Discussion :

[smutmutant2003]

Bonjour
Quelqu'un pourrait il m'expliquer ce que ce terme veut dire et en quoi ca consiste, et surtout pourquoi on le fait.
Bien cordialement

[eclesia]

Un thread est un thread...

je suposse que le "local" veut dire que c'est une classe anonyme.

Quand a l'utlité d'un thread... il peut tout et rien .

[1tox]

Un thread local est une classe de la JDK5 (ThreadLocal pour la nommer). Cette classe permet de gérer des variables dont l'état dépend d'un contexte (d'un thread). Par exemple, si tu veux créer une classe qui contient un indentifiant unique par thread, comme le montre l'exemple ci-dessous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import java.util.concurrent.atomic.AtomicInteger;
 
 public class UniqueThreadIdGenerator {
 
     private static final AtomicInteger uniqueId = new AtomicInteger(0);
 
     private static final ThreadLocal < Integer > uniqueNum = 
         new ThreadLocal < Integer > () {
             @Override protected Integer initialValue() {
                 return uniqueId.getAndIncrement();
         }
     };
 
     public static int getCurrentThreadId() {
         return uniqueId.get();
     }
 } // UniqueThreadIdGenerator

[1tox]

erratum: ThreadLocal existe depuis la JDK1.2

[sironimo]

Tu sais tu peux éditer tes posts c'est plus pratique des fois

[smutmutant2003]

Tout d'abord messieurs je tiens a vous remercier pour votre participation a ce topic.
Mes connaissances etant limite en java, classe debutant oblige
Quand tu dis

Cette classe permet de gérer des variables dont l'état dépend d'un contexte

Ca veut dire quoi exactement, parce que pour moi l'etat d'une variable est soit utilisee donc active, soit inutilisee donc inactive. D'autre part que vient faire le mot Context que j'ai deja vue ailleurs en J2EE sans vraiment comprendre ce que c'est.
Parles tu de la meme chose ???
Merci pour votre aide.

[chtig]

Rien à voir pour contexte et Context dans ce que disais 1tox.

Je vais essayer une autre approche pour t'expliquer :

Supposons que nous avons un objet (objet1) et que cet objet a un attribu (attribut1). Cet objet correspond d'une certaine manière à un bout de mémoire.
Cet objet peut être utilisé par deux Threads, nommons les thread 1 et thread 2. Ces threads correspondent plus ou moins à des processus différents pour le système, ou plus simplement à des programmes séparés à l'intérieur de ton programme.

Si attribut1 est d'un type quelconque (pas ThreadLocal), alors thread 1 et thread 2 lorsqu'ils parlent de attribut 1 parlent du même emplacement mémoire. Cet emplacement mémoire est donc partagé entre les deux Thread.

En revanche, si attribut1 est un ThreadLocal, il est spécifique à chaque Thread, donc il s'agit de deux zones mémoire différentes pour thread 1 et thread 2.

Petite précision : en fait ce n'est pas le ThreadLocal qui est partagé ou non mais ce que tu mets dedans (voir set et get de ThreadLocal).

C'est plus clair ?

[smutmutant2003]

Je te remercie c'est en effet plus clair.
Toutefois il faut de la pratique pour ce genre de d'appli. Mais alors quel genre d'application pourrait utiliser le thread local et dans quel but??? Quel gain effectif peut on avoir????
PUisqu'en fait tu es en train de me decire une espece de synchronisation, ne peut on pas le faire avec Synchronized ???

Bien Cordialement

[the-gtm]

Dans un serveur d'appli J2EE, en gros un thread = une requête. On peut donc utiliser le ThreadLocal pour associer au thread (et donc à la requête) une transaction, un utilisateur, une connexion base de données etc ...