Java学习14（ThreadLocal详解）

àì夳堔傛蜴生んèń 2024-03-23 17:14 54阅读 0赞

![在这里插入图片描述][83a08b42829a4a74b4a5a5031f4f6d10.png]  
对于`ThreadLocal`，大家的第一反应可能是很简单呀，线程的变量副本，每个线程隔离。那这里有几个问题大家可以思考一下：

*  `ThreadLocal`的 key 是弱引用，那么在 `ThreadLocal.get()`的时候，发生GC之后，key 是否为null？
 *  `ThreadLocal`中`ThreadLocalMap`的数据结构？
 *  `ThreadLocalMap`的Hash 算法？
 *  `ThreadLocalMap`中Hash 冲突如何解决？
 *  `ThreadLocalMap`的扩容机制？`ThreadLocalMap`中过期 key 的清理机制？探测式清理和启发式清理流程？
 *  `ThreadLocalMap.set()`方法实现原理？
 *  `ThreadLocalMap.get()`方法实现原理？项目中`ThreadLocal`使用情况？

***1、ThreadLocal代码演示？***

public class ThreadLocalTest {
        
        private List<String> messages = Lists.newArrayList();
    
        public static final ThreadLocal<ThreadLocalTest> holder = ThreadLocal.withInitial(ThreadLocalTest::new);
    
        public static void add(String message) {
        
            holder.get().messages.add(message);
        }
    
        public static List<String> clear() {
        
            List<String> messages = holder.get().messages;
            holder.remove();
    
            System.out.println("size: " + holder.get().messages.size());
            return messages;
        }
    
        public static void main(String[] args) {
        
            ThreadLocalTest.add("一枝花算不算浪漫");
            System.out.println(holder.get().messages);
            ThreadLocalTest.clear();
        }
    }

打印结果：

[一枝花算不算浪漫]
    size: 0

`ThreadLocal`对象可以**提供线程局部变量**，每个**线程Thread拥有一份自己的副本变量，多个线程互不干扰。**

***2、ThreadLocal的数据结构？***

![在这里插入图片描述][e7bb050b326f4f24a892b749411d3e39.png]  
`Thread`类有一个类型为`ThreadLocal.ThreadLocalMap`的实例变量`threadLocals`，也就是说每个线程有一个自己的`ThreadLocalMap`。

`ThreadLocalMap`有自己的独立实现，可以简单地将它的`key`视作`ThreadLocal`，`value`为**代码中放入的值**（**实际上key并不是ThreadLocal本身，而是它的一个弱引用**）。

每个线程在往`ThreadLocal`里放值的时候，都会往自己的`ThreadLocalMap`里存，读也是以`ThreadLocal`作为引用，在自己的map里找对应的key，从而实现了**线程隔离**。

`ThreadLocalMap`有点类似`HashMap`的结构，只是`HashMap`是由**数组+链表**实现的，而`ThreadLocalMap`中并**没有链表结构**。

我们还要注意`Entry`， 它的key是`ThreadLocal<?> k` ，继承自`WeakReference`， 也就是我们常说的**弱引用类型**。

***3、GC 之后 key 是否为 null？***

回应开头的那个问题， `ThreadLocal` 的key是**弱引用**，那么在`ThreadLocal.get()`的时候，发生GC之后，key是否是null？

为了搞清楚这个问题，我们需要搞清楚Java的四种引用类型：

*  强引用：我们常常 new 出来的对象就是强引用类型，只要**强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足的时候**
 *  软引用：使用 `SoftReference` 修饰的对象被称为软引用，**软引用指向的对象在内存要溢出的时候被回收**
 *  弱引用：使用 `WeakReference` 修饰的对象被称为弱引用，**只要发生垃圾回收，若这个对象只被弱引用指向，那么就会被回收**
 *  虚引用：虚引用是**最弱的引用**，在 Java 中使用 `PhantomReference` 进行定义。虚引用中唯一的作用就是**用队列接收对象即将死亡的通知**

使用反射的方式来看看GC后ThreadLocal中的数据情况：

public class ThreadLocalDemo {
        
    
        public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException, InterruptedException {
        
            Thread t = new Thread(()->test("abc",false));
            t.start();
            t.join();
            System.out.println("--gc后--");
            Thread t2 = new Thread(() -> test("def", true));
            t2.start();
            t2.join();
        }
    
