Explication détaillée d'exemples comparatifs de threads locaux ThreadLocal et de mécanismes de synchronisation en Java

Cet article présente principalement des informations pertinentes sur la comparaison des threads locaux ThreadLocal et des mécanismes de synchronisation en Java. Les amis dans le besoin peuvent se référer à

La conception de ThreadLocal

.

Jetez d'abord un coup d'œil à l'interface de ThreadLocal :

Object get() ; // 返回当前线程的线程局部变量副本 protected Object
initialValue(); // 返回该线程局部变量的当前线程的初始值          
void set(Object value); // 设置当前线程的线程局部变量副本的值

ThreadLocal a 3 méthodes, dont la plus remarquable est initialValue(), qui est une méthode protégée, évidemment spécifiquement implémentée pour le remplacement de sous-classe. Cette méthode renvoie la valeur initiale de la variable locale du thread actuel dans le thread. Cette méthode est une méthode d'appel retardée qui est exécutée lorsqu'un thread appelle get() ou set(Object) pour la première fois, et n'est exécutée qu'une seule fois. L'implémentation réelle dans ThreadLocal renvoie directement un null :

protected Object initialValue() { return null; }

Comment ThreadLocal conserve-t-il une copie de la variable pour chaque thread ? En fait, l'idée d'implémentation est très simple. Il y a une Map dans la classe ThreadLocal, qui sert à stocker une copie des variables de chaque thread.

Par exemple, l'exemple d'implémentation suivant : Cela équivaut à stocker une Map. Il s'agit de l'implémentation de la méthode get de ThreadLocal. >Comparaison de ThreadLocal et d'autres mécanismes de synchronisation

public T get() {
    Thread t = Thread.currentThread();//获取当前线程
    ThreadLocalMap map = getMap(t);
    if (map != null) {
      ThreadLocalMap.Entry e = map.getEntry(this);
      if (e != null)
        return (T)e.value;
    }
    return setInitialValue();
  }
  
  
   ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
  }

Quels sont les avantages de ThreadLocal par rapport aux autres mécanismes de synchronisation ? ThreadLocal et tous les autres mécanismes de synchronisation sont conçus pour résoudre les conflits d'accès à la même variable dans plusieurs threads. Dans les mécanismes de synchronisation ordinaires, le verrouillage d'objet est utilisé pour obtenir un accès sécurisé à la même variable par plusieurs threads. À ce stade, la variable est partagée par plusieurs threads. L'utilisation de ce mécanisme de synchronisation nécessite une analyse très détaillée du moment où lire et écrire la variable, quand verrouiller un objet, quand libérer le verrou de l'objet, etc. Tout cela est dû au fait que plusieurs threads partagent des ressources. ThreadLocal résout l'accès simultané de plusieurs threads sous un autre angle. ThreadLocal conservera une copie des variables liées au thread pour chaque thread, isolant ainsi les données de plusieurs threads. Chaque thread a sa propre copie des variables. pas besoin de synchroniser la variable. ThreadLocal fournit un objet partagé thread-safe. Lors de l'écriture de code multithread, vous pouvez encapsuler l'intégralité de la variable non sécurisée dans ThreadLocal ou encapsuler l'état spécifique au thread de l'objet dans ThreadLocal.
Puisque ThreadLocal peut contenir des objets de n'importe quel type, l'utilisation de ThreadLocal pour obtenir la valeur du thread actuel nécessite une

conversion de type

forcée. Mais avec l'introduction des modèles dans la nouvelle version Java (1.5), la nouvelle classe ThreadLocal qui prend en charge les paramètres des modèles en bénéficiera. Il est également possible de réduire la conversion de type forcée et d'avancer certaines vérifications d'erreurs au moment de la compilation, ce qui simplifiera dans une certaine mesure l'utilisation de ThreadLocal.

Résumé

Bien entendu, ThreadLocal ne peut pas remplacer le mécanisme de synchronisation, et les deux domaines problématiques sont différents. Le mécanisme de synchronisation consiste à synchroniser l'accès simultané de plusieurs threads aux mêmes ressources et constitue un moyen efficace de communiquer entre plusieurs threads ; ThreadLocal consiste à isoler le partage de données de plusieurs threads et n'est pas fondamentalement partagé entre plusieurs threads (variables). donc bien sûr, il n'est pas nécessaire de synchroniser plusieurs threads. Par conséquent, si vous avez besoin de communiquer entre plusieurs threads, utilisez le mécanisme de synchronisation ; si vous devez isoler les conflits de partage entre plusieurs threads, vous pouvez utiliser ThreadLocal, ce qui simplifiera grandement votre programme et le rendra plus lisible et concis.

Utilisations courantes de ThreadLocal :

Stocker l'utilisateur de la session actuelle
Stocker certaines variables de contexte, telles que ActionContext de webwork Sessions de magasin, telles que la session Spring Hibernate orm

Exemple : utilisez ThreadLocal pour implémenter Singleton par thread

Les variables locales de thread sont souvent utilisées pour décrire des "monades" avec état " (Singletons) ) ou un objet partagé thread-safe, soit en encapsulant l'intégralité de la variable non sécurisée dans un ThreadLocal, soit en encapsulant l'état spécifique au thread de l'objet dans un ThreadLocal. Par exemple, dans une application étroitement liée à une base de données, de nombreuses méthodes du programme peuvent avoir besoin d'accéder à la base de données. Il n'est pas pratique d'inclure une connexion comme paramètre dans chaque méthode du système - utiliser une "monade" pour accéder à la connexion est probablement une technique plus grossière, mais beaucoup plus pratique. Cependant, plusieurs threads ne peuvent pas partager en toute sécurité une connexion JDBC. Comme le montre le listing 3, en utilisant ThreadLocal dans une « monade », nous pouvons permettre à n'importe quelle classe de notre programme d'obtenir facilement une référence à une connexion par thread. De cette façon, nous pouvons considérer ThreadLocal comme nous permettant de créer des monades par thread.

Un moyen simple d'implémenter la sécurité des threads de la connexion Mysql

Théoriquement parlant, ThreadLocal est bien relatif à chaque thread, et chaque thread aura son propre ThreadLocal. Mais comme mentionné ci-dessus, les serveurs d'applications généraux maintiennent un pool de threads. Par conséquent, les accès de différents utilisateurs peuvent recevoir le même fil de discussion. Par conséquent, lorsque vous effectuez une opération basée sur TheadLocal, vous devez faire attention à éviter la mise en cache des variables ThreadLocal, ce qui obligerait d'autres threads à accéder aux variables de ce thread.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!