table of Contents
1. Beans in Spring are singletons by default, which may have thread safety issues.
2. ThreadLocal's way to solve thread safety
Reference article
1), talk about thread safety in Spring
2). Have you ever thought about it. What is the default singleton of Spring Bean?
1. Beans in Spring are singletons by default, which may have thread safety issues.
what is the problem? ----- Stateful beans will have threading problems.
What is a stateful bean? :
- Stateful session bean : each user has its own unique instance. During the lifetime of the user, the bean retains the user's information, that is, "stateful"; once the user dies (the end of the call or the end of the instance), the lifetime of the bean It's over. That is, each user will initially get an initial bean.
- Stateless session bean : Once the bean is instantiated, it is added to the session pool and can be shared by all users. Even if the user has died, the life of the bean may not necessarily end. It may still exist in the session pool for other users to call. Since there is no specific user, the state of a certain user cannot be maintained, so it is called a stateless bean. But a stateless session bean is not stateless. If it has its own properties (variables), then these variables will be affected by all users who call it, which must be paid attention to in practical applications.
2. ThreadLocal's way to solve thread safety
https://mp.csdn.net/console/editor/html/108565112
Overall thought:
Provide a thread-private variable copy for the thread, so that multiple threads can change their own thread-local variables at will without affecting other threads. However, it should be noted that what ThreadLocal provides is only a shallow copy. If the variable is a reference type, then it is necessary to consider whether its internal state will be changed. To solve this problem, you can rewrite the initialValue() function of ThreadLocal. To implement deep copy by yourself, it is recommended to rewrite this function at the beginning when using ThreadLocal.
ThreadLocal is different from a lock mechanism like synchronized. First of all, their application scenarios and implementation ideas are different. The lock emphasizes how to synchronize multiple threads to correctly share a variable. ThreadLocal is to solve how the same variable is not shared by multiple threads. From the perspective of performance overhead, if the lock mechanism uses time for space, then ThreadLocal uses space for time .
3. Memory leak in ThreadLocal
We have to consider a situation where memory leaks will occur
If ThreadLocal is set to null and there is no strong reference to it, ThreadLocal will be recycled according to the reachability analysis algorithm of garbage collection.
In this way, the ThreadLocalMap will contain an Entry with a null key , and the ThreadLocalMap is in the Thread. As long as the thread is not finished, these inaccessible values will cause a memory leak. To solve this problem, the getEntry(), set() and remove() functions in ThreadLocalMap will clean up the Entry whose key is null. Take the source code of the getEntry() function below as an example.
What is a memory leak? Memory overflow? :
- Memory leak means that you apply to the system to allocate memory for use (new), but you do not return it (delete) after you have used it. As a result, you can no longer access the memory you have applied for (maybe you get its address) Lost), and the system cannot allocate it to the required program again.
- Memory overflow means that the memory you requested to allocate exceeds what the system can give you, and the system cannot meet the demand, so overflow occurs.
Source: Memory leak and its solution --- https://zhuanlan.zhihu.com/p/69151763