Comment ThreadLocal de Java est-il implémenté sous le capot?

Toutes les réponses ici sont correctes, mais un peu décevantes car elles montrent à quel point la mise en œuvre de ThreadLocal est intelligente. Je regardais juste le code source pour ThreadLocal et a été agréablement impressionné par la façon dont il est mis en œuvre.

L'Implémentation Naïve

Si je vous demandais d'implémenter une classe ThreadLocal<T> compte tenu de l'API décrite dans le javadoc, que feriez-vous? Une implémentation initiale serait probablement un ConcurrentHashMap<Thread,T> utilisant Thread.currentThread() comme clé. Ce will fonctionnerait raisonnablement bien, mais présente certains inconvénients.

• Thread contention - ConcurrentHashMap est une classe assez intelligente, mais elle doit finalement encore s'occuper d'empêcher plusieurs threads de s'en mêler de quelque manière que ce soit, et si différents threads le frappent régulièrement, il y aura des ralentissements.
• Conserve en permanence un pointeur sur le Thread et l'objet, même après que le Thread a terminé et pourrait être GC'ed.

Le GC-friendly Mise en œuvre

Ok essayez à nouveau, permet de traiter le problème de récupération de place en utilisant références faibles . Traiter avec WeakReferences peut être déroutant, mais il devrait suffire d'utiliser une carte construite comme ceci:

 Collections.synchronizedMap(new WeakHashMap<Thread, T>())

Ou si nous utilisons Goyave (et nous devrions être!):

new MapMaker().weakKeys().makeMap()

Cela signifie qu'une fois que personne d'autre ne tient le Thread (ce qui implique qu'il est terminé), la clé / valeur peut être récupérée, ce qui est une amélioration, mais ne le fait toujours pas résoudre le problème de conflit de threads, ce qui signifie que jusqu'à présent, notre ThreadLocal n'est pas si étonnant d'une classe. De plus, si quelqu'un décidait de conserver des objets Thread après avoir terminé, ils ne seraient jamais GC'ed, et donc nos objets non plus, même s'ils sont techniquement inaccessibles maintenant.

La mise en œuvre intelligente

Nous avons pensé à ThreadLocal comme un mappage de threads à des valeurs, mais peut-être que ce n'est pas vraiment la bonne façon d'y penser. Plutôt de le penser comme un mappage des Threads aux valeurs dans chaque objet ThreadLocal, et si nous le pensions comme un mappage des objets ThreadLocal aux valeurs dans chaque Thread? Si chaque thread stocke le mappage et que ThreadLocal fournit simplement une interface agréable dans ce mappage, nous pouvons éviter tous les problèmes des implémentations précédentes.

Une implémentation ressemblerait à ceci:

// called for each thread, and updated by the ThreadLocal instance
new WeakHashMap<ThreadLocal,T>()

Il n'est pas nécessaire de s'inquiéter de la concurrence ici, car seulement un thread accédera jamais à cette carte.

Les développeurs Java ont un avantage majeur sur nous ici - ils peuvent directement développer la classe Thread et y ajouter des champs et des opérations, et c'est exactement ce qu'ils ont fait.

Dans java.lang.Thread il y a les lignes suivantes:

/* ThreadLocal values pertaining to this thread. This map is maintained
 * by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;

Qui, comme le suggère le commentaire, est en effet un mappage privé de paquets de toutes les valeurs suivies par les objets ThreadLocal pour ce Thread. La mise en œuvre de ThreadLocalMap n'est pas une WeakHashMap, mais il suit le même contrat de base, y compris en tenant ses clés par référence faible.

ThreadLocal.get() est ensuite implémenté comme ceci:

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

Et ThreadLocal.setInitialValue() comme ceci:

private T setInitialValue() {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
    return value;
}

Essentiellement, utilisez une cartedans ce fil pour contenir tous nos ThreadLocal objets. De cette façon, nous n'avons jamais besoin de nous soucier des valeurs des autres Threads (ThreadLocal ne peut littéralement accéder qu'aux valeurs du thread actuel) et n'avons donc aucun problème de concurrence. De plus, une fois le Thread terminé, sa carte sera automatiquement GC'ed et tous les objets locaux seront nettoyés. Même si le Thread est maintenu, les objets ThreadLocal sont maintenus par une référence faible et peuvent être nettoyés dès que l'objet ThreadLocal sort de la portée.

Inutile de dire que j'ai été plutôt impressionné par cette implémentation, elle contourne assez élégamment beaucoup de problèmes de concurrence (certes en profitant de faire partie du noyau Java, mais c'est pardonnable comme c'est une classe si intelligente) et permet un accès rapide et sécurisé aux objets qui ne doivent être accessibles que par un thread à la fois.

Tl; dr ThreadLocal'l'implémentation de s est assez cool, et beaucoup plus rapide/plus intelligent que vous ne le pensez à première vue.

Si vous avez aimé cette réponse, vous pourriez également apprécier ma discussion (moins détaillée) sur ThreadLocalRandom.

_{Thread/ThreadLocal des extraits de code tirés de l'implémentation de Java par Oracle/OpenJDK 8.}