aspose file tools*
The moose likes Threads and Synchronization and the fly likes ThreadLocal variable and static TL variable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "ThreadLocal variable and static TL variable" Watch "ThreadLocal variable and static TL variable" New topic
Author

ThreadLocal variable and static TL variable

Tejas Aryan
Greenhorn

Joined: Apr 12, 2009
Posts: 22
I have gone through many articles and tried to understand the ThreadLocal variable and what happens when ThreadLocal variable is declared as static. As I understand, thread local variables are local to each threads. But I am not able to understand how a static thread local variable would behave in such context.

Please put in your understanding to help me understand better.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

There is no such a distinction as a "static TL variable". A thread local instance can be referenced by an instance variable or a static variable; Or even both at the same time. The difference in behavior is the same difference in behavior applied to any other object.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1771
    
    7

You seem to understand what a ThreadLocal variable is. From the from the JavaDoc:

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread.


What do you know about static variables and instance variables, how do they differ? Given that, why would the JavaDoc state that "ThreadLocal instances are typically private static"?

Edit: Ugh ninja'ed by Henry ;)


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Jelle Klap wrote:
Edit: Ugh ninja'ed by Henry ;)



Sorry...

Amazing timing though -- 20 hours without an answer, then 2 responses within 5 minutes.

Henry
Dmitry Zhuravlev
Ranch Hand

Joined: Apr 14, 2010
Posts: 93
Actually this old topic looks interesting for me.

As we know static variable has only one instance - instance bound with the class object instance.

But static ThreadLocal variable can have many instances per class! Of course, actually these instances are hidden inside one reference to ThreadLocal, for example:


- this line of code will produce one myThreadLocal reference as usual for static variables, but many Integer instances for each of the threads accessing it.. So actually this looks like a special static variable that can have many instances per class.. Probably this fact surprised the topic starter. Concurrency Gurus, please correct me if I am wrong.

(Yes, I see the dates. Just some personal interest for ThreadLocals)
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Dmitry Zhuravlev wrote:
So actually this looks like a special static variable that can have many instances per class..


Not per class but per thread. You can think of a TL as a Map where the key is the thread ID and the value is the value of the variable per thread.
So, conceptually the variable contains multiple values (just like any other collection variable), whether the multiple values have affinity with a thread or not is not something that is important in reference to a static or non-static TL.

apigee, a better way to API!
assert assertion
Greenhorn

Joined: Jul 14, 2011
Posts: 8
I think a static TL will have exactly the same behavior as a member TL variable. However a member TL variable cannot be accessed from a static method. Static TL variables are to support static methods .
ramesh vanka
Greenhorn

Joined: Mar 13, 2005
Posts: 11
ThreadLocal instance associated Thread,
run(){
ThreadLocal a = new ThreadLocal();
a.set(Thread.currentThread().getName());
}
Two threads t1,t2 threads are running.
T1 Scenario:
ThreadLocal internally maintain map. In map(KEY, VALUE) ,
KEY = THREAD IDENTIFIER,Based thread hashcode and some logic, it will generate the Thread Identifier
Value= a.set(Thread.currentThread().getName());

so when ever T1 issues t1.get(), first it will check internal map, In the map it have thread identifier it will give the value.

T1 Scenario:
Same like that.

Hope It will clear the doubts.

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

ramesh vanka wrote:ThreadLocal instance associated Thread,
run(){
ThreadLocal a = new ThreadLocal();
a.set(Thread.currentThread().getName());
}
Two threads t1,t2 threads are running.
T1 Scenario:
ThreadLocal internally maintain map. In map(KEY, VALUE) ,
KEY = THREAD IDENTIFIER,Based thread hashcode and some logic, it will generate the Thread Identifier
Value= a.set(Thread.currentThread().getName());

so when ever T1 issues t1.get(), first it will check internal map, In the map it have thread identifier it will give the value.

T1 Scenario:
Same like that.

Hope It will clear the doubts.




Using the analogy that the ThreadLocal class maintaining a map, with the calling thread as a key is actually a good way to remember what it does. However, this is not how the implementation works -- the ThreadLocal class actually stores the value in the Thread object, so while the threadlocal class will use the thread object, but there is no reason to hash the thread object.

Henry
Eduardo Moranchel
Greenhorn

Joined: Jul 31, 2012
Posts: 5
The way i understand it:

A thread local is a class.
It has a value per thread.
It is a key/value store where the key is the Thread ID and the value is whatever we put inside
Wait. is it... like a map?
maybe. lets think it this way.
All threads have a unique ID, that can be the key of the map.
And we store a value inside.
So we can say a ThreadLocal can be actually a Map<ThreadId, ValueType> variable.
but handling maps and stuff is bad and boring so why not disguise it with ThreadLocal<ValueType>
ok now then how do we get the id?
Thread.getCurrentThread().getId ? something like that exists actually.
So there you have it. how ThreadLocals work.

Being static is just in case you want to access it from different objects regardless of where they are (a convenient way of passing the variable around) but is in no way mandatory.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Eduardo Moranchel wrote:The way i understand it:

A thread local is a class.
It has a value per thread.
It is a key/value store where the key is the Thread ID and the value is whatever we put inside
Wait. is it... like a map?
maybe. lets think it this way.
All threads have a unique ID, that can be the key of the map.
And we store a value inside.
So we can say a ThreadLocal can be actually a Map<ThreadId, ValueType> variable.
but handling maps and stuff is bad and boring so why not disguise it with ThreadLocal<ValueType>
ok now then how do we get the id?
Thread.getCurrentThread().getId ? something like that exists actually.
So there you have it. how ThreadLocals work.


Actually, that is not how threadlocals work -- it is just easier to think of it as a map that routes values based on the thread id as the key.... meaning you can envision it that way. It is not a disguised map.

As already mentioned, the ThreadLocal class actually stores the values internally in the Thread object that represents the thread. The data is actually not stored in the ThreadLocal object.

Henry
tushar pagar
Greenhorn

Joined: Aug 30, 2012
Posts: 1

I agree with Henry.
If ThreadLocal was a map, then it would be difficult accessing it concurrently. This will have a performance hit as all threads who are trying to set ThreadLocal will have to synchronize over the threadlocal object.
ramesh vanka
Greenhorn

Joined: Mar 13, 2005
Posts: 11

I am pasting here inside ThreadLocal snippet:

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();
}

public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}

void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}


run(){
ThreadLocal a = new ThreadLocal();
a.set(Thread.currentThread().getName());
}
Two threads t1,t2 threads are running.
T1 Scenario:
ThreadLocal internally maintain map. In map(KEY, VALUE) ,

My Comments:
When the user called a.set(Thread.currentThread().getName()) Initially,
1) if it will check corresponding thread's any threadlocalmap is there or not
2) For 1st time corresponding threadlocalmap is null, so that it will call createMap(Thread t, T firstValue) , here you are creating new Threadlocalmap with this ThreadLocal and setter value and assigning to Thread's Threadlocals
like t.threadLocals = new ThreadLocalMap(this, firstValue);

Here parameterized constructor of ThreadLocalMap first argument is ThreadLocal Object. Now you can see the below ThreadLocalMap Constructor

ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}

Inside of ThreadLocalMap it is taking the index as hash of the ThreadLocal only.

3) So when ever you are calling get(Thread t), it will check thread t's threadlocalmap, then it will return value.

Hope it will clear the doubts on the hash...

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ThreadLocal variable and static TL variable