ThreadLocal principle analysis

Stack and Heap are the Stack and Heap we often say, here not to repeat, just need to note a little knowledge can, Stack is the thread private exclusive and thread-safe, Heap is all threads shared non-thread-safe. TheadLocal is designed to allow threads to have their own internal variables, and each thread is isolated from each other to achieve thread safety.

static class ThreadLocalMap {

    // Entry in hash Map inherits WeakReference and points to threadLocal objects
    // If the key is null, the entry is no longer needed and will be cleared from the table
    // Such entries are called "stale entries"
    static class Entry extends WeakReference<ThreadLocal<? >>{
        /** The value associated with this ThreadLocal. */Object value; Entry(ThreadLocal<? > k, Object v) {super(k); value = v; }}private static final int INITIAL_CAPACITY = 16;

    private Entry[] table;

    private int size = 0;

    private int threshold; // Default to 0

    private void setThreshold(int len) {
        threshold = len * 2 / 3; } ThreadLocalMap(ThreadLocal<? > firstKey, Object firstValue) { table =new Entry[INITIAL_CAPACITY];
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        table[i] = new Entry(firstKey, firstValue);
        size = 1; setThreshold(INITIAL_CAPACITY); }}Copy the code

• ThreadLocalMap is a custom hash map that holds thread local variables
• Its operations are confined to the ThreadLocal class and are not exposed
• This class is used on the private variables threadLocals and inheritableThreadLocals of the Thread class
• WeakReferences are used as the key type for hash table entries in order to hold a large number of long-lived threadLocal instances
• If the hash table runs out of space, entries with null keys will be cleared

private T setInitialValue(a) {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if(map ! =null)
        map.set(this, value);
    else
        createMap(t, value);
    return value;
}
Copy the code

• Call the initialValue method to get the initialValue.
• Gets the ThreadLocalMap inside the current thread
• If the map exists, add the current ThreadLocal and value to the map
• If the map does not exist, create a ThreadLocalMap and store it inside the current thread

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if(map ! =null)
        map.set(this, value);
    else
        createMap(t, value);
}
Copy the code

• Gets the ThreadLocalMap inside the current thread
• If the map exists, add the current ThreadLocal and value to the map
• If the map does not exist, create a ThreadLocalMap and store it inside the current thread

Hash generating algorithm: HASH_INCREMENT is a hexadecimal hash magic number that participates in the hash calculation. In this case, 0x61C88647 is the hexadecimal hash magic number. When converted to hexadecimal, -1640531527 is generated by incrementing HASH_INCREMENT each time

ThreadLocalMap uses the golden number approach, which greatly reduces hash collisions.

• Golden section number: The golden section number of int is calculated by multiplying the maximum value of int by math.sqrt (5) -1) / 2. The golden section number of int is -1640531527.
• Hash magic number: The hash number is changed by HASH_INCREMENT itself. After research, it is found that this will have better hash performance.
• High and low bits: (2 N power -1) the generated numbers have a feature, the high binary is 0, the low binary is 1
• Efficient bitwise and: HASH_INCREMENT increment HASH_INCREMENT increment HASH_INCREMENT increment increment HASH_INCREMENT increment increment HASH_INCREMENT increment increment increment HASH_INCREMENT increment increment increment HASH_INCREMENT increment increment increment increment So it becomes HashCode & (2 to the NTH -1) = HashCode % (2 to the NTH -1), but bitwise and is more efficient than modulo

