Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you what are several misunderstandings about ThreadLocal. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

The java.lang.ThreadLocal,ThreadLocal provided in the version of JDK 1.2 provides a new way to solve the concurrency problem of multithreaded programs. Using this utility class, you can write beautiful multithreaded programs very succinctly. ThreadLocal is not a Thread, but a local variable of Thread.

Recently, due to the need to use ThreadLocal, I searched some relevant materials on the Internet and found that there are often the following misunderstandings about ThreadLocal.

1. ThreadLocal is an implementation of java thread

It is true that ThreadLocal is related to java threads, but it is not an implementation of Java threads, it is just used to maintain local variables. Each thread provides its own version of variables, mainly to avoid thread conflicts, and each thread maintains its own version. Independent of each other, the modification will not affect each other.

Second, ThreadLocal is relative to each session.

ThreadLocal, as its name implies, is for threads. In java web programming, each user has its own session identity from the beginning to the end of the session. But ThreadLocal is not at the session level. In fact, Threadlocal is independent of the user session. It is a server-side behavior that maintains its own ThreadLocal each time the server generates a new thread.

For this misunderstanding, I think it should be the result of developers testing based on some application servers locally. It is well known that the average application server maintains a set of thread pools, that is, a new thread is not necessarily generated for each visit. Instead, you have your own thread cache pool. For access, first find the existing thread from the cache pool, and then generate a new thread if it has been used up.

Therefore, because the developer is generally only testing by himself, the burden on the server is very small, which leads to the possibility of sharing the same thread for each access, leading to the misunderstanding that each session has a ThreadLocal.

3. ThreadLocal is relative to each thread, and users will have a new ThreadLocal each time they visit.

In theory, ThreadLocal is indeed relative to each thread, each thread will have its own ThreadLocal. But as mentioned above, the average application server maintains a set of thread pools. Therefore, different users may receive the same thread for access. Therefore, when doing TheadLocal-based work, care should be taken to avoid caching ThreadLocal variables, causing other threads to access this thread variable.

4. ThreadLocal can be used to access each user.

It can be said that ThreadLocal is a double-edged sword, if it can be used, it can play a very good effect. However, if ThreadLocal is not used well, it will be the same as a global variable. The code cannot be reused and cannot be tested independently. Because some classes that could have been reused now rely on ThreadLocal variables. In other cases where there is no ThreadLocal, these classes become unavailable. Personally, I think there are several applications where ThreadLocal is well used, which are worth referring to.

1. Store the jert of the current session user: quake want

2. Store some context variables, such as webwork's ActionContext

3. Store session, such as session of Spring hibernate orm

These are the several misunderstandings of ThreadLocal shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.