{"id":336,"date":"2011-12-04T20:44:35","date_gmt":"2011-12-04T19:44:35","guid":{"rendered":"http:\/\/doanduyhai.wordpress.com\/?p=336"},"modified":"2011-12-04T20:44:35","modified_gmt":"2011-12-04T19:44:35","slug":"threadlocal-explained","status":"publish","type":"post","link":"https:\/\/www.doanduyhai.com\/blog\/?p=336","title":{"rendered":"ThreadLocal explained"},"content":{"rendered":"

Today we are going to look into the ThreadLocal internals, its usage and all the related pitfalls.<\/p>\n

ThreadLocal, among other Java advanced features like volatile<\/strong> variables or nested<\/strong> classes, is rarely used.<\/p>\n

The main reason is its relative<\/em> complexity and mostly the very few cases where ThreadLocal is really required.<\/p>\n

Yet, if its underlying mechanism is well understood, ThreadLocal can be very handy in some situations. No wonder it is at the heart of some framework features, Spring
\nTransactionSynchronizationManager<\/strong> for example.
\n
\n <\/p>\n

I Usage<\/h1>\n

A Global design<\/h3>\n

ThreadLocal is an alternative to the usage of global variable passed from methods to methods as argument (brute force technique) or static variable (visible within the current ClassLoader).<\/p>\n

However, unlike global<\/strong> or static<\/strong> variable, the ThreadLocal scope is limited to the execution of the current thread<\/em>, thus its name. A ThreadLocal attached to Thread1 cannot be access by Thread2 and vice versa. This thread isolation makes ThreadLocal thread-safe<\/em> by nature, unlike static variables which need synchronization (thus performance overhead)<\/p>\n

A ThreadLocal is composed of the ThreadLocal object itself and a value Object we’ll refer to as target Object<\/strong> for the rest of this article.<\/p>\n

A ThreadLocal object is created, then attached to the current thread. All portion of your program executed by the current thread can access the ThreadLocal target Object, provided that the code can access the ThreadLocal reference<\/strong>, and that’s the trick! There is no point creating a ThreadLocal if it cannot be accessed everywhere in your code.<\/p>\n

Most of the time, the ThreadLocal object itself is created as a static final<\/strong> variable. Static to make it accessible from everywhere and final to avoid being modified. There is no need to synchronize the access to the ThreadLocal object itself since only the target Object is usefull and this object is different from one thread to another (so thread-safe<\/em> by nature)<\/p>\n

B Example<\/h3>\n
\npackage test;\n\npublic class ThreadLocalManager\n{\n\tpublic static final ThreadLocal myThreadLocal = new ThreadLocal();\n}\n\npublic class TestThreadLocal implements Runnable\n{\n\n\tprivate String value;\n\tprivate long delayTime;\n\tprivate long sleepTime;\n\n\tpublic TestThreadLocal(String value, long delayTime, long sleepTime) {\n\t\tthis.value = value;\n\t\tthis.delayTime = delayTime;\n\t\tthis.sleepTime = sleepTime;\n\t}\n\n\t@Override\n\tpublic void run()\n\t{\n\n\t\ttry\n\t\t{\n\t\t\tThread.sleep(this.delayTime);\n\t\t\tSystem.out.println(&quot;[&quot; + this + &quot;] is setting myThreadLocal [&quot; + ThreadLocalManager.myThreadLocal + &quot;] the value : &quot; + this.value);\n\t\t\tThreadLocalManager.myThreadLocal.set(this.value);\n\t\t\tThread.sleep(this.sleepTime);\n\t\t\tSystem.out.println(&quot;[&quot; + this + &quot;] is accessing myThreadLocal [&quot; + ThreadLocalManager.myThreadLocal + &quot;] value : &quot;\n\t\t\t\t\t+ ThreadLocalManager.myThreadLocal.get());\n\t\t}\n\t\tcatch (InterruptedException e)\n\t\t{\n\t\t\te.printStackTrace();\n\t\t}\n\n\t}\n\n\tpublic static void main(String[] args)\n\t{\n\t\tTestThreadLocal test1 = new TestThreadLocal(&quot;V1&quot;, 0, 200);\n\t\tSystem.out.println(&quot;Creating test1 : &quot; + test1);\n\t\tTestThreadLocal test2 = new TestThreadLocal(&quot;V2&quot;, 100, 500);\n\t\tSystem.out.println(&quot;Creating test2 : &quot; + test2);\n\t\tThread t1 = new Thread(test1);\n\t\tThread t2 = new Thread(test2);\n\n\t\tt1.start();\n\t\tt2.start();\n\t}\n\n}\n<\/pre>\n
The produced output is:
\n
\nCreating test1 : test.TestThreadLocal@30c221<\/strong>
\nCreating test2 : test.TestThreadLocal@1e5e2c3<\/strong><\/code><\/p>\n
[test.TestThreadLocal@30c221<\/strong>] is setting myThreadLocal [java.lang.ThreadLocal@f72617<\/strong>] the value : V1
\n[test.TestThreadLocal@1e5e2c3<\/strong>] is setting myThreadLocal [java.lang.ThreadLocal@f72617<\/strong>] the value : V2
\n[test.TestThreadLocal@30c221<\/strong>] is accessing myThreadLocal [java.lang.ThreadLocal@f72617<\/strong>] value : V1
\n[test.TestThreadLocal@1e5e2c3<\/strong>] is accessing myThreadLocal [java.lang.ThreadLocal@f72617<\/strong>] value : V2<\/p>\n
Although the execution of both threads is tangled, the output message clearly show that the ThreadLocal value is completely isolated between threads t1<\/em> & t2<\/em>.
\n <\/p>\n
II Code analysis<\/h1>\n
A Class diagram<\/h3>\n
Below is a class diagram of all objects related to ThreadLocal. This diagram has been designed reversing from openjdk 6-b14<\/strong> source code.<\/p>\n
\"\"<\/a><\/p>\n
ThreadLocalMap<\/strong> is a static inner class inside ThreadLocal<\/strong> class
\nThreadLocalMap.Entry<\/strong> is a static inner class inside ThreadLocalMap<\/strong> class and extending WeakReference<\/strong> class<\/p>\n
A Thread<\/strong> has a package protected threadLocals<\/em> variable of type ThreadLocal.ThreadLocalMap<\/strong>
\nA ThreadLocalMap<\/strong> has a private table<\/em> variable which is an array of Entry<\/strong> objects<\/p>\n
The ThreadLocal<\/strong> class itself is not extending nor aggregating any above class. Thus it is in relation with Thread<\/strong> and ThreadLocalMap<\/strong> classes<\/p>\n
The ThreadLocal<\/strong> class exposes the following methods:<\/p>\n