        private static void test(String s,boolean isGC)  {
        
            try {
        
                new ThreadLocal<>().set(s);
                if (isGC) {
        
                    System.gc();
                }
                Thread t = Thread.currentThread();
                Class<? extends Thread> clz = t.getClass();
                Field field = clz.getDeclaredField("threadLocals");
                field.setAccessible(true);
                Object ThreadLocalMap = field.get(t);
                Class<?> tlmClass = ThreadLocalMap.getClass();
                Field tableField = tlmClass.getDeclaredField("table");
                tableField.setAccessible(true);
                Object[] arr = (Object[]) tableField.get(ThreadLocalMap);
                for (Object o : arr) {
        
                    if (o != null) {
        
                        Class<?> entryClass = o.getClass();
                        Field valueField = entryClass.getDeclaredField("value");
                        Field referenceField = entryClass.getSuperclass().getSuperclass().getDeclaredField("referent");
                        valueField.setAccessible(true);
                        referenceField.setAccessible(true);
                        System.out.println(String.format("弱引用key:%s,值:%s", referenceField.get(o), valueField.get(o)));
                    }
                }
            } catch (Exception e) {
        
                e.printStackTrace();
            }
        }
    }

结果如下：

弱引用key:java.lang.ThreadLocal@433619b6,值:abc
    弱引用key:java.lang.ThreadLocal@418a15e3,值:java.lang.ref.SoftReference@bf97a12
    --gc后--
    弱引用key:null,值:def

因为这里创建的`ThreadLocal`并没有指向任何值，也就是没有任何引用：

new ThreadLocal<>().set(s);

所以这里在GC之后，key就会被回收，我们看到上面debug中的referent=null, 如果改动一下代码：

这个问题刚开始看，如果没有过多思考，弱引用，还有垃圾回收，那么肯定会觉得是null。

其实是不对的，因为题目说的是在做 **ThreadLocal.get()** 操作，**证明其实还是有强引用存在的**，所以 `key` `并不为 null`，如下图所示，`ThreadLocal`的强引用仍然是存在的。  
![在这里插入图片描述][c01adbc88a894846a7931d6e785d7bdb.png]

**如果我们的强引用不存在的话**，那么 **key 就会被回收，也就是会出现我们 value 没被回收，key 被回收，导致 value 永远存在，出现内存泄漏。**

***4、ThreadLocal.set()方法源码详解？***  
![在这里插入图片描述][6e6b81821d0b407d8e1fc223c83c24c3.png]

`ThreadLocal`中的set方法原理如上图所示，很简单，主要是判断ThreadLocalMap是否存在，然后使用`ThreadLocal`中的set方法进行数据处理。代码如下：

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

主要的核心逻辑还是在`ThreadLocalMap`中的，一步步往下看，后面还有更详细的剖析。

***5、ThreadLocalMap Hash 算法***

既然是Map结构，那么`ThreadLocalMap`当然也要实现自己的**hash算法**来**解决散列表数组冲突问题**。

int i = key.threadLocalHashCode & (len-1);

`ThreadLocalMap`中hash算法很简单，这里i就是当前 key 在散列表中对应的数组下标位置。

这里最关键的就是`threadLocalHashCode`值的计算，`ThreadLocal`中有一个属性为`HASH_INCREMENT = 0x61c88647`

public class ThreadLocal<T> {
        
        private final int threadLocalHashCode = nextHashCode();
    
        private static AtomicInteger nextHashCode = new AtomicInteger();
    
        private static final int HASH_INCREMENT = 0x61c88647;
    
        private static int nextHashCode() {
        
            return nextHashCode.getAndAdd(HASH_INCREMENT);
        }
    
        static class ThreadLocalMap {
        
            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);
            }
        }
    }

每当创建一个`ThreadLocal`对象，这个`ThreadLocal.nextHashCode` 这个值就会增长 `0x61c88647` 。

这个值很特殊，它是斐波那契数 也叫 黄金分割数。`hash`增量为 这个数字，**带来的好处就是 hash 分布非常均匀**。

***6、ThreadLocalMap Hash 冲突？***

> 注明：  
> 下面所有示例图中，  
> 绿色块Entry代表正常数据，  
> 灰色块代表Entry的key值为null，已被垃圾回收。  
> 白色块表示Entry为null。

虽然`ThreadLocalMap`中使用了黄金分割数来作为hash计算因子，大大减少了Hash冲突的概率，但是仍然会存在冲突。

`HashMap`中**解决冲突的方法是在数组上构造一个链表结构，冲突的数据挂载到链表上，如果链表长度超过一定数量则会转化成红黑树**。

