ThreadLocal is introduced:

  • ThreadLocal provided the thread local variable for each thread can get/set methods to perform operations on data to a local variable, not conflict and other threads of local variables, implements the thread data isolation, such as supermarket public store content ark, everybody can use, but everyone is a separate items

ThreadLocal implementation principle:

  1. When ThreadLocal’s set method is called, getMap is called, the current thread is passed in, and ThreadLocalMap is returned

    • This ThreadLocalMap is actually a Map that exists in the Thread class

  2. Once you get a ThreadLocalMap, you put yourself (ThreadLocal) as the key and your value as the value into the ThreadLocalMap, thus isolating data between threads

Question time:

What is the use of Thread? Or where are the application scenarios?

  • ThreadLocal is rarely used in projects. In Spring, there is an implementation of ThreadLocal. ThreadLocal stores a Map of each Entry. The Key in an Entry stores a DataSource, and the Value stores a Connection. ThreadLocal is used to ensure that a thread obtains a Connection object, thus ensuring that all operations in a transaction are on the same database Connection

A ThreadLocalMap is defined in a Thread. If a ThreadLocalMap is defined in a Thread, the current Thread will be the key and the value will be the value. The diagram below:

  • In theory, yes,But consider the following three points
    1. Each thread has multiple private variables, and since the current thread is the Key, you need to distinguish between multiple variables and maintain an identity
    2. Even if the problem of maintaining identifiers is solved, if the concurrency is large enough and multiple threads access the Map to access their own stored private variables, the Map volume may expand, resulting in a decrease in Map access performance
    3. And the Map maintains private variables for all threads, so when can it be destroyed

Why does a key point to a ThreadLocal object with a weak reference? What is a weak reference?

  • First, let’s take a look at the four Java references:Java has strong, soft, weak, and virtual references
    1. Strong reference: Strong references to an object that are not set to NULL are not collected during GC
    2. SoftReference: if there is enough memory, the object to which the reference refers will not be reclaimed; if there is no memory, the object to which the reference refers will be reclaimed
    3. WeakReference: as soon as GC is triggered, the object to which the reference refers is reclaimed
    4. Virtual reference: The main purpose of a virtual reference is to track the status of a garbage collection, and to notify the class through the reference queue when it is collected.
  • Second, why use weak references to point to ThreadLocal objects
    • If the key uses a strong reference to a ThreadLocal object, then when the reference between the Thread and the ThreadLocal object is broken, and since the ThreadLocalMap exists in the Thread, as long as the Thread does not disappear, The ThreadLocalMap will never disappear, and the entry will always exist in the ThreadLocalMap causing a memory leak
    • When a ThreadLocal reference is broken, the reference between the key and ThreadLocal will automatically disappear without any memory leaks
  • When a ThreadLocal object is recycled, the key value is null, and the corresponding value cannot be accessed. In this case, memory leaks can occur
    • Memory leak: An unused chunk of memory that can never be reclaimed
    • Out of memory (OOM) : When the memory is used up, more and more requests are made for the memory

ThreadLocal can leak memory, so will it leak memory for a long time?

  • This is not true because threadLocalMaps belong to threads. If a Thread is destroyed, the ThreadLocalMap will be destroyed as well. When the key is found to be null, it is cleared, so you don’t have to worry about long-term memory leaks
  • What are the conditions under which chronic memory leaks occur? The following conditions must be met simultaneously to cause chronic memory leaks
    1. ThreadLocal recycled
    2. Thread reuse (in a thread pool environment)
    3. The set/get/remove methods of ThreadLocal are no longer invoked after the thread is reused

So, with all that said, did you fail? Don’t leave without a “like”