Vor Python 3.7 verließen sich Entwickler ausschließlich auf threading.local(), um anfragen-spezifische Daten wie Benutzersitzungen oder Datenbankverbindungen zu speichern. Die Verbreitung von asyncio offenbarte jedoch einen grundsätzlichen Fehler: Thread-lokale Speicherung wird von allen Koroutinen, die auf dem gleichen Event-Loop-Thread laufen, geteilt. Wenn eine asynchrone Aufgabe die Kontrolle abgibt, könnte eine andere unbeabsichtigt auf den scheinbar isolierten Status der ersten Aufgabe zugreifen oder diesen ändern, was zu Sicherheitsanfälligkeiten und Datenkorruption führt. PEP 567 führte contextvars ein, um eine logische Ausführungskontext-Isolation unabhängig von OS-Threads bereitzustellen, wobei das Konzept nach ähnlichen Mechanismen in C# und Erlang modelliert wurde.
In synchronem Python führt jede HTTP-Anfrage typischerweise auf ihrem eigenen Thread aus, was threading.local() ausreichend macht, um den Anfragekontext zu speichern. In asynchronen Architekturen können Tausende von gleichzeitigen Anfragen auf einem einzigen Thread multiplexiert werden, der von einem Event-Loop verwaltet wird. Wenn zwei asynchrone Aufgaben gleichzeitig ausgeführt werden – eine pausiert bei einem await, während die andere fortgesetzt wird – teilen sie sich das gleiche thread-lokale Dictionary. Ohne einen Mechanismus, um den Kontext bei Aufgabenwechseln zu speichern und wiederherzustellen, sickert der globale Status zwischen logisch separaten Operationen. Dies schafft Wettlaufbedingungen, bei denen das Authentifizierungstoken Aufgabe A für Aufgabe B sichtbar wird oder die Grenzen von Datenbanktransaktionen zwischen nicht verwandten Anforderungen verschwommen sind.
Python implementiert ContextVar als Schlüssel in einer unveränderlichen Karte, die im Thread-Zustand gespeichert ist. Jede asynchrone Aufgabe hält einen Verweis auf ihr eigenes Context-Objekt – eine dauerhafte Datenstruktur, bei der Modifikationen neue Versionen erstellen, anstatt den gemeinsamen Zustand zu verändern. Wenn asyncio eine Aufgabe bei einem await aussetzt, erfasst es den aktuellen Kontext; beim Fortsetzen wird dieser Kontext wiederhergestellt, wodurch sichergestellt wird, dass ContextVar.get() den Wert zurückgibt, der an diese spezifische Aufgabe gebunden ist, auch wenn sich die OS-Threads möglicherweise verschoben haben. Diese Copy-on-Write-Semantik garantiert Isolation ohne Lock-Überhead.
import contextvars import asyncio request_id = contextvars.ContextVar('request_id', default='unknown') async def process_task(task_name): # Wert für diesen spezifischen Aufgaben-Kontext setzen token = request_id.set(task_name) try: await asyncio.sleep(0.01) # Kontrolle abgeben, andere Aufgaben können ausgeführt werden current = request_id.get() print(f"Aufgabe {task_name} liest: {current}") finally: request_id.reset(token) # Vorherigen Kontext wiederherstellen async def main(): # Zwei Aufgaben gleichzeitig auf demselben Thread ausführen await asyncio.gather(process_task('Alpha'), process_task('Beta')) asyncio.run(main())
Ein Team, das ein Hochdurchsatz-API-Gateway aufbaute, migrierte von einer threaded Flask-Anwendung zu einem asynchronen FastAPI-Dienst. Sie entdeckten, dass ihre Authentifizierungsmiddleware, die den aktuellen Benutzer in threading.local() speicherte, unter Last zufällig die Identität von Benutzer A den Anfragen von Benutzer B zuwies. Erste Debugging-Versuche deuteten auf Wettlaufbedingungen hin, aber Protokolle zeigten, dass die Zuweisungen selbst bei Ein-Worker-Bereitstellungen geschahen. Die Ursache war das kooperative Multitasking von asyncio, bei dem ein Anfragenhandler während eines Datenbankaufrufs die Kontrolle abgibt und es einem anderen Handler ermöglicht, auf demselben Thread zu laufen und den thread-lokalen Speicher zu übernehmen.
Das Team versuchte zunächst, ein globales Dictionary nach threading.get_ident() zu indizieren, in der Annahme, dass dies die Anfragen isolieren würde. Dieser Ansatz bot eine einfache Migration von der alten Codebasis, ohne externe Abhängigkeiten einzuführen. Unter uvicorn mit asyncio behandelt jedoch derselbe Thread mehrere Anfragen nacheinander, was bedeutet, dass das Dictionary veraltete Daten von vorherigen Anfragen beibehielt und Berechtigungsfehler verursachte, bei denen authentifizierte Sitzungen fälschlicherweise zwischen nicht verwandten Anfragen weiter bestanden.
Sie refaktorisierten jede Funktionssignatur, um einen context-Dictionaryparameter zu akzeptieren und diesen durch den gesamten Aufrufstapel von der Middleware bis zur Datenbankebene zu leiten. Dieser explizite Datenfluss beseitigte versteckten Zustand und funktionierte über sowohl synchrone als auch asynchrone Grenzen hinweg. Leider erforderte dies massive Refaktorisierungen, die Tausende von Funktionen betrafen und Integrationen von Drittanbietern, die globale Konfigurationsobjekte erwarteten, unterbrachen, während die resultierende Code-Lesbarkeit die Wartungsbelastung und das Risiko menschlichen Fehlers erheblich erhöhte.
Das Team übernahm contextvars.ContextVar, um das authentifizierte Benutzerobjekt zu speichern, wodurch die Middleware die Variable beim Eintritt der Anfrage setzen konnte, während nachgelagerte Funktionen über .get() darauf zugreifen konnten, ohne die Funktionssignaturen zu belasten. Dieser Ansatz erforderte keine architektonischen Überarbeitungen und bot automatische Isolation zwischen konkurrierenden Aufgaben, obwohl dies ein sorgfältiges Management von reset()-Token erforderte, um Speicherlecks in langlaufenden Prozessen zu verhindern. Außerdem wurde das Debugging herausfordernder, da der Zustand implizit im Ausführungskontext und nicht in Stack-Traces sichtbar war.
Letztendlich wählte das Team contextvars, weil Prototyping zeigte, dass es nur Änderungen an der Middleware-Ebene erforderte und die massive Refaktorisierung um explizite Kontextübergabe vermied. Indem sie Anforderungs-Handler in try/finally-Blöcke einwickelten, um sicherzustellen, dass Token zurückgesetzt wurden, verhinderten sie Speicherlecks bei gleichzeitiger Beibehaltung sauberer Funktionssignaturen. Das Gateway verarbeitet nun 50.000 gleichzeitige Verbindungen pro Worker, ohne Datenlecks zwischen Anfragen, und das Team reduzierte die Anzahl der OS-Threads von 100 pro Instanz auf 4, was den Speicherverbrauch um 80 % senkte und die Gesamtleistung um 300 % verbesserte.
Warum funktioniert threading.local() in asynchronem Code nicht, aber in threaded Code?
In threaded Python plant das Betriebssystem Threads präemptiv, und jeder Thread hat seinen eigenen C-Stack und PyThreadState-Struktur. threading.local() ordnet Variablen dieser OS-Level-Thread-Identität zu und stellt somit Isolation sicher. In asyncio plant die Event-Loop kooperativ Aufgaben auf einem einzigen Thread unter Verwendung einer Warteschlange; wenn eine Aufgabe ausgibt, führt die Schleife sofort eine andere Aufgabe auf demselben Thread aus, ohne PyThreadState zu wechseln. Folglich sieht threading.local() denselben Schlüssel für beide Aufgaben, was zu Zustandssickerungen führt. Contextvars löst dies, indem es einen Stapel von Kontextzuweisungen innerhalb des PyThreadState beibehält, den die Event-Schleife während der Aufgabenwechsel swappt und so logische Isolation unabhängig von den OS-Threads schafft.
Was passiert, wenn Sie vergessen, einen ContextVar-Token zurückzusetzen?
ContextVar.set() gibt ein Token-Objekt zurück, das den vorherigen Zustand repräsentiert und an reset() übergeben werden muss, um den vorherigen Wert wiederherzustellen. Wenn Sie dies versäumen – beispielsweise, indem Sie einen try/finally-Block weglassen – behält die Variable ihren Wert über den beabsichtigten Umfang hinaus. In langlaufenden asynchronen Servern führt dies zu einem Speicherleck, bei dem alte Anfrage-Kontexte in der Kontextkette anfallen, und nachfolgende Aufgaben auf diesem Thread könnten veraltete Werte erben, wenn der Kontext nicht ordnungsgemäß wiederhergestellt wird. Im Gegensatz zu traditionellen Stapelvariablen, die verschwinden, wenn Funktionen zurückkehren, bleiben Kontextvariablen im Ausführungskontext bestehen, bis sie explizit zurückgesetzt oder bis die Aufgabe endet, was die Bereinigung zwingend erforderlich macht.
Wie propagieren sich Kontextvariablen zu untergeordneten Aufgaben und Threads?
Wenn Sie asyncio.create_task() verwenden, erhält die untergeordnete Aufgabe automatisch eine Kopie des aktuellen Kontexts des übergeordneten Kontextes, um sicherzustellen, dass Kontextvariablen natürlich über das asynchrone Aufrufgraf fließen. Wenn Sie jedoch concurrent.futures.ThreadPoolExecutor oder loop.run_in_executor() verwenden, wird der Aufruf in einem anderen OS-Thread ausgeführt, der standardmäßig mit einem leeren Kontext beginnt. Bewerber nehmen oft an, dass der Kontext über Thread-Grenzen hinweg wie thread-lokale Speicherung propagiert, aber contextvars sind spezifisch für den logischen asynchronen Kontext. Um Werte an Threads zu propagieren, müssen Sie den Kontext explizit mithilfe von contextvars.copy_context() erfassen und die Funktion innerhalb dieses Kontexts über context.run() ausführen oder die Variablen manuell als Argumente übergeben.