Quand et comment dois-je utiliser un ThreadLocal variable?

Un possible (et fréquent) d'utiliser, c'est quand vous avez un objet qui n'est pas thread-safe, mais vous voulez éviter de la synchronisation accès à l'objet (je suis à la recherche à vous, SimpleDateFormat). Au lieu de cela, donner à chaque fil sa propre instance de l'objet.

Par exemple:

public class Foo
{
    //SimpleDateFormat is not thread-safe, so give one to each thread
    private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
        @Override
        protected SimpleDateFormat initialValue()
        {
            return new SimpleDateFormat("yyyyMMdd HHmm");
        }
    };

    public String formatIt(Date date)
    {
        return formatter.get().format(date);
    }
}

La Documentation.

De nombreux cadres de l'utilisation ThreadLocals à maintenir un certain contexte lié à l'thread courant. Par exemple, lorsque la transaction en cours est stocké dans un ThreadLocal, vous n'avez pas besoin de passer en tant que paramètre par le biais de chaque appel de méthode, au cas où quelqu'un en bas de la pile a besoin d'un accès à elle. Les applications Web peuvent stocker des informations sur la demande actuelle et de la session dans un ThreadLocal, de sorte que l'application dispose d'un accès facile pour eux. Avec Guice vous pouvez utiliser ThreadLocals lors de la mise en œuvre de des étendues personnalisées pour l'injection des objets (Guice par défaut de servlet étendues plus probablement les utiliser en tant que bien).

ThreadLocals sont une sorte de variables globales (bien qu'un peu moins mal parce qu'ils sont limités à un seul thread), donc vous devez être prudent lors de leur utilisation afin d'éviter des effets secondaires indésirables et les fuites de mémoire. La conception de votre Api, de sorte que le ThreadLocal valeurs sera toujours automatiquement désactivée lorsqu'ils ne sont plus nécessaires et que la mauvaise utilisation de l'API ne sera pas possible (par exemple comme ceci). ThreadLocals peut être utilisé pour rendre le code plus propre, et dans certains rares cas, ils sont la seule façon de faire quelque chose à travailler (mon projet actuel a deux cas de ce type; ils sont documentés ici sous "les Champs Statiques et Variables Globales").

Il est un très bon exemple dans le livre Java de la Simultanéité dans la Pratique. Où l'auteur (Joshua Bloch) explique comment le Thread de l'accouchement est l'une des façons les plus simples pour parvenir à la sécurité des threads et ThreadLocal est plus formel les moyens de maintenir fil de l'accouchement. À la fin il explique également comment les gens peuvent en abuser en l'utilisant comme variables globales.

J'ai copié le texte du livre susmentionné mais le code 3.10 est absente, tout comme il n'est pas très important de comprendre d'où ThreadLocal, devrait être utilisée.

Ces variables sont souvent utilisés afin d'empêcher le partage de conceptions basées sur mutable Singletons ou des variables globales. Par exemple, une application unique-thread peut maintenir une base de données mondiale de connexion est initialisée au démarrage pour éviter d'avoir à passer d'une Connexion à chaque méthode. Depuis les connexions JDBC ne sont pas thread-safe, une application multithread qui utilise une connexion globale sans une coordination supplémentaire n'est pas thread-safe soit. À l'aide d'un ThreadLocal pour stocker de la connexion JDBC, comme dans ConnectionHolder dans la Liste 3.10, chaque thread a son propre connexion.

ThreadLocal est largement utilisé dans la mise en œuvre de l'application de cadres de. Par exemple, un conteneur J2EE associer un contexte de transaction avec un thread qui s'exécute pour la durée d'un EJB appel. Ceci est facilement réalisé en utilisant un statique Locale de Thread la tenue de l'opération contexte: quand le code de la structure a besoin pour déterminer ce que l'opération est actuellement en cours d'exécution, il récupère le contexte de transaction à partir de ce ThreadLocal. C'est pratique en ce qu'elle réduit le besoin de passer d'un contexte d'exécution d'information dans chaque méthode, mais les couples le code qui utilise ce mécanisme pour le cadre.

Il est facile d'abus ThreadLocal par le traitement de son fil de confinement de la propriété comme une licence pour utiliser des variables globales ou comme un moyen de créer des “caché” des arguments de méthode. Comme les variables globales, variables, peut nuire à la réutilisabilité et d'introduire caché couplages entre les classes, et doit donc être utilisé avec précaution.