id:1 	 hashCode:1640531527 	 binary:01100001110010001000011001000111 
id:2 	 hashCode:-1013904242 	 binary:11000011100100010000110010001110 
id:3 	 hashCode:626627285 	 binary:00100101010110011001001011010101 
id:4 	 hashCode:-2027808484 	 binary:10000111001000100001100100011100 
id:5 	 hashCode:-387276957 	 binary:11101000111010101001111101100011 
id:6 	 hashCode:1253254570 	 binary:01001010101100110010010110101010 
id:7 	 hashCode:-1401181199 	 binary:10101100011110111010101111110001 
id:8 	 hashCode:239350328 	 binary:00001110010001000011001000111000 
id:9 	 hashCode:1879881855 	 binary:01110000000011001011100001111111 
id:10 	 hashCode:-774553914 	 binary:11010001110101010011111011000110 
id:11 	 hashCode:865977613 	 binary:00110011100111011100010100001101 
id:12 	 hashCode:-1788458156 	 binary:10010101011001100100101101010100 
id:13 	 hashCode:-147926629 	 binary:11110111001011101101000110011011 
id:14 	 hashCode:1492604898 	 binary:01011000111101110101011111100010 
id:15 	 hashCode:-1161830871 	 binary:10111010101111111101111000101001 
id:16 	 hashCode:478700656 	 binary:00011100100010000110010001110000 
id:17 	 hashCode:2119232183 	 binary:01111110010100001110101010110111 
id:18 	 hashCode:-535203586 	 binary:11100000000110010111000011111110 
id:19 	 hashCode:1105327941 	 binary:01000001111000011111011101000101 
id:20 	 hashCode:-1549107828 	 binary:10100011101010100111110110001100 
id:21 	 hashCode:91423699 	     binary:00000101011100110000001111010011 
id:22 	 hashCode:1731955226 	 binary:01100111001110111000101000011010 
id:23 	 hashCode:-922480543 	 binary:11001001000001000001000001100001 
id:24 	 hashCode:718050984 	 binary:00101010110011001001011010101000 
id:25 	 hashCode:-1936384785 	 binary:10001100100101010001110011101111 
id:26 	 hashCode:-295853258 	 binary:11101110010111011010001100110110 
id:27 	 hashCode:1344678269 	 binary:01010000001001100010100101111101 
id:28 	 hashCode:-1309757500 	 binary:10110001111011101010111111000100 
id:29 	 hashCode:330774027 	 binary:00010011101101110011011000001011 
id:30 	 hashCode:1971305554 	 binary:01110101011111111011110001010010 
id:31 	 hashCode:-683130215 	 binary:11010111010010000100001010011001
Copy the code

The above hashCode is generated 32 times by nexthashcode.getandAdd (HASH_INCREMENT) Since the binary high order of (2 ^ N -1) is all 1 and ampersand, the more hashCode has hash property, the final index value will also have good hash property and the possibility of hash collisions will be reduced. In the case that the binary of (2 ^ N -1) is fixed, that is, the low bits are all 1 and the high bits are all 0. Therefore, if the high and low bits of hashCode are too much the same, serious collisions will occur. Only when the high and low bits of hashCode have very good differences, as shown in the figure above, can collisions be reduced

id:1 	 hashCode:1640531527 	 index:7 
id:2 	 hashCode:-1013904242 	 index:14 
id:3 	 hashCode:626627285 	 index:21 
id:4 	 hashCode:-2027808484 	 index:28 
id:5 	 hashCode:-387276957 	 index:3 
id:6 	 hashCode:1253254570 	 index:10 
id:7 	 hashCode:-1401181199 	 index:17 
id:8 	 hashCode:239350328 	 index:24 
id:9 	 hashCode:1879881855 	 index:31 
id:10 	 hashCode:-774553914 	 index:6 
id:11 	 hashCode:865977613 	 index:13 
id:12 	 hashCode:-1788458156 	 index:20 
id:13 	 hashCode:-147926629 	 index:27 
id:14 	 hashCode:1492604898 	 index:2 
id:15 	 hashCode:-1161830871 	 index:9 
id:16 	 hashCode:478700656 	 index:16 
id:17 	 hashCode:2119232183 	 index:23 
id:18 	 hashCode:-535203586 	 index:30 
id:19 	 hashCode:1105327941 	 index:5 
id:20 	 hashCode:-1549107828 	 index:12 
id:21 	 hashCode:91423699 	     index:19 
id:22 	 hashCode:1731955226 	 index:26 
id:23 	 hashCode:-922480543 	 index:1 
id:24 	 hashCode:718050984 	 index:8 
id:25 	 hashCode:-1936384785 	 index:15 
id:26 	 hashCode:-295853258 	 index:22 
id:27 	 hashCode:1344678269 	 index:29 
id:28 	 hashCode:-1309757500 	 index:4 
id:29 	 hashCode:330774027 	 index:11 
id:30 	 hashCode:1971305554 	 index:18 
id:31 	 hashCode:-683130215 	 index:25 
id:32 	 hashCode:957401312 	 index:0
Copy the code