而 `ThreadLocalMap` 中并没有链表结构，所以这里不能使用 HashMap 解决冲突的方式了。  
![在这里插入图片描述][17a4de13da684ef89326db68b1f64583.png]

如上图所示，如果我们插入一个value=27的数据，通过 hash 计算后应该落入槽位 4 中，而槽位 4 已经有了 Entry 数据。

此时就会线性向后查找，一直找到 Entry 为 null 的槽位才会停止查找，将当前元素放入此槽位中。当然迭代过程中还有其他的情况，比如遇到了 Entry 不为 null 且 key 值相等的情况，还有 Entry 中的 key 值为 null 的情况等等都会有不同的处理，后面会一一详细讲解。

这里还画了一个Entry中的key为null的数据（Entry=2 的灰色块数据），因为key值是弱引用类型，所以会有这种数据存在。在set过程中，如果遇到了key过期的Entry数据，实际上是会进行一轮**探测式清理**操作的，具体操作方式后面会讲到。

***7、ThreadLocalMap.set()详解？***

看完了ThreadLocal hash 算法后，我们再来看set是如何实现的。

往ThreadLocalMap中set数据（新增或者更新数据）分为好几种情况，针对不同的情况我们画图来说明。

*  第一种情况： 通过**hash计算后**的**槽位对应的Entry数据为空**：  
    ![在这里插入图片描述][bdddf021b6c64f9abdad4b6e6e1d586c.png]

这里直接将数据放到该槽位即可。

*  第二种情况： **槽位数据不为空**，key值与当前`ThreadLocal`通过hash计算获取的key **值一致** ：  
    ![在这里插入图片描述][d43a5493d42c42a7b2c313ff41868f49.png]

这里直接更新该槽位的数据。

*  第三种情况： **槽位数据不为空**，往后遍历过程中，在找到Entry为null的槽位之前，没有遇到key过期的Entry：  
    ![在这里插入图片描述][01f281214b1e4f4689296977e64b8835.png]

遍历散列数组，线性往后查找，如果找到Entry为null的槽位，则将数据放入该槽位中，或者往后遍历过程中，遇到了key 值相等的数据，直接更新即可。

*  第四种情况： 槽位数据不为空，往后遍历过程中，在找到Entry为null的槽位之前，遇到key过期的Entry，如下图，往后遍历过程中，遇到了index=7的槽位数据Entry的key=null：  
    ![在这里插入图片描述][8f386b2b1dc54a69aaa39f4196ecc7be.png]

散列数组下标为 7 位置对应的Entry数据key为null，表明此数据key值已经被垃圾回收掉了，此时就会执行`replaceStaleEntry()`方法，该方法含义是**替换过期数据的逻辑**，**以index=7位起点开始遍历，进行探测式数据清理工作**。

初始化探测式清理过期数据扫描的开始位置：`slotToExpunge = staleSlot = 7`

以当前`staleSlot`开始 **向前迭代查找**，找其他过期的数据，然后更新过期数据起始扫描下标`slotToExpunge`。for循环迭代，直到碰到Entry为null结束。

如果找到了过期的数据，继续向前迭代，直到遇到Entry=null的槽位才停止迭代，如下图所示，`slotToExpunge` 被更新为 0：  
![在这里插入图片描述][8cb531aec5be411f9cd64573a78b4f6c.png]

以当前节点(index=7)向前迭代，检测是否有过期的Entry数据，如果有则更新slotToExpunge值。碰到null则结束探测。以上图为例slotToExpunge被更新为 0。

上面向前迭代的操作是为了更新探测清理过期数据的起始下标slotToExpunge的值，这个值在后面会讲解，它是用来判断当前过期槽位staleSlot之前是否还有过期元素。

接着开始以staleSlot位置(index=7)向后迭代，如果找到了相同 key 值的 Entry 数据：  
![在这里插入图片描述][51f622d9c28945c9a4ba1dc9e0123328.png]

从当前节点staleSlot向后查找key值相等的Entry元素，找到后更新Entry的值并交换staleSlot元素的位置(staleSlot位置为过期元素)，更新Entry数据，然后开始进行过期Entry的清理工作，如下图所示：  
![在这里插入图片描述][2f0a357217c54320a13e24fad2648f7f.png]

向后遍历过程中，如果没有找到相同 key 值的 Entry 数据：  
![在这里插入图片描述][676858d99f6f485fb674024c1eb1461a.png]

从当前节点staleSlot向后查找key值相等的Entry元素，直到Entry为null则停止寻找。通过上图可知，此时table中没有key值相同的Entry。