1. ThreadLocal en Java a été introduite sur la JDK 1.2, mais a été plus tard generified dans le JDK 1.5 à introduire le type de sécurité sur ThreadLocal variable.

2. ThreadLocal peut être associé avec du Fil portée, tout le code qui est exécuté par le Thread a accès à ThreadLocal variables, mais deux thread ne peut pas voir les uns les autres ThreadLocal variable.

3. Chaque thread détient en exclusivité une copie de ThreadLocal variable qui devient admissible à la collecte des Déchets après que le thread a fini ou est décédé, normalement ou en raison de toute Exception, compte tenu de ces ThreadLocal variable n'a pas d'autres vivent des références.

4. ThreadLocal variables en Java sont généralement privés de champs statiques dans les Classes et de maintenir son état à l'intérieur du Fil.

Lire la suite: ThreadLocal en Java - Exemple de Programme et un Tutoriel

Webapp serveur peut maintenir un pool de threads, et un ThreadLocal var doit être retiré avant la réponse au client, ainsi thread en cours peuvent être réutilisés par la demande suivante.

Depuis Java 8 release, il n'y a plus déclaratif d'initialiser ThreadLocal:

ThreadLocal<Cipher> local = ThreadLocal.withInitial(() -> "init value");

Jusqu'à ce que Java 8 release vous deviez effectuer les opérations suivantes:

ThreadLocal<String> local = new ThreadLocal<String>(){
    @Override
    protected String initialValue() {
        return "init value";
    }
};

En outre, si l'instanciation de la méthode (constructeur, méthode de fabrique) de la classe qui est utilisée pour ThreadLocal ne prend aucun paramètre, vous pouvez simplement utiliser la méthode des références (introduit dans Java 8):

class NotThreadSafe {
    //no parameters
    public NotThreadSafe(){}
}

ThreadLocal<NotThreadSafe> container = ThreadLocal.withInitial(NotThreadSafe::new);

Remarque:
L'évaluation est paresseux puisque vous êtes de passage à java.util.function.Supplier lambda qui est évaluée uniquement lorsque ThreadLocal#get nom, mais la valeur n'a pas été évalué.

quand?

Lorsqu'un objet n'est pas thread-safe, au lieu de synchronisation, ce qui freine l'évolutivité, de donner un objet à tous les fils et de le garder fil portée, ce qui est ThreadLocal. L'un des plus fréquemment utilisé, mais pas thread-safe sont les objets de Connexion de base de données et JMSConnection.

Comment ?

Un exemple est le Printemps framework utilise ThreadLocal fortement pour la gestion des transactions dans les coulisses par le maintien de ces objets de connexion dans ThreadLocal variables. Au plus haut niveau, lorsqu'une transaction est démarrée, il obtient la connexion ( et désactive la validation automatique ) et la maintient dans ThreadLocal. sur la poursuite de la db appels, il utilise la même connexion pour communiquer avec db. À la fin, il prend la connexion de ThreadLocal et s'engage à le ( ou la restauration ) de la transaction et libère la connexion.

Je pense que log4j utilise également ThreadLocal pour le maintien de la MDC.

