Threadlocal notes for Java

Source Address; http://sishuok.com/forum/blogPost/list/340.html

First, threadlocal is not used to solve the problem of multi-threaded access to shared objects. Generally, threadlocal is used. the objects from set () to the thread are the objects used by the thread. Other threads do not need to be accessed or cannot be accessed.Different threads access different objects.

In addition, threadlocal enables each thread to maintain an independent object instead of threadlocal. set () is implemented, but through the operation of the new object in each thread. Each thread creates one object, not a copy or copy of the object.Through threadlocal. set () saves the reference of the newly created object to a map of each thread. Each thread has such a map and runs threadlocal. in get (), each thread extracts the objects from its own map, so it obtains the objects in its own thread, and the threadlocal instance is used as the map key.

If threadlocal. set () is the same object shared by multiple threads, so threadlocal of multiple threads. get () still gets the shared object itself, but there are still concurrent access problems.

Here is a typical threadlocal application in hibernate:

 

Java code:

View copies to clipboard and print

1. Private Static final threadlocal threadsession = new threadlocal ();
3. Public static session getsession () throws infrastructureexception {
4. Session S = (Session) threadsession. Get ();
5. Try {
6. If (S = NULL ){
7. S = getsessionfactory (). opensession ();
8. Threadsession. set (s );
9. }
10. } Catch (hibernateexception ex ){
11. Throw new infrastructureexception (Ex );
12. }
13. Return S;
14. }

You can see that in the getsession () method, first check whether the current thread has been put into the session. If not, use sessionfactory (). opensession () creates a session and then sets the session to the thread. It is actually placed in the map threadlocalmap of the current thread, the only reference to this session is the threadlocalmap in the current thread (as described below), and threadsession is the key of this value. To obtain this session, you can use threadsession. get () to get the threadlocalmap in the current thread, and then take threadsession as the key to get the corresponding value. This session is equivalent to the private variable of the thread, rather than the public variable.
Obviously, this session cannot be obtained in other threads, and they can only get things in their own threadlocalmap. If the session is shared by multiple threads, it will not be messy.
Imagine how to implement it without threadlocal? It may be troublesome to create a session in the action and upload the session to the service and Dao one by one. Alternatively, you can define a static map by yourself and put the current thread as the key and session created as the value into the map. This is also the idea of the average person, but in fact, the implementation of threadlocal is the opposite. It has a map in each thread, and the threadlocal instance is used as the key, so that the number of items in each map is very small, in addition, when the thread is destroyed, the corresponding items are also destroyed. I don't know what other benefits are there.

In short, threadlocal is not used to solve the problem of shared object access, but mainly provides methods to keep objects and convenient object access methods to avoid passing parameters. Two points are summarized:
1. Each thread has its own threadlocalmap class object, which can keep the thread's own objects in it. The thread can correctly access its own objects in various tubes.
2. Use a shared threadlocal static instance as the key, save the references of different objects to threadlocalmap of different threads, and then run get () of the static threadlocal instance everywhere () method to get the object saved by the thread, avoiding the trouble of passing this object as a parameter.

Of course, if you want to pass the thread-shared object through threadlocal. set () can also be placed in the thread to avoid the access method passed by parameters. However, note that get () is the same shared object, concurrent access problems must be solved by other means. But in general, the objects shared by the thread can be easily accessed by setting them to a certain type of static variables. It seems that there is no need to put them in the thread.

In the Application Scenario of threadlocal, I think it is best to access objects with multiple threads (each thread corresponds to an instance), and this object is used in many places.