Réponse à la question.
ThreadLocal a été introduit dans Java 1.2 pour fournir des variables locales à un thread sans passer en paramètres des méthodes. L'implémentation utilise un ThreadLocalMap stocké dans chaque objet Thread, où les clés de la carte sont des wrappers WeakReference autour des instances ThreadLocal. La faille de conception critique survient parce que la classe Entry de la carte conserve la valeur via un champ de référence forte, ce qui signifie que même lorsque la clé WeakReference est effacée par le ramassage de garbage, l'objet de valeur reste fortement référencé par le Thread vivant. Cela crée une fuite de mémoire dans les pools de threads où les threads survivent indéfiniment, accumulant des valeurs orphelines. Sans appel explicite à remove(), l'entrée obsolète peut persister tout au long de la durée de vie du thread, immobilisant effectivement l'objet de valeur en mémoire.
Situation de la vie réelle
Une plateforme de trading financier a utilisé ThreadLocal pour stocker des instantanés de données de marché par requête à travers des appels de service profondément imbriqués. En utilisant un ThreadPoolExecutor fixe, l'application a mystérieusement épuisé l'espace mémoire de tas toutes les 12 heures sous une charge de production. Les dumps de tas ont révélé que les objets Thread retenaient de grands tableaux byte[] via des entrées ThreadLocalMap avec des clés nulles, entraînant une dégradation du service.
Solution 1 : Hygiène manuelle avec try-finally
Les développeurs ont tenté d'encapsuler chaque point d'entrée avec des blocs try-finally appelant remove().
Solution 2 : Enveloppe de pool de threads avec nettoyage automatique
Les ingénieurs ont envisagé d'envelopper les tâches Runnable pour capturer et effacer tous les ThreadLocals après exécution.
Solution 3 : Injection de dépendance à portée de requête
Migration du stockage du contexte vers des beans RequestScope de Spring avec nettoyage automatique des proxys.
Solution choisie et résultat
L'équipe a choisi une approche hybride utilisant un Servlet Filter avec try-finally pour garantir que remove() était appelé pour tous les ThreadLocals à portée de requête. Cela a permis une application centralisée sans refactorisation architecturale, empêchant l'accumulation même en cas d'exceptions. La rétention dans le tas a chuté de 90 %, éliminant le cycle de redémarrage forcé et satisfaisant le SLA de disponibilité de 99,99 %. Une surveillance continue a confirmé une utilisation stable de la mémoire de tas sur plusieurs semaines d'opération.
Ce que les candidats omettent souvent
Pourquoi ThreadLocalMap utilise-t-il WeakReference pour la clé mais une référence forte pour la valeur, plutôt que de rendre les deux faibles ?
Si la valeur était conservée par le biais d'une WeakReference, le garbage collector pourrait récupérer l'objet de valeur alors que la clé ThreadLocal est encore accessible. Cela entraînerait des appels subséquents à get() renvoyant null de manière inattendue, violant l'attente qu'une valeur définie par un thread reste stable durant la durée d'exécution de ce thread. La référence forte garantit la stabilité de la valeur, tandis que la clé faible permet à l'entrée d'être marquée comme obsolète une fois l'instance ThreadLocal elle-même n'est plus référencée par la logique de l'application.
Comment InheritableThreadLocal propage-t-il des valeurs aux threads enfants, et quel risque unique de fuite de mémoire cela introduit-il dans les environnements de pool de threads ?
InheritableThreadLocal copie les entrées du thread parent dans la carte inheritableThreadLocals du thread enfant lors de l'initialisation du Thread via Thread.init(). Cette copie peu profonde se produit lors de la création du thread, ce qui signifie que les pools de threads—où les threads sont créés une fois et réutilisés—héritent des valeurs du parent arbitraire qui les a créés. Si ce parent tenait de grands contextes, chaque thread du pool conserve ces références de manière permanente, pouvant potentiellement fuir des données sensibles à travers différentes requêtes lorsque les threads traitent des tâches pour différents utilisateurs.
Quel est le but du comportement de rehashing de la méthode expungeStaleEntry lors du nettoyage, et pourquoi simplement annuler l'emplacement obsolète briserait-il les invariants de la carte ?
ThreadLocalMap résout les collisions en utilisant l'adressage ouvert avec un sondage linéaire. Lorsqu'une entrée obsolète est supprimée, il suffit d'annuler son emplacement pour briser la chaîne de sondage pour les entrées qui ont été stockées après elle en raison de collisions. La méthode expungeStaleEntry rehashes toutes les entrées suivantes dans la séquence de sondage jusqu'à ce qu'elle rencontre un emplacement nul, les relocalisant à leurs positions correctes. Sans ce rehashing, les opérations de recherche pour ces entrées déplacées termineraient prématurément à l'emplacement nul, retournant incorrectement null bien que l'entrée existe plus tard dans la table.