[Conception] Thread local

Version imprimable

22/01/2007, 13h44
smutmutant2003

[Conception] Thread local

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
23/01/2007, 12h58
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 ;) .

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:

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

23/01/2007, 14h20
1tox

erratum: ThreadLocal existe depuis la JDK1.2
23/01/2007, 14h21
sironimo

Tu sais tu peux éditer tes posts c'est plus pratique des fois ;)
26/01/2007, 11h03
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 :mouarf:
Quand tu dis

Citation:

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.

:merci:
26/01/2007, 14h13
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 ?
26/01/2007, 16h10
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
29/01/2007, 21h04
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 ...