创建新的Entry，替换table\[stableSlot\]位置：  
![在这里插入图片描述][a5bdf364c21b4d8a8f388fcb693319b5.png]

替换完成后也是进行过期元素清理工作，清理工作主要是有两个方法：`expungeStaleEntry()`和`cleanSomeSlots()`，具体细节后面会讲到。

***8、ThreadLocalMap.set()源码详解？***

上面已经用图的方式解析了set()实现的原理，其实已经很清晰了，我们接着再看下源码：`java.lang.ThreadLocal.ThreadLocalMap.set()`:

private void set(ThreadLocal<?> key, Object value) {
        
        Entry[] tab = table;
        int len = tab.length;
        int i = key.threadLocalHashCode & (len-1);
    
        for (Entry e = tab[i];
             e != null;
             e = tab[i = nextIndex(i, len)]) {
        
            ThreadLocal<?> k = e.get();
    
            if (k == key) {
        
                e.value = value;
                return;
            }
    
            if (k == null) {
        
                replaceStaleEntry(key, value, i);
                return;
            }
        }
    
        tab[i] = new Entry(key, value);
        int sz = ++size;
        if (!cleanSomeSlots(i, sz) && sz >= threshold)
            rehash();
    }

这里会通过key来计算在散列表中的对应位置，然后以当前key对应的桶的位置向后查找，找到可以使用的桶。

Entry[] tab = table;
    int len = tab.length;
    int i = key.threadLocalHashCode & (len-1);

**什么情况下桶才是可以使用的呢？**

*  k = key 说明是替换操作，可以使用
 *  碰到一个过期的桶，执行替换逻辑，占用过期桶
 *  查找过程中，碰到桶中Entry=null的情况，直接使用

接着就是执行for循环遍历，向后查找，我们先看下`nextIndex()、prevIndex()`方法实现：  
![在这里插入图片描述][06b6b638ae6341c9a91978822aa73126.png]

private static int nextIndex(int i, int len) {
        
        return ((i + 1 < len) ? i + 1 : 0);
    }
    
    private static int prevIndex(int i, int len) {
        
        return ((i - 1 >= 0) ? i - 1 : len - 1);
    }

接着看剩下for循环中的逻辑：

*  遍历当前key值对应的桶中Entry数据为空，这说明散列数组这里没有数据冲突，跳出for循环，直接set数据到对应的桶中
 *  如果key值对应的桶中Entry数据不为空 : 如果**k = key**，说明当前set操作是一个替换操作，做替换逻辑，直接返回 ; 如果**key = null**，说明当前桶位置的Entry是过期数据，执行`replaceStaleEntry()`方法(核心方法)，然后返回
 *  for循环执行完毕，继续往下执行说明向后迭代的过程中遇到了entry为null的情况：在Entry为null的桶中创建一个新的Entry对象 ； 执行++size操作
 *  调用`cleanSomeSlots()`做一次启发式清理工作，清理散列数组中Entry的key过期的数据：如果清理工作完成后，未清理到任何数据，且size超过了阈值(数组长度的 2/3)，进行`rehash()`操作； `rehash()`中会先进行一轮**探测式清理**，清理过期key，清理完成后如果\*\*size >= threshold - threshold / 4，就会执行真正的扩容逻辑(\*\*扩容逻辑往后看)

接着重点看下`replaceStaleEntry()`方法，`replaceStaleEntry()`方法**提供替换过期数据的功能**，我们可以对应上面**第四种情况的原理图**来再回顾下，具体代码如下：`java.lang.ThreadLocal.ThreadLocalMap.replaceStaleEntry()`

private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                                           int staleSlot) {
        
        Entry[] tab = table;
        int len = tab.length;
        Entry e;
    
        int slotToExpunge = staleSlot;
        for (int i = prevIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = prevIndex(i, len))
    
            if (e.get() == null)
                slotToExpunge = i;
    
        for (int i = nextIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = nextIndex(i, len)) {
        
    
            ThreadLocal<?> k = e.get();
    
            if (k == key) {
        
                e.value = value;
    
                tab[i] = tab[staleSlot];
                tab[staleSlot] = e;
    
                if (slotToExpunge == staleSlot)
                    slotToExpunge = i;
                cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
                return;
            }
    
            if (k == null && slotToExpunge == staleSlot)
                slotToExpunge = i;
        }
    
        tab[staleSlot].value = null;
        tab[staleSlot] = new Entry(key, value);
    
        if (slotToExpunge != staleSlot)
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
    }