Rien de vraiment nouveau ici, mais j'ai découvert aujourd'hui que ThreadLocal est très utile lors de l'utilisation de Bean Validation, dans une application web. Les messages de Validation sont localisées, mais par défaut, utilisez Locale.getDefault(). Vous pouvez configurer le Validator avec un autre MessageInterpolator, mais il n'y a aucun moyen de spécifier le Locale lorsque vous appelez validate. Vous pouvez donc créer un statique ThreadLocal<Locale> (ou mieux encore, un conteneur avec d'autres choses que vous pourriez avoir besoin pour être ThreadLocal et ensuite votre personnalisé MessageInterpolator choisir le Locale de que. La prochaine étape consiste à écrire un ServletFilter qui utilise une valeur de session ou request.getLocale() de choisir les paramètres régionaux et de le stocker dans votre ThreadLocal de référence.

ThreadLocal permettra d'assurer l'accès à l'mutable objet par les multiples
les threads dans le non synchronisé méthode est synchronisé, les moyens
la mutable objet immuable dans la méthode.

Cette
est réalisée en donnant à la nouvelle instance de l'objet mutable pour chaque thread
essayez d'y accéder. C'est donc une copie locale de chaque thread. C'est certains
hack sur la prise de variable d'instance dans une méthode pour être accessible comme une
variable locale. Comme vous conscient de la méthode de la variable locale n'est disponible
pour le fil, une différence est; méthode des variables locales ne seront pas
disponible pour le fil une fois que l'exécution de la méthode est plus où que mutable
objet partagé avec threadlocal sera disponible dans plusieurs
méthodes jusqu'à ce que nous le nettoyer.

Par Définition:

La ThreadLocal classe en Java permet de créer des variables qui peuvent
seulement être lu et écrit par le même thread. Ainsi, même si deux threads
d'exécuter le même code, et le code a une référence à une
ThreadLocal variable, puis les deux threads ne peuvent pas voir les uns les autres
ThreadLocal variables.

Chaque Thread en java contient ThreadLocalMap en elle.

Où

Key = One ThreadLocal object shared across threads.
value = Mutable object which has to be used synchronously, this will be instantiated for each thread.

La réalisation de la ThreadLocal:

Maintenant créer une classe wrapper pour ThreadLocal qui va contenir la mutable objet comme ci-dessous (avec ou sans initialValue()).
Maintenant getter et setter de ce wrapper travail sur threadlocal instance au lieu d'mutable objet.

Si getter() de threadlocal n'ai pas trouver une valeur dans le threadlocalmap de la Thread; alors qu'il invoquera le initialValue() pour obtenir sa copie privée à l'égard du fil.

class SimpleDateFormatInstancePerThread {

    private static final ThreadLocal<SimpleDateFormat> dateFormatHolder = new ThreadLocal<SimpleDateFormat>() {

        @Override
        protected SimpleDateFormat initialValue() {
            SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd") {
                UUID id = UUID.randomUUID();
                @Override
                public String toString() {
                    return id.toString();
                };
            };
            System.out.println("Creating SimpleDateFormat instance " + dateFormat +" for Thread : " + Thread.currentThread().getName());
            return dateFormat;
        }
    };

    /*
     * Every time there is a call for DateFormat, ThreadLocal will return calling
     * Thread's copy of SimpleDateFormat
     */
    public static DateFormat getDateFormatter() {
        return dateFormatHolder.get();
    }

    public static void cleanup() {
        dateFormatHolder.remove();
    }
}

Maintenant wrapper.getDateFormatter() appellera threadlocal.get() et qui permettra de vérifier la currentThread.threadLocalMap contient ce (threadlocal) exemple.

Si oui, de retour de la valeur (SimpleDateFormat) correspondant threadlocal instance

d'autre ajouter la carte avec cette threadlocal exemple, initialValue().

Ci-joint la sécurité des threads réalisés sur ce mutable classe; par chaque thread est de travailler avec ses propres mutable instance, mais avec le même ThreadLocal instance. Signifie que Tous les threads partagent le même ThreadLocal exemple sous forme de clé, mais différents SimpleDateFormat exemple comme valeur.

https://github.com/skanagavelu/yt.tech/blob/master/src/ThreadLocalTest.java

La ThreadLocal classe en Java vous permet de créer des variables qui ne peuvent être lus et écrits par le même thread. Ainsi, même si deux threads s'exécutent le même code, et le code a une référence à une ThreadLocal variable, puis les deux threads ne peuvent pas voir les uns les autres ThreadLocal variables.

Lire plus

La mise en cache, parfois, vous devez calculer la valeur de même beaucoup de temps, donc par le stockage de la dernière série d'entrées d'une méthode et du résultat, vous pouvez accélérer le code. En utilisant Thread Local Storage vous éviter d'avoir à réfléchir sur le verrouillage.

Threadlocal fournit un moyen très facile de réaliser des objets de réutilisabilité avec un coût nul.

J'ai eu une situation où plusieurs threads ont été la création d'une image de mutable cache, sur chaque notification de mise à jour.

J'ai utilisé un Threadlocal sur chaque fil, puis chaque thread juste besoin de réinitialiser l'ancienne image et ensuite mettre à jour à partir du cache sur chaque notification de mise à jour.

Habitude d'objets réutilisables à partir de l'objet de réserves de sécurité des threads et des coûts qui leur sont associés, bien que cette approche n'en a aucun.