Un context.Context propage l'annulation à travers un arbre hiérarchique où chaque nœud dérivé maintient une référence à son parent via une structure cancelCtx ou valueCtx intégrée. Cette structure d'arbre permet un suivi bidirectionnel : les parents connaissent leurs enfants grâce à une carte protégée par un mutex, tandis que les enfants connaissent leurs parents par des références de pointeur direct. Lorsque l'annulation se produit, ce design permet une traversée immédiate de la racine aux feuilles sans coordination globale.
Lorsque cancel() est invoqué sur un nœud parent, il acquiert un mutex pour protéger la carte children, itère sur tous les contextes enfants enregistrés et invoque leurs fermetures cancel respectives de manière récursive. La fonction cancel de chaque enfant ferme son propre canal done dédié (alloué paresseusement via sync.Once pour optimiser les contextes qui ne sont jamais annulés) et se retire de la carte children du parent pour éliminer les références qui, autrement, empêcheraient la collecte des déchets. Ce mécanisme garantit que les signaux d'annulation se propagent instantanément à travers tout le sous-arbre tout en évitant les fuites de ressources.
Pour les annulations basées sur le délai, timerCtx intègre un time.Timer qui déclenche automatiquement la fermeture cancel lorsque la date limite expire. De manière cruciale, si le parent se décharge avant que le minuteur ne s'active, la fonction cancel de l'enfant arrête explicitement le minuteur via Stop() et vide le canal si nécessaire, empêchant la goroutine de minuterie de persister dans le runtime et de consommer des ressources après que le contexte a déjà été annulé.
Considérez un microservice Go à fort débit traitant des demandes d'utilisateurs qui se répartissent sur trois services en aval : une base de données PostgreSQL principale, un cache Redis, et une API REST tierce. Chaque demande doit exécuter des requêtes contre les trois sources pour agréger une réponse, avec des latences p99 budgétées à moins de 500 millisecondes. Le service gère des milliers de connexions simultanées, ce qui rend la gestion des ressources critique pour la stabilité.
Description du problème :
Sous une lourde charge, les clients se déconnectent fréquemment (délai d'attente ou fermeture de connexion) après avoir soumis des demandes, mais les goroutines continuent à traiter des requêtes complètes contre la base de données et attendent des API externes lentes, épuisant les pools de connexion et le CPU malgré le fait que les résultats soient sans valeur. L'annulation manuelle nécessite de transmettre des drapeaux booléens à travers des dizaines d'appels de fonction, ce qui est fragile et sujet à l'erreur. De plus, sans propagation adéquate, les goroutines gérant ces demandes abandonnées pourraient s'accumuler indéfiniment, entraînant éventuellement une condition OOM (Out Of Memory) ou une exhaustion des descripteurs de fichiers sur le serveur hôte.
Différentes solutions envisagées :
Propagation manuelle avec des drapeaux atomiques : Nous avons envisagé de passer un pointeur atomic.Bool à travers chaque signature de fonction, en le vérifiant périodiquement dans des boucles. Cette approche offre un surcoût d'abstraction nul et permet un contrôle explicite sur les points d'annulation. Cependant, cela ne peut pas interrompre les appels système bloquants comme les lectures TCP, requiert des changements de code invasifs pour chaque fonction de bibliothèque et n'offre aucune standardisation pour les délais ou les échéances.
Fermage de goroutines avec des canaux d'arrêt explicites : Lancer chaque opération en aval dans une goroutine séparée et utiliser un bloc select sur un canal de clôture personnalisé permet un retour anticipé lorsque l'annulation est demandée. Cette approche fournit des points d'annulation non bloquants et une gestion modulaire des délais par opération. Cependant, cela crée O(n) goroutines par demande où n est le nombre d'opérations, engendre un surcoût de planification important, et ne peut toujours pas forcer l'annulation dans des bibliothèques tierces qui n'acceptent pas de canaux ou ne vérifient pas les états d'annulation.
Propagation standard de l'arbre de contexte : Utiliser http.Request.Context() comme racine et dériver des contextes enfants via context.WithTimeout pour chaque appel en aval permet un support d'annulation natif dans la bibliothèque standard. Cette méthode offre une propagation automatique des délais à travers toute la pile d'appels sans surcoût de goroutine par opération et gère automatiquement le nettoyage du minuteur. Cependant, elle nécessite un respect strict de l'utilisation appropriée de l'API, comme toujours appeler la fonction d'annulation renvoyée par WithTimeout pour éviter de fuir des ressources de minuteurs.
Solution choisie et résultat :
Nous avons choisi la propagation standard de l'arbre de contexte, où chaque gestionnaire HTTP dérive un contexte sciemment lié à la demande avec un délai de 30 secondes et les requêtes de base de données individuelles utilisent context.WithTimeout(reqCtx, 2*time.Second) pour imposer des sous-délai plus stricts. Lorsqu'un client se déconnecte, le serveur HTTP annule le contexte racine, ce qui traverse l'arbre et débloque immédiatement les appels réseau du pilote sql pour libérer les connexions. Sous les tests de charge avec 10k demandes concurrentes et 30 % de déconnexions de clients, les événements d'épuisement du pool de connexion ont chuté de 95 %, et la latence p99 pour les demandes actives s'est considérablement améliorée grâce à une réduction de la contention des ressources.
Pourquoi un contexte enfant annulé doit-il explicitement se retirer de la carte children de son parent pour éviter les fuites de mémoire ?
Beaucoup supposent que le parent conserve les enfants tant qu'il n'est pas détruit lui-même. En pratique, lorsque cancelCtx.cancel() s'exécute (que ce soit en raison de la propagation parentale ou d'un délai local), il acquiert le mutex du parent et se supprime de la carte children. Si cette suppression n'avait pas lieu, un contexte parent de longue durée (comme un contexte de serveur en arrière-plan) accumulerait des entrées pour chaque contexte de demande transitoire jamais créé, empêchant la collecte des déchets de la mémoire de requêtes complétées et provoquant une croissance de tas illimitée.
Comment context.WithValue atteint-il O(1) d'espace par clé tout en maintenant un temps de recherche O(k) où k est la profondeur de l'arbre, et pourquoi ne pas utiliser une carte ?
Les candidats suggèrent souvent de copier une carte à chaque appel de WithValue (ce qui coûterait O(n) en taille de carte) ou d'utiliser une carte synchronisée globale (problèmes de concurrence). L'implémentation réelle utilise une liste chaînée : chaque valueCtx contient une clé, une valeur et un pointeur vers le parent. Value() traverse vers le haut en comparant les clés. Puisque les arbres de contexte sont rarement plus profonds que 5-10 niveaux (demande → gestionnaire → service → DB → tx), cela est effectivement de temps constant. Utiliser une carte par contexte nécessiterait soit de copier (coûteux), soit de la mutabilité (non sécurisé pour les lectures concurrentes).
Quel est le danger spécifique de stocker nil dans une variable d'interface context.Context, et pourquoi context.Background() retourne-t-il une structure vide non-nulle au lieu de nil ?
Bien que var c context.Context = nil soit valide, le passer à des fonctions qui s'attendent à des contextes annulables provoque des panics lorsque des méthodes sont appelées sur l'interface nulle. Background() retourne un singleton backgroundCtx{} (une structure vide non-nulle implémentant l'interface) pour garantir que les appels de méthode réussissent toujours et pour fournir une racine stable pour les arbres de contexte. Cela évite la confusion entre "interface nulle vs concrète nulle" (où un pointeur typé nul satisfait aux vérifications != nil mais panique lors des appels de méthode) en garantissant que la valeur de contexte n'est jamais nulle, seul le pointeur parent peut logiquement être nul.