`slotToExpunge`表示开始**探测式清理过期数据**的开始下标，默认从当前的`staleSlot`开始。以当前的`staleSlot`开始，向前迭代查找，找到没有过期的数据，**for循环一直碰到Entry为null才会结束**。如果向前找到了过期数据，更新探测清理过期数据的开始下标为 i，即

slotToExpunge=ifor (int i = prevIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = prevIndex(i, len)){
        
    
        if (e.get() == null){
        
            slotToExpunge = i;
        }
    }

接着开始从staleSlot向后查找，**也是碰到Entry为null的桶结束**。 如果迭代过程中，**碰到 k == key，这说明这里是替换逻辑，替换新数据并且交换当前`staleSlot`位置**。如果`slotToExpunge == staleSlot`，这说明`replaceStaleEntry()`一开始向前查找过期数据时并未找到过期的Entry数据，接着向后查找过程中也未发现过期数据，修改开始探测式清理过期数据的下标为当前循环的 index，即`slotToExpunge = i`。最后调用`cleanSomeSlots(expungeStaleEntry(slotToExpunge), len)`;进行**启发式过期数据清理**。

if (k == key) {
        
        e.value = value;
    
        tab[i] = tab[staleSlot];
        tab[staleSlot] = e;
    
        if (slotToExpunge == staleSlot)
            slotToExpunge = i;
    
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        return;
    }

`cleanSomeSlots()`和`expungeStaleEntry()`方法后面都会细讲，这两个是和清理相关的方法，一个是过期key相关Entry的**启发式清理(Heuristically scan)**，另一个是过期key相关Entry的**探测式清理**。

如果 k != key则会接着往下走，`k == null`说明当前遍历的Entry是一个过期数据，`slotToExpunge == staleSlot`说明，一开始的向前查找数据并未找到过期的Entry。如果条件成立，则更新`slotToExpunge` 为当前位置，这个前提是前驱节点扫描时未发现过期数据。

if (k == null && slotToExpunge == staleSlot)
        slotToExpunge = i;

往后迭代的过程中如果没有找到`k == key`的数据，且碰到Entry为null的数据，**则结束当前的迭代操作**。此时说明这里是一个添加的逻辑，将新的数据添加到`table[staleSlot]` 对应的slot中。

tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

最后判断除了staleSlot以外，还发现了其他过期的slot数据，就要开启清理数据的逻辑：

if (slotToExpunge != staleSlot)
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);

***9、ThreadLocalMap过期 key 的探测式清理流程？***

上面我们有提及`ThreadLocalMap`的两种过期key数据清理方式：**探测式清理**和**启发式清理**。

我们先讲下探测式清理，也就是**expungeStaleEntry**方法。

遍历散列数组，从开始位置向后探测清理过期数据，将过期数据的Entry设置为null，沿途中碰到未过期的数据则将此数据rehash后重新在table数组中定位，如果定位的位置已经有了数据，则会将未过期的数据放到最靠近此位置的Entry=null的桶中，使rehash后的Entry数据距离正确的桶的位置更近一些。操作逻辑如下：  
![在这里插入图片描述][fdafead5ddcc4a43a7bf8e32ebc290e1.png]

如上图，set(27) 经过 hash 计算后应该落到index=4的桶中，由于index=4桶已经有了数据，所以往后迭代最终数据放入到index=7的桶中，放入后一段时间后index=5中的Entry数据key变为了null  
![在这里插入图片描述][d3300968d0964dc8887570767d5d5221.png]

如果再有其他数据set到map中，就会触发**探测式清理操作**。

如上图，执行探测式清理后，index=5的数据被清理掉，继续往后迭代，到index=7的元素时，经过rehash后发现该元素正确的index=4，而此位置已经有了数据，往后查找离index=4最近的Entry=null的节点(刚被探测式清理掉的数据：index=5)，找到后移动index= 7的数据到index=5中，此时桶的位置离正确的位置index=4更近了。

\*\*经过一轮探测式清理后，key过期的数据会被清理掉，没过期的数据经过rehash重定位后所处的桶位置理论上更接近i= key.hashCode & (tab.len - 1)的位置。\*\*这种优化会提高整个散列表查询性能。

接着看下`expungeStaleEntry()`具体流程，我们还是以先原理图后源码讲解的方式来一步步梳理：  
![在这里插入图片描述][e81b770b40dd4d92b82b789807a40a09.png]

我们假设expungeStaleEntry(3) 来调用此方法，如上图所示，我们可以看到ThreadLocalMap中table的数据情况，接着执行清理操作：  
![在这里插入图片描述][d5c7ed74602642db828329b341c8fed9.png]

