Design and use of threadlocal

As early as Java 1.2 was launched, a new support was introduced in the Java platform: java.lang.ThreadLocal, which provided us with a new option for multithreaded programming. This tool class can be very concise to write a graceful multithreaded program, although threadlocal is very useful, but seems to understand it now, the use of its friends are not many.

What's threadlocal?

What is threadlocal? In fact, Threadlocal is not a local implementation version of a thread, it's not a threads, it's thread local variable. Perhaps it would be more appropriate to name it Threadlocalvar. A thread-local variable (ThreadLocal) is very simple in that it provides a copy of the variable value for each thread that uses the variable, and each thread can independently alter its own copy without conflict with the replica of the other thread. From a thread's point of view, it's as if every thread owns the variable entirely. Thread-local variables are not a new Java invention, and in other language compiler implementations (such as IBM XL FORTRAN), it provides direct support at the language level. Because Java does not provide direct support at the language level, but rather provides a threadlocal class to support, the code to write thread-local variables in Java is relatively clumsy, perhaps one reason why thread-local variables are not well popularized in Java.

Design of Threadlocal

First look at the Threadlocal interface:

Object get (); Returns the thread local variable copy of the current thread protected Object initialvalue (); Returns the initial value void set (Object value) of the current thread of the thread local variable; Sets the value of a copy of the thread local variable for the current thread

Threadlocal has 3 methods, notably InitialValue (), which is a protected method that is explicitly implemented for subclass rewriting. This method returns the initial value of the current thread's local variable in the thread, which is a deferred invocation method that executes only 1 times when a thread calls get () or set (Object) for the 1th time. A true implementation in threadlocal returns a null directly:

Protected Object InitialValue () {return null;}

How does threadlocal maintain a copy of a variable for each thread? In fact, the idea of implementation is very simple, in the Threadlocal class has a map, used to store a copy of each thread's variables. For example, the following examples implement:

public class ThreadLocal
{
　 private Map values = Collections.synchronizedMap(new HashMap());
　 public Object get()
　 {
　　 Thread curThread = Thread.currentThread();
　　 Object o = values.get(curThread);
　　 if (o == null && !values.containsKey(curThread))
　　 {
　　　 o = initialValue();
　　　 values.put(curThread, o);
　　 }
　　 return o;
　 }
　 public void set(Object newValue)
　 {
　　 values.put(Thread.currentThread(), newValue);
　 }
　 public Object initialValue()
　 {
　　 return null;
　 }
}

This is not an industrial strength, of course, but the overall idea of threadlocal in the JDK is similar.