The above is the case where the index values are generated 32 times when the length is 32. It is found that the index values are evenly distributed and there is no collision.

The reason ThreadLocal uses weak references for Entry keys is to reclaim as soon as possible to avoid taking up a large amount of memory space. In addition, it creatively adds two methods of exploratory clearing and heuristic clearing to reclaim and clear memory objects when core methods such as GET and SET are called

private boolean cleanSomeSlots(int i, int n) {
    boolean removed = false;
    Entry[] tab = table;
    int len = tab.length;
    do {
        // I itself is not an invalid slot in any case, so start with the next one
        i = nextIndex(i, len);
        Entry e = tab[i];
        if(e ! =null && e.get() == null) {
            // Expand the scan control factor
            n = len;
            removed = true;
            // Clear a segmenti = expungeStaleEntry(i); }}while ((n >>>= 1) != 0);
    return removed;
 }
Copy the code

• The slot is cleared heuristically. The entry corresponding to I is non-invalid (the pointed ThreadLocal is not reclaimed or the entry itself is empty), and n is used to control the number of scans
• Normally, if no invalid slot is found in log n scans, the function ends
• If an invalid slot is found, set n to len of the table, clear consecutive segments, and continue scanning from the next empty slot
• This function is called when an insert is being inserted and when an invalid slot is being replaced. This function is called when an insert is being inserted and when an invalid slot is being replaced

To collate object references, use **++>Indicates a strong reference– >** indicates a weak reference

• Thread ++> ThrealLocal.ThreadLocalMap ++> Entry ++> key (referant) –> ThreadLocal
• Thread + + > ThrealLocal. ThreadLocalMap + + > Entry value + + + + > > Object as key (referant) — – > ThreadLocal is weak references, gc will recycle the key, In this case, the key is null, but the Thread, as the Root of the chain of references, does not disappear immediately after the Thread completes execution. Instead, it resides in the Stack. In this case, there are generally two ways: one is executed in a for loop, and the other is executed in a Thread pool. Therefore, strongly referenced values will not be freed, resulting in memory overflow

• If the key of a ThreadLocal is a weak reference, will the key be null after GC in threadlocale.get ()? Because the key of Entry
  
  is a WeakReference, it will be reclaimed after GC
  ,object>
• ThreadLocalMap data structure in ThreadLocal? Hash table
• Hash algorithm for ThreadLocalMap? Key.threadlocalhashcode & (length-1), length is a power of 2
• How to resolve Hash conflicts in ThreadLocalMap? Open addresses, secondary addressing, because of the use of golden section number hash, hashing is very good, the likelihood of collisions is very low, so there is no chain address resolution conflict like HashMap
• ThreadLocalMap Capacity expansion mechanism?
  
  length2/3 triggers the rehash logic for exploratory cleaning, and finally determines size >= threshold3/4 to determine whether to actually call resize
• How to clean expired keys in ThreadLocalMap? Exploratory and heuristic clean-up processes? ExpungeStaleEntry ()) and heuristic (cleanSomeSlots()) probe cleanup is based on the current Entry and ends when the value is null, which belongs to linear probe cleanup
• Threadlocalmap.set () slightly
• Threadlocalmap.get () ¶ slightly
• How is ThreadLocal used in your project? Potholes? Parent threads cannot pass thread variables, and using a thread pool in the main thread is equivalent to using child threads in the parent thread that cannot pass values

Spring container, RPC full-link traceId transmission, etc

www.cnblogs.com/wang-meng/p… https://blog.csdn.net/zjcsuct/article/details/104310194 www.iocoder.cn/JDK/ThreadL… https://blog.csdn.net/qq_22167989/article/details/89448670