第一步是清空当前staleSlot位置的数据，index=3位置的Entry变成了null。然后接着往后探测：  
![在这里插入图片描述][385102ece121428999bf907aea407b2a.png]

执行完第二步后，index=4 的元素挪到 index=3 的槽位中。

继续往后迭代检查，碰到正常数据，计算该数据位置是否偏移，如果被偏移，则重新计算slot位置，目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置  
![在这里插入图片描述][18015e9b609a4530958cfc21d03208e9.png]

在往后迭代的过程中碰到空的槽位，终止探测，这样一轮探测式清理工作就完成了，接着我们继续看看具体实现源代码：

private int expungeStaleEntry(int staleSlot) {
        
        Entry[] tab = table;
        int len = tab.length;
    
        tab[staleSlot].value = null;
        tab[staleSlot] = null;
        size--;
    
        Entry e;
        int i;
        for (i = nextIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = nextIndex(i, len)) {
        
            ThreadLocal<?> k = e.get();
            if (k == null) {
        
                e.value = null;
                tab[i] = null;
                size--;
            } else {
        
                int h = k.threadLocalHashCode & (len - 1);
                if (h != i) {
        
                    tab[i] = null;
    
                    while (tab[h] != null)
                        h = nextIndex(h, len);
                    tab[h] = e;
                }
            }
        }
        return i;
    }

这里我们还是以staleSlot=3 来做示例说明，首先是将tab\[staleSlot\]槽位的数据清空，然后设置size-- 接着以staleSlot位置往后迭代，如果遇到k==null的过期数据，也是清空该槽位数据，然后size–

ThreadLocal<?> k = e.get();
    
    if (k == null) {
        
        e.value = null;
        tab[i] = null;
        size--;
    }

如果key没有过期，重新计算当前key的下标位置是不是当前槽位下标位置，如果不是，那么说明产生了**hash冲突**，此时以新计算出来正确的槽位位置往后迭代，找到最近一个可以存放entry的位置。

int h = k.threadLocalHashCode & (len - 1);
    if (h != i) {
        
        tab[i] = null;
    
        while (tab[h] != null)
            h = nextIndex(h, len);
    
        tab[h] = e;
    }

这里是处理正常的产生Hash冲突的数据，经过迭代后，有过Hash冲突数据的Entry位置会更靠近正确位置，这样的话，查询的时候 效率才会更高。

***10、ThreadLocalMap扩容机制？***

在`ThreadLocalMap.set()`方法的最后，如果执行完启发式清理工作后，未清理到任何数据，且当前散列数组中Entry的数量已经达到了列表的`扩容阈值(len*2/3)`，就开始执行`rehash()`逻辑：

if (!cleanSomeSlots(i, sz) && sz >= threshold)
        rehash();

接着看下rehash()具体实现：

private void rehash() {
        
        expungeStaleEntries();
    
        if (size >= threshold - threshold / 4)
            resize();
    }
    
    private void expungeStaleEntries() {
        
        Entry[] tab = table;
        int len = tab.length;
        for (int j = 0; j < len; j++) {
        
            Entry e = tab[j];
            if (e != null && e.get() == null)
                expungeStaleEntry(j);
        }
    }

这里首先是会进行探测式清理工作，从table的起始位置往后清理，上面有分析清理的详细流程。清理完成之后，table中可能有一些key为null的Entry数据被清理掉，所以此时通过判断`size >= threshold - threshold / 4` 也就是`size >= threshold * 3/4` 来决定是否扩容。

我们还记得上面进行`rehash()`的阈值是`size >= threshold`，所以当面试官套路我们`ThreadLocalMap`扩容机制的时候 我们一定要说清楚这两个步骤：  
![在这里插入图片描述][83e80fc28887468085fe70e1e6cf146d.png]

接着看看具体的`resize()`方法，为了方便演示，我们以`oldTab.len=8`来举例：  
![在这里插入图片描述][efb973f61e95410f8ca6506830100425.png]

扩容后的tab的大小为oldLen \* 2，然后遍历老的散列表，重新计算hash位置，然后放到新的tab数组中，**如果出现hash冲突则往后寻找最近的entry为null的槽位**，遍历完成之后，oldTab中所有的entry数据都已经放入到新的tab中了。重新计算tab下次扩容的阈值，具体代码如下：

