Several misunderstandings of threadlocal

Recently, because of the need to use threadlocal, on-line search for some relevant information, found that threadlocal often have the following several misunderstandings

One, threadlocal is an implementation of Java thread
Threadlocal is really about Java threading, but it's not an implementation of Java threads, it's just for maintaining local variables. For each thread, provide its own version of the variable, primarily to avoid thread conflicts, each thread maintains its own version. Independent of each other, modification will not affect the other side.

Second, the threadlocal is relative to each session

Threadlocal, as the name implies, is for threading. In Javaweb programming, each user has its own session ID from the beginning to the end of the session. But threadlocal is not on the conversation layer. In fact, Threadlocal is independent of the user session. It is a server-side behavior that maintains its own threadlocal when the server generates a new thread. For this misconception, the individual should be the result of a developer's local test based on some application servers. As we all know, the general application server maintains a set of thread pools, that is, for each access, it does not necessarily become a new thread. Instead, you have a thread cache pool. For access, the existing thread is first found in the cache pool, and if it has been exhausted, it will be reborn into a new thread. So, because the developer himself in the test, usually only himself in the measurement, so that the burden of the server is very small, so that each access may be shared with the same thread, resulting in a misunderstanding: each session has a threadlocal

Third, the threadlocal is relative to each thread, the user each access will have the new threadlocal

Theoretically, threadlocal is indeed relative to each thread, and each thread will have its own threadlocal. But as mentioned above, the general application server will maintain a set of thread pools. As a result, different user access may be subject to the same thread. Therefore, when doing theadlocal-based, it is prudent to avoid the caching of threadlocal variables, causing other threads to access this thread variable

Four, for each user access, threadlocal can be used more
It can be said that Threadlocal is a double-edged sword, the use of words can play a very good effect. However, if the threadlocal is not used well, it will be the same as the global variable. Code cannot be reused and cannot be tested independently. Because, some classes that could have been reused now depend on the threadlocal variable. If there are no threadlocal occasions, these classes become unusable. A few applications that a person feels threadlocal used well are worth reference

1, store the current session User: Quakewant's Jert

2. Store some context variables, such as WebWork's Actioncontext

3, storage session, such as Springhibernate ORM session

Several misunderstandings of threadlocal