I just learned about ThreadLocal this morning. I read that it should always be final and static like:
private static final ThreadLocal<Session> threadLocal = new ThreadLocal<Session>();
(Session is a Hibernate Session)
My confusion is this: Because it is static, it is available to any thread in the JVM. Yet it will hold information local to each thread which accesses it? I'm trying to wrap my head around this so I apologize if this is unclear. Each thread in the application has access to the same ThreadLocal object, but the ThreadLocal object will store objects local to each thread?
ThreadLocal is useful, when you want to have some state that should not be shared amongst different threads, but it should be accessible from each thread during its whole lifetime. As an example, imagine a web application, where each request is served by a different thread.
You should always call remove because ThreadLocal class puts values from the Thread Class defined by ThreadLocal. Values localValues; This will also cause to hold reference of Thread and associated objects. the value will be set to null and the underlying entry will still be present.
The Java ThreadLocal class enables you to create variables that can only be read and written by the same thread. Thus, even if two threads are executing the same code, and the code has a reference to the same ThreadLocal variable, the two threads cannot see each other's ThreadLocal variables.
The reason is that the variables are accessed via a pointer associated with the thread. They act like global variables with thread scope, hence static is the closest fit. This is the way that you get thread local state in things like pthreads so this might just be an accident of history and implementation.
Yes, the instance would be the same, but the code attaches the value you set with the Thread.currentThread()
, when you set and when you retrieve, so the value set will be accessible just within the current thread when accessed using the methods set
and get
.
Its really easy to understand it.
Imagine that each Thread
has a map that associates a value to a ThreadLocal
instance. Every time you perform a get or a set on a ThreadLocal
, the implemention of ThreadLocal
gets the map associated to the current Thread
(Thread.currentThread()
) and perform the get
or set
in that map using itself as key.
Example:
ThreadLocal tl = new ThreadLocal();
tl.set(new Object()); // in this moment the implementation will do something similar to Thread.getCurrentThread().threadLocals.put(tl, [object you gave])
Object obj = t1.get(); // in this moment the implementation will do something similar to Thread.getCurrentThread().threadLocals.get(tl)
And the interesting thing on this is that the ThreadLocal
is hierarchic, meaning if you defined a value for a parent Thread
it will be accessible from a child one.
You always access the same instance of ThreadLocal for a specific problem but this instance returns a different value for each thread calling the get method.
That's the point : it's easy to find the object but each thread will have its specific own value. Thus you can for example make sure your specific value won't be accessed by two different threads.
You could see it (conceptually) as a kind of HashMap<Thread><V>
which would always be accessed with Thread.currentThread()
as key.
Because the thread-specific values are not stored in the ThreadLocal
object, but the current Thread's ThreadLocalMap
. The ThreadLocal
object merely serves as key in these maps.
For details, read the JavaDoc of ThreadLocal
and subclasses, or, if you are curious about the implementation, the source code available in every recent JDKs src.zip.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With