private void resize() {
        
        Entry[] oldTab = table;
        int oldLen = oldTab.length;
        int newLen = oldLen * 2;
        Entry[] newTab = new Entry[newLen];
        int count = 0;
    
        for (int j = 0; j < oldLen; ++j) {
        
            Entry e = oldTab[j];
            if (e != null) {
        
                ThreadLocal<?> k = e.get();
                if (k == null) {
        
                    e.value = null;
                } else {
        
                    int h = k.threadLocalHashCode & (newLen - 1);
                    while (newTab[h] != null)
                        h = nextIndex(h, newLen);
                    newTab[h] = e;
                    count++;
                }
            }
        }
    
        setThreshold(newLen);
        size = count;
        table = newTab;
    }

***11、ThreadLocalMap.get()详解？***

上面已经看完了set()方法的源码，其中包括set数据、清理数据、优化数据桶的位置等操作，接着看看get()操作的原理。

`ThreadLocalMap.get()`图解

*  第一种情况： 通过**查找key值**计算出散列表中**slot位置**，然后**该slot位置中的Entry.key和查找的key一致，则直接返回**：  
    ![在这里插入图片描述][8f7b9c3d21ac433e9432a052a7911261.png]
 *  第二种情况： slot位置中的Entry.key和要查找的key不一致：  
    ![在这里插入图片描述][843f3d8153eb4e698b79d1f9c6ff5608.png]

我们以get(ThreadLocal1)为例，通过hash计算后，正确的slot位置应该是 4，**而index=4的槽位已经有了数据，且key值不等于ThreadLocal1，所以`需要继续往后迭代查找`。**

迭代到index=5的数据时，此时Entry.key=null，触发一次探测式数据回收操作，执行`expungeStaleEntry()`方法，执行完后，index 5,8的数据都会被回收，而index 6,7的数据都会前移。index 6,7前移之后，继续从 index=5 往后迭代，于是就在 index=5 找到了key值相等的Entry数据，如下图所示：  
![在这里插入图片描述][004163dfdae54e3cbfe649b9d9edff5c.png]

**ThreadLocalMap.get()源码详解？**

`java.lang.ThreadLocal.ThreadLocalMap.getEntry()`:

private Entry getEntry(ThreadLocal<?> key) {
        
        int i = key.threadLocalHashCode & (table.length - 1);
        Entry e = table[i];
        if (e != null && e.get() == key)
            return e;
        else
            return getEntryAfterMiss(key, i, e);
    }
    
    private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
        
        Entry[] tab = table;
        int len = tab.length;
    
        while (e != null) {
        
            ThreadLocal<?> k = e.get();
            if (k == key)
                return e;
            if (k == null)
                expungeStaleEntry(i);
            else
                i = nextIndex(i, len);
            e = tab[i];
        }
        return null;
    }

***12、ThreadLocalMap过期 key 的启发式清理流程？***

上面多次提及到`ThreadLocalMap`过期key的两种清理方式：探测式清理(`expungeStaleEntry`())、启发式清理(`cleanSomeSlots`())

探测式清理是**以当前Entry 往后清理，遇到值为null则结束清理，属于线性探测清理**。

而启发式清理被作者定义为：**Heuristically scan some cells looking for stale entries**.  
![在这里插入图片描述][5f6dfed47e9b4ac9bf684ef262862c12.png]

具体代码如下：

private boolean cleanSomeSlots(int i, int n) {
        
        boolean removed = false;
        Entry[] tab = table;
        int len = tab.length;
        do {
        
            i = nextIndex(i, len);
            Entry e = tab[i];
            if (e != null && e.get() == null) {
        
                n = len;
                removed = true;
                i = expungeStaleEntry(i);
            }
        } while ( (n >>>= 1) != 0);
        return removed;
    }

***13、InheritableThreadLocal？***

我们使用`ThreadLocal`的时候，在**异步场景下**是**无法给子线程共享父线程中创建的线程副本数据**的。

为了解决这个问题，JDK 中还有一个`InheritableThreadLocal`类，我们来看一个例子：

public class InheritableThreadLocalDemo {
        
        public static void main(String[] args) {
        
            ThreadLocal<String> ThreadLocal = new ThreadLocal<>();
            ThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
            ThreadLocal.set("父类数据:threadLocal");
            inheritableThreadLocal.set("父类数据:inheritableThreadLocal");
    
            new Thread(new Runnable() {
        
                @Override
                public void run() {
        
                    System.out.println("子线程获取父类ThreadLocal数据：" + ThreadLocal.get());
                    System.out.println("子线程获取父类inheritableThreadLocal数据：" + inheritableThreadLocal.get());
                }
            }).start();
        }
    }

打印结果：

子线程获取父类ThreadLocal数据：null
    子线程获取父类inheritableThreadLocal数据：父类数据:inheritableThreadLocal

实现原理是**子线程是通过在父线程中通过调用new Thread()方法来创建子线程**，**Thread\#init**方法在**Thread**的构造方法中被调用。在init方法中拷贝父线程数据到子线程中：

private void init(ThreadGroup g, Runnable target, String name,
                          long stackSize, AccessControlContext acc,
                          boolean inheritThreadLocals) {
        
        if (name == null) {
        
            throw new NullPointerException("name cannot be null");
        }
    
        if (inheritThreadLocals && parent.inheritableThreadLocals != null)
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
        this.stackSize = stackSize;
        tid = nextThreadID();
    }

但`InheritableThreadLocal`仍然有缺陷，**一般我们做异步化处理都是使用的线程池**，而`InheritableThreadLocal`是在**new Thread中的init()方法给赋值的**，**而线程池是线程复用的逻辑**，所以这里会存在问题。

当然，有问题出现就会有解决问题的方案，阿里巴巴开源了一个`TransmittableThreadLocal`组件就可以解决这个问题，这里就不再延伸。

[83a08b42829a4a74b4a5a5031f4f6d10.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ab6300a4bec04587aabbbf82e37b3e7d.png
[e7bb050b326f4f24a892b749411d3e39.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/664c3382717f4c1398f5c4cd482d49e9.png
[c01adbc88a894846a7931d6e785d7bdb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/317e653fdf424ff495e2c1583c2ae2f4.png
[6e6b81821d0b407d8e1fc223c83c24c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/c08dc4bbc8384550bc413cd865f6f15b.png
[17a4de13da684ef89326db68b1f64583.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/3d14a4c335db458490fb923e6d6cda06.png
[bdddf021b6c64f9abdad4b6e6e1d586c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d105297dd9754cefa75a930c0ade2b6c.png
[d43a5493d42c42a7b2c313ff41868f49.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/c6e427ad3a744ff9943b5916b83d076a.png
[01f281214b1e4f4689296977e64b8835.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/82c072e9acbb4555a8443c8903d0eacb.png
[8f386b2b1dc54a69aaa39f4196ecc7be.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/f139b11fb57043459263fa2392d737c6.png
[8cb531aec5be411f9cd64573a78b4f6c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/eac5e029e77f43d983a10fc2837a70a1.png
[51f622d9c28945c9a4ba1dc9e0123328.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/f9a803b9b52749c598a3507a04aba6e0.png
[2f0a357217c54320a13e24fad2648f7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/560bd8c0f38b4116a498abb5883ca374.png
[676858d99f6f485fb674024c1eb1461a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1cbc1fd974a94096987f76641bf9d45f.png
[a5bdf364c21b4d8a8f388fcb693319b5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/33ad1639830c4613969ff4fcdde3ad25.png
[06b6b638ae6341c9a91978822aa73126.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1a4385a4c3de4ca5abbf3c23cfeee29a.png
[fdafead5ddcc4a43a7bf8e32ebc290e1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/3f33a4ce006c47eabfd44126772ff8ac.png
[d3300968d0964dc8887570767d5d5221.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/0dfc0198eeac4e2fa791c23f1a652f15.png
[e81b770b40dd4d92b82b789807a40a09.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d082b73ae7d84df8bbf9c4338b636971.png
[d5c7ed74602642db828329b341c8fed9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/8ea50fd2987448f6bdb29495169bfe39.png
[385102ece121428999bf907aea407b2a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/5822aaea04b54ef8a6cb8ca1e5650c60.png
[18015e9b609a4530958cfc21d03208e9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/26f71d8e3e0e4926ad2f878099dc8e38.png
[83e80fc28887468085fe70e1e6cf146d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/fe4d4c62a6974a8f80a40703269d4774.png
[efb973f61e95410f8ca6506830100425.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1aaafbc06e314ff1b8ecc558b1fd71fa.png
[8f7b9c3d21ac433e9432a052a7911261.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/318cf853154d4625a3905c274ea04122.png
[843f3d8153eb4e698b79d1f9c6ff5608.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/074f6aa785c94607a0ba798462e9c478.png
[004163dfdae54e3cbfe649b9d9edff5c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/e4160e13447644f9b8b54bfa361d324c.png
[5f6dfed47e9b4ac9bf684ef262862c12.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ac5760d4f897475cba8a89c524fa493e.png