diff --git a/README.md b/README.md index 58be3c7c..2f467816 100644 --- a/README.md +++ b/README.md @@ -141,8 +141,9 @@ Github用户如果访问速度缓慢的话，可以转移到[码云](https://git 1. [并发容器总结](docs/java/Multithread/并发容器总结.md) 2. **线程池**：[Java线程池学习总结](./docs/java/Multithread/java线程池学习总结.md)、[拿来即用的线程池最佳实践](./docs/java/Multithread/best-practice-of-threadpool.md) 3. [乐观锁与悲观锁](docs/essential-content-for-interview/面试必备之乐观锁与悲观锁.md) -4. [JUC 中的 Atomic 原子类总结](docs/java/Multithread/Atomic.md) -5. [AQS 原理以及 AQS 同步组件总结](docs/java/Multithread/AQS.md) +4. [万字图文深度解析ThreadLocal](docs/java/Multithread/ThreadLocal.md) +5. [JUC 中的 Atomic 原子类总结](docs/java/Multithread/Atomic.md) +6. [AQS 原理以及 AQS 同步组件总结](docs/java/Multithread/AQS.md) ### JVM diff --git a/docs/java/Multithread/ThreadLocal.md b/docs/java/Multithread/ThreadLocal.md index f69cc1d6..0b78432d 100644 --- a/docs/java/Multithread/ThreadLocal.md +++ b/docs/java/Multithread/ThreadLocal.md @@ -1,170 +1,914 @@ -[ThreadLocal造成OOM内存溢出案例演示与原理分析](https://blog.csdn.net/xlgen157387/article/details/78298840) +> 本文来自一枝花算不算浪漫投稿， 原文地址：[https://juejin.im/post/5eacc1c75188256d976df748](https://juejin.im/post/5eacc1c75188256d976df748)。 -[深入理解 Java 之 ThreadLocal 工作原理]() +### 前言 -## ThreadLocal +![](./thread-local/1.png) -### ThreadLocal简介 +**全文共10000+字，31张图，这篇文章同样耗费了不少的时间和精力才创作完成，原创不易，请大家点点关注+在看，感谢。** -通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。**如果想实现每一个线程都有自己的专属本地变量该如何解决呢？** JDK中提供的`ThreadLocal`类正是为了解决这样的问题。 **`ThreadLocal`类主要解决的就是让每个线程绑定自己的值，可以将`ThreadLocal`类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。** +对于`ThreadLocal`，大家的第一反应可能是很简单呀，线程的变量副本，每个线程隔离。那这里有几个问题大家可以思考一下： -**如果你创建了一个`ThreadLocal`变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是`ThreadLocal`变量名的由来。他们可以使用 `get（）` 和 `set（）` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。** +- `ThreadLocal`的key是**弱引用**，那么在 `ThreadLocal`.get()的时候,发生**GC**之后，key是否为**null**？ +- `ThreadLocal`中`ThreadLocalMap`的**数据结构**？ +- `ThreadLocalMap`的**Hash算法**？ +- `ThreadLocalMap`中**Hash冲突**如何解决？ +- `ThreadLocalMap`的**扩容机制**？ +- `ThreadLocalMap`中**过期key的清理机制**？**探测式清理**和**启发式清理**流程？ +- `ThreadLocalMap.set()`方法实现原理？ +- `ThreadLocalMap.get()`方法实现原理？ +- 项目中`ThreadLocal`使用情况？遇到的坑？ +- ...... -再举个简单的例子： +上述的一些问题你是否都已经掌握的很清楚了呢？本文将围绕这些问题使用图文方式来剖析`ThreadLocal`的**点点滴滴**。 -比如有两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么ThreadLocal就是用来这两个线程竞争的。 +### 目录 -### ThreadLocal示例 -相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。 + +**注明：** 本文源码基于`JDK 1.8` + +### `ThreadLocal`代码演示 + +我们先看下`ThreadLocal`使用示例： ```java -import java.text.SimpleDateFormat; -import java.util.Random; +public class ThreadLocalTest { + private List messages = Lists.newArrayList(); -public class ThreadLocalExample implements Runnable{ + public static final `ThreadLocal` holder = `ThreadLocal`.withInitial(ThreadLocalTest::new); - // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本 - private static final ThreadLocal formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm")); + public static void add(String message) { + holder.get().messages.add(message); + } - public static void main(String[] args) throws InterruptedException { - ThreadLocalExample obj = new ThreadLocalExample(); - for(int i=0 ; i<10; i++){ - Thread t = new Thread(obj, ""+i); - Thread.sleep(new Random().nextInt(1000)); - t.start(); + public static List clear() { + List 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(); + } +} +``` + +打印结果： + +```java +[一枝花算不算浪漫] +size: 0 +``` + +`ThreadLocal`对象可以提供线程局部变量，每个线程`Thread`拥有一份自己的**副本变量**，多个线程互不干扰。 + +### `ThreadLocal`的数据结构 + +![](./thread-local/2.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， 也就是我们常说的弱引用类型。 + +### GC 之后key是否为null？ + +回应开头的那个问题， `ThreadLocal` 的`key`是弱引用，那么在` `ThreadLocal`.get()`的时候,发生`GC`之后，`key`是否是`null`？ + +为了搞清楚这个问题，我们需要搞清楚`Java`的**四种引用类型**： + +- **强引用**：我们常常new出来的对象就是强引用类型，只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足的时候 +- **软引用**：使用SoftReference修饰的对象被称为软引用，软引用指向的对象在内存要溢出的时候被回收 +- **弱引用**：使用WeakReference修饰的对象被称为弱引用，只要发生垃圾回收，若这个对象只被弱引用指向，那么就会被回收 +- **虚引用**：虚引用是最弱的引用，在 Java 中使用 PhantomReference 进行定义。虚引用中唯一的作用就是用队列接收对象即将死亡的通知 + + +接着再来看下代码，我们使用反射的方式来看看`GC`后`ThreadLocal`中的数据情况：(下面代码来源自：https://blog.csdn.net/thewindkee/article/details/103726942，本地运行演示GC回收场景) + +```java +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 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(); } } +} +``` + +结果如下： +```java +弱引用key:java.lang.`ThreadLocal`@433619b6,值:abc +弱引用key:java.lang.`ThreadLocal`@418a15e3,值:java.lang.ref.SoftReference@bf97a12 +--gc后-- +弱引用key:null,值:def +``` + +![](./thread-local/3.png) + +如图所示，因为这里创建的`ThreadLocal`并没有指向任何值，也就是没有任何引用： + +```java +new ThreadLocal<>().set(s); +``` + +所以这里在`GC`之后，`key`就会被回收，我们看到上面`debug`中的`referent=null`, 如果**改动一下代码：** + +![](./thread-local/4.png) + +这个问题刚开始看，如果没有过多思考，**弱引用**，还有**垃圾回收**，那么肯定会觉得是`null`。 + +其实是不对的，因为题目说的是在做 ``ThreadLocal`.get()` 操作，证明其实还是有**强引用**存在的，所以 `key` 并不为 `null`，如下图所示，`ThreadLocal`的**强引用**仍然是存在的。 + +![image.png](./thread-local/5.png) + +如果我们的**强引用**不存在的话，那么 `key` 就会被回收，也就是会出现我们 `value` 没被回收，`key` 被回收，导致 `value` 永远存在，出现内存泄漏。 + +### `ThreadLocal.set()`方法源码详解 + +![](./thread-local/6.png) + +`ThreadLocal`中的`set`方法原理如上图所示，很简单，主要是判断`ThreadLocalMap`是否存在，然后使用`ThreadLocal`中的`set`方法进行数据处理。 + +代码如下： + +```java +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`中的，一步步往下看，后面还有更详细的剖析。 + +### `ThreadLocalMap` Hash算法 + +既然是`Map`结构，那么`ThreadLocalMap`当然也要实现自己的`hash`算法来解决散列表数组冲突问题。 + +```java +int i = key.threadLocalHashCode & (len-1); +``` + +`ThreadLocalMap`中`hash`算法很简单，这里`i`就是当前key在散列表中对应的数组下标位置。 + +这里最关键的就是`threadLocalHashCode`值的计算，`ThreadLocal`中有一个属性为`HASH_INCREMENT = 0x61c88647` + +```java +public class ThreadLocal { + 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` **分布非常均匀**。 + +我们自己可以尝试下： + +![](./thread-local/8.png) + +可以看到产生的哈希码分布很均匀，这里不去细纠**斐波那契**具体算法，感兴趣的可以自行查阅相关资料。 + +### `ThreadLocalMap` Hash冲突 + +> **注明：** 下面所有示例图中，**绿色块**`Entry`代表**正常数据**，**灰色块**代表`Entry`的`key`值为`null`，**已被垃圾回收**。**白色块**表示`Entry`为`null`。 + +虽然`ThreadLocalMap`中使用了**黄金分隔数来**作为`hash`计算因子，大大减少了`Hash`冲突的概率，但是仍然会存在冲突。 + +`HashMap`中解决冲突的方法是在数组上构造一个**链表**结构，冲突的数据挂载到链表上，如果链表长度超过一定数量则会转化成**红黑树**。 + +而`ThreadLocalMap`中并没有链表结构，所以这里不能适用`HashMap`解决冲突的方式了。 + +![](./thread-local/7.png) + + +如上图所示，如果我们插入一个`value=27`的数据，通过`hash`计算后应该落入第4个槽位中，而槽位4已经有了`Entry`数据。 + +此时就会线性向后查找，一直找到`Entry`为`null`的槽位才会停止查找，将当前元素放入此槽位中。当然迭代过程中还有其他的情况，比如遇到了`Entry`不为`null`且`key`值相等的情况，还有`Entry`中的`key`值为`null`的情况等等都会有不同的处理，后面会一一详细讲解。 + +这里还画了一个`Entry`中的`key`为`null`的数据（**Entry=2的灰色块数据**），因为`key`值是**弱引用**类型，所以会有这种数据存在。在`set`过程中，如果遇到了`key`过期的`Entry`数据，实际上是会进行一轮**探测式清理**操作的，具体操作方式后面会讲到。 + +### `ThreadLocalMap.set()`详解 + +#### `ThreadLocalMap.set()`原理图解 + +看完了`ThreadLocal` **hash算法**后，我们再来看`set`是如何实现的。 + +往`ThreadLocalMap`中`set`数据（**新增**或者**更新**数据）分为好几种情况，针对不同的情况我们画图来说说明。 + +**第一种情况：** 通过`hash`计算后的槽位对应的`Entry`数据为空： + +![](./thread-local/9.png) + +这里直接将数据放到该槽位即可。 + +**第二种情况：** 槽位数据不为空，`key`值与当前`ThreadLocal`通过`hash`计算获取的`key`值一致： + +![](./thread-local/10.png) + +这里直接更新该槽位的数据。 + +**第三种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，没有遇到`key`过期的`Entry`： + +![](./thread-local/11.png) + +遍历散列数组，线性往后查找，如果找到`Entry`为`null`的槽位，则将数据放入该槽位中，或者往后遍历过程中，遇到了**key值相等**的数据，直接更新即可。 + +**第四种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，遇到`key`过期的`Entry`，如下图，往后遍历过程中，一到了`index=7`的槽位数据`Entry`的`key=null`： + +![](./thread-local/12.png) + +散列数组下标为7位置对应的`Entry`数据`key`为`null`，表明此数据`key`值已经被垃圾回收掉了，此时就会执行`replaceStaleEntry()`方法，该方法含义是**替换过期数据的逻辑**，以**index=7**位起点开始遍历，进行探测式数据清理工作。 + +初始化探测式清理过期数据扫描的开始位置：`slotToExpunge = staleSlot = 7` + +以当前`staleSlot`开始 向前迭代查找，找其他过期的数据，然后更新过期数据起始扫描下标`slotToExpunge`。`for`循环迭代，直到碰到`Entry`为`null`结束。 + +如果找到了过期的数据，继续向前迭代，直到遇到`Entry=null`的槽位才停止迭代，如下图所示，**slotToExpunge被更新为0**： + +![](./thread-local/13.png) + +以当前节点(`index=7`)向前迭代，检测是否有过期的`Entry`数据，如果有则更新`slotToExpunge`值。碰到`null`则结束探测。以上图为例`slotToExpunge`被更新为0。 + +上面向前迭代的操作是为了更新探测清理过期数据的起始下标`slotToExpunge`的值，这个值在后面会讲解，它是用来判断当前过期槽位`staleSlot`之前是否还有过期元素。 + +接着开始以`staleSlot`位置(index=7)向后迭代，**如果找到了相同key值的Entry数据：** + +![](./thread-local/14.png) + +从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，找到后更新`Entry`的值并交换`staleSlot`元素的位置(`staleSlot`位置为过期元素)，更新`Entry`数据，然后开始进行过期`Entry`的清理工作，如下图所示： + +![Yu4oWT.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba9af057e1e?w=1336&h=361&f=png&s=63049) + + +**向后遍历过程中，如果没有找到相同key值的Entry数据：** + +![](./thread-local/15.png) + +从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，直到`Entry`为`null`则停止寻找。通过上图可知，此时`table`中没有`key`值相同的`Entry`。 + +创建新的`Entry`，替换`table[stableSlot]`位置： + +![](./thread-local/16.png) + +替换完成后也是进行过期元素清理工作，清理工作主要是有两个方法：`expungeStaleEntry()`和`cleanSomeSlots()`，具体细节后面会讲到，请继续往后看。 + +#### `ThreadLocalMap.set()`源码详解 + +上面已经用图的方式解析了`set()`实现的原理，其实已经很清晰了，我们接着再看下源码： + +`java.lang.ThreadLocal`.`ThreadLocalMap.set()`: + +```java +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`对应的桶的位置向后查找，找到可以使用的桶。 + +```java +Entry[] tab = table; +int len = tab.length; +int i = key.threadLocalHashCode & (len-1); +``` + +什么情况下桶才是可以使用的呢？ +1. `k = key` 说明是替换操作，可以使用 +2. 碰到一个过期的桶，执行替换逻辑，占用过期桶 +3. 查找过程中，碰到桶中`Entry=null`的情况，直接使用 + +接着就是执行`for`循环遍历，向后查找，我们先看下`nextIndex()`、`prevIndex()`方法实现： + +![](./thread-local/17.png) + +```java +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`循环中的逻辑： +1. 遍历当前`key`值对应的桶中`Entry`数据为空，这说明散列数组这里没有数据冲突，跳出`for`循环，直接`set`数据到对应的桶中 +2. 如果`key`值对应的桶中`Entry`数据不为空 +2.1 如果`k = key`，说明当前`set`操作是一个替换操作，做替换逻辑，直接返回 +2.2 如果`key = null`，说明当前桶位置的`Entry`是过期数据，执行`replaceStaleEntry()`方法(核心方法)，然后返回 +3. `for`循环执行完毕，继续往下执行说明向后迭代的过程中遇到了`entry`为`null`的情况 +3.1 在`Entry`为`null`的桶中创建一个新的`Entry`对象 +3.2 执行`++size`操作 +4. 调用`cleanSomeSlots()`做一次启发式清理工作，清理散列数组中`Entry`的`key`过期的数据 +4.1 如果清理工作完成后，未清理到任何数据，且`size`超过了阈值(数组长度的2/3)，进行`rehash()`操作 +4.2 `rehash()`中会先进行一轮探测式清理，清理过期`key`，清理完成后如果**size >= threshold - threshold / 4**，就会执行真正的扩容逻辑(扩容逻辑往后看) + +接着重点看下`replaceStaleEntry()`方法，`replaceStaleEntry()`方法提供替换过期数据的功能，我们可以对应上面**第四种情况**的原理图来再回顾下，具体代码如下： + +`java.lang.ThreadLocal.ThreadLocalMap.replaceStaleEntry()`: + +```java +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=i` + +```java +for (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);`进行启发式过期数据清理。 + +```java +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` 为当前位置，这个前提是前驱节点扫描时未发现过期数据。 + +```java +if (k == null && slotToExpunge == staleSlot) + slotToExpunge = i; +``` + +往后迭代的过程中如果没有找到`k == key`的数据，且碰到`Entry`为`null`的数据，则结束当前的迭代操作。此时说明这里是一个添加的逻辑，将新的数据添加到`table[staleSlot]` 对应的`slot`中。 + +```java +tab[staleSlot].value = null; +tab[staleSlot] = new Entry(key, value); +``` + +最后判断除了`staleSlot`以外，还发现了其他过期的`slot`数据，就要开启清理数据的逻辑： +```java +if (slotToExpunge != staleSlot) + cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); +``` + +### `ThreadLocalMap`过期key的探测式清理流程 + +上面我们有提及`ThreadLocalMap`的两种过期`key`数据清理方式：**探测式清理**和**启发式清理**。 + +我们先讲下探测式清理，也就是`expungeStaleEntry`方法，遍历散列数组，从开始位置向后探测清理过期数据，将过期数据的`Entry`设置为`null`，沿途中碰到未过期的数据则将此数据`rehash`后重新在`table`数组中定位，如果定位的位置已经有了数据，则会将未过期的数据放到最靠近此位置的`Entry=null`的桶中，使`rehash`后的`Entry`数据距离正确的桶的位置更近一些。操作逻辑如下： + +![](./thread-local/18.png) + +如上图，`set(27)` 经过hash计算后应该落到`index=4`的桶中，由于`index=4`桶已经有了数据，所以往后迭代最终数据放入到`index=7`的桶中，放入后一段时间后`index=5`中的`Entry`数据`key`变为了`null` + +![](./thread-local/19.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()`具体流程，我们还是以先原理图后源码讲解的方式来一步步梳理： + +![](./thread-local/20.png) + +我们假设`expungeStaleEntry(3)` 来调用此方法，如上图所示，我们可以看到`ThreadLocalMap`中`table`的数据情况，接着执行清理操作： + +![](./thread-local/21.png) + +第一步是清空当前`staleSlot`位置的数据，`index=3`位置的`Entry`变成了`null`。然后接着往后探测： + +![](./thread-local/22.png) + +执行完第二步后，index=4的元素挪到index=3的槽位中。 + +继续往后迭代检查，碰到正常数据，计算该数据位置是否偏移，如果被偏移，则重新计算`slot`位置，目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置 + +![](./thread-local/23.png) + +在往后迭代的过程中碰到空的槽位，终止探测，这样一轮探测式清理工作就完成了，接着我们继续看看具体**实现源代码**： + +```java +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--` + +```java +ThreadLocal k = e.get(); + +if (k == null) { + e.value = null; + tab[i] = null; + size--; +} +``` + +如果`key`没有过期，重新计算当前`key`的下标位置是不是当前槽位下标位置，如果不是，那么说明产生了`hash`冲突，此时以新计算出来正确的槽位位置往后迭代，找到最近一个可以存放`entry`的位置。 + +```java +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`位置会更靠近正确位置，这样的话，查询的时候 效率才会更高。 + +### `ThreadLocalMap`扩容机制 + +在``ThreadLocalMap.set()`方法的最后，如果执行完启发式清理工作后，未清理到任何数据，且当前散列数组中`Entry`的数量已经达到了列表的扩容阈值`(len*2/3)`，就开始执行`rehash()`逻辑： + +```java +if (!cleanSomeSlots(i, sz) && sz >= threshold) + rehash(); +``` + +接着看下`rehash()`具体实现： + +```java +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`扩容机制的时候 我们一定要说清楚这两个步骤： + +![](./thread-local/24.png) + +接着看看具体的`resize()`方法，为了方便演示，我们以`oldTab.len=8`来举例： + +![](./thread-local/25.png) + +扩容后的`tab`的大小为`oldLen * 2`，然后遍历老的散列表，重新计算`hash`位置，然后放到新的`tab`数组中，如果出现`hash`冲突则往后寻找最近的`entry`为`null`的槽位，遍历完成之后，`oldTab`中所有的`entry`数据都已经放入到新的`tab`中了。重新计算`tab`下次扩容的**阈值**，具体代码如下： + +```java +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; +} +``` + +### `ThreadLocalMap.get()`详解 + +上面已经看完了`set()`方法的源码，其中包括`set`数据、清理数据、优化数据桶的位置等操作，接着看看`get()`操作的原理。 + +#### `ThreadLocalMap.get()`图解 + +**第一种情况：** 通过查找`key`值计算出散列表中`slot`位置，然后该`slot`位置中的`Entry.key`和查找的`key`一致，则直接返回： + +![](./thread-local/26.png) + +**第二种情况：** `slot`位置中的`Entry.key`和要查找的`key`不一致： + +![](./thread-local/27.png) + +我们以`get(ThreadLocal1)`为例，通过`hash`计算后，正确的`slot`位置应该是4，而`index=4`的槽位已经有了数据，且`key`值不等于``ThreadLocal`1`，所以需要继续往后迭代查找。 + +迭代到`index=5`的数据时，此时`Entry.key=null`，触发一次探测式数据回收操作，执行`expungeStaleEntry()`方法，执行完后，`index 5,8`的数据都会被回收，而`index 6,7`的数据都会前移，此时继续往后迭代，到`index = 6`的时候即找到了`key`值相等的`Entry`数据，如下图所示： + +![](./thread-local/28.png) + +#### `ThreadLocalMap.get()`源码详解 + +`java.lang.ThreadLocal.ThreadLocalMap.getEntry()`: + +```java +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; +} +``` + + +### `ThreadLocalMap`过期key的启发式清理流程 + + +上面多次提及到`ThreadLocalMap`过期可以的两种清理方式：**探测式清理(expungeStaleEntry())**、**启发式清理(cleanSomeSlots())** + +探测式清理是以当前`Entry` 往后清理，遇到值为`null`则结束清理，属于**线性探测清理**。 + +而启发式清理被作者定义为：**Heuristically scan some cells looking for stale entries**. + +![](./thread-local/29.png) + +具体代码如下： + +```java +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; +} +``` + +### `InheritableThreadLocal` + +我们使用`ThreadLocal`的时候，在异步场景下是无法给子线程共享父线程中创建的线程副本数据的。 + +为了解决这个问题，JDK中还有一个`InheritableThreadLocal`类，我们来看一个例子： + +```java +public class InheritableThreadLocalDemo { + public static void main(String[] args) { + ThreadLocal ThreadLocal = new ThreadLocal<>(); + ThreadLocal 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(); + } +} +``` + +打印结果： + +```java +子线程获取父类`ThreadLocal`数据：null +子线程获取父类inheritableThreadLocal数据：父类数据:inheritableThreadLocal +``` + +实现原理是子线程是通过在父线程中通过调用`new Thread()`方法来创建子线程，`Thread#init`方法在`Thread`的构造方法中被调用。在`init`方法中拷贝父线程数据到子线程中： + +```java +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`组件就可以解决这个问题，这里就不再延伸，感兴趣的可自行查阅资料。 + +### `ThreadLocal`项目中使用实战 + +#### `ThreadLocal`使用场景 + +我们现在项目中日志记录用的是`ELK+Logstash`，最后在`Kibana`中进行展示和检索。 + +现在都是分布式系统统一对外提供服务，项目间调用的关系可以通过traceId来关联，但是不同项目之间如何传递`traceId`呢？ + +这里我们使用`org.slf4j.MDC`来实现此功能，内部就是通过`ThreadLocal`来实现的，具体实现如下： + +当前端发送请求到**服务A**时，**服务A**会生成一个类似`UUID`的`traceId`字符串，将此字符串放入当前线程的`ThreadLocal`中，在调用**服务B**的时候，将`traceId`写入到请求的`Header`中，**服务B**在接收请求时会先判断请求的`Header`中是否有`traceId`，如果存在则写入自己线程的`ThreadLocal`中。 + +![](./thread-local/30.png) + +图中的`requestId`即为我们各个系统链路关联的`traceId`，系统间互相调用，通过这个`requestId`即可找到对应链路，这里还有会有一些其他场景： + +![](./thread-local/31.png) + +针对于这些场景，我们都可以有相应的解决方案，如下所示 + +#### Feign远程调用解决方案 + +**服务发送请求：** +```java +@Component +@Slf4j +public class FeignInvokeInterceptor implements RequestInterceptor { + + @Override + public void apply(RequestTemplate template) { + String requestId = MDC.get("requestId"); + if (StringUtils.isNotBlank(requestId)) { + template.header("requestId", requestId); + } + } +} +``` + +**服务接收请求：** +```java +@Slf4j +@Component +public class LogInterceptor extends HandlerInterceptorAdapter { + + @Override + public void afterCompletion(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, Exception arg3) { + MDC.remove("requestId"); + } @Override - public void run() { - System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern()); + public void postHandle(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, ModelAndView arg3) { + } + + @Override + public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { + + String requestId = request.getHeader(BaseConstant.REQUEST_ID_KEY); + if (StringUtils.isBlank(requestId)) { + requestId = UUID.randomUUID().toString().replace("-", ""); + } + MDC.put("requestId", requestId); + return true; + } +} +``` + +#### 线程池异步调用，requestId传递 + +因为`MDC`是基于`ThreadLocal`去实现的，异步过程中，子线程并没有办法获取到父线程`ThreadLocal`存储的数据，所以这里可以自定义线程池执行器，修改其中的`run()`方法： + +```java +public class MyThreadPoolTaskExecutor extends ThreadPoolTaskExecutor { + + @Override + public void execute(Runnable runnable) { + Map context = MDC.getCopyOfContextMap(); + super.execute(() -> run(runnable, context)); + } + + @Override + private void run(Runnable runnable, Map context) { + if (context != null) { + MDC.setContextMap(context); + } try { - Thread.sleep(new Random().nextInt(1000)); - } catch (InterruptedException e) { - e.printStackTrace(); + runnable.run(); + } finally { + MDC.remove(); } - //formatter pattern is changed here by thread, but it won't reflect to other threads - formatter.set(new SimpleDateFormat()); - - System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern()); } - -} - -``` - -Output: - -``` -Thread Name= 0 default Formatter = yyyyMMdd HHmm -Thread Name= 0 formatter = yy-M-d ah:mm -Thread Name= 1 default Formatter = yyyyMMdd HHmm -Thread Name= 2 default Formatter = yyyyMMdd HHmm -Thread Name= 1 formatter = yy-M-d ah:mm -Thread Name= 3 default Formatter = yyyyMMdd HHmm -Thread Name= 2 formatter = yy-M-d ah:mm -Thread Name= 4 default Formatter = yyyyMMdd HHmm -Thread Name= 3 formatter = yy-M-d ah:mm -Thread Name= 4 formatter = yy-M-d ah:mm -Thread Name= 5 default Formatter = yyyyMMdd HHmm -Thread Name= 5 formatter = yy-M-d ah:mm -Thread Name= 6 default Formatter = yyyyMMdd HHmm -Thread Name= 6 formatter = yy-M-d ah:mm -Thread Name= 7 default Formatter = yyyyMMdd HHmm -Thread Name= 7 formatter = yy-M-d ah:mm -Thread Name= 8 default Formatter = yyyyMMdd HHmm -Thread Name= 9 default Formatter = yyyyMMdd HHmm -Thread Name= 8 formatter = yy-M-d ah:mm -Thread Name= 9 formatter = yy-M-d ah:mm -``` - -从输出中可以看出，Thread-0已经改变了formatter的值，但仍然是thread-2默认格式化程序与初始化值相同，其他线程也一样。 - -上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA会提示你转换为Java8的格式(IDEA真的不错！)。因为ThreadLocal类在Java 8中扩展，使用一个新的方法`withInitial()`，将Supplier功能接口作为参数。 - -```java - private static final ThreadLocal formatter = new ThreadLocal(){ - @Override - protected SimpleDateFormat initialValue() - { - return new SimpleDateFormat("yyyyMMdd HHmm"); - } - }; -``` - -### ThreadLocal原理 - -从 `Thread`类源代码入手。 - -```java -public class Thread implements Runnable { - ...... -//与此线程有关的ThreadLocal值。由ThreadLocal类维护 -ThreadLocal.ThreadLocalMap threadLocals = null; - -//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 -ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; - ...... } ``` -从上面`Thread`类 源代码可以看出`Thread` 类中有一个 `threadLocals` 和 一个 `inheritableThreadLocals` 变量，它们都是 `ThreadLocalMap` 类型的变量,我们可以把 `ThreadLocalMap` 理解为`ThreadLocal` 类实现的定制化的 `HashMap`。默认情况下这两个变量都是null，只有当前线程调用 `ThreadLocal` 类的 `set`或`get`方法时才创建它们，实际上调用这两个方法的时候，我们调用的是`ThreadLocalMap`类对应的 `get()`、`set() `方法。 +#### 使用MQ发送消息给第三方系统 -`ThreadLocal`类的`set()`方法 - -```java - public void set(T value) { - Thread t = Thread.currentThread(); - ThreadLocalMap map = getMap(t); - if (map != null) - map.set(this, value); - else - createMap(t, value); - } - ThreadLocalMap getMap(Thread t) { - return t.threadLocals; - } -``` - -通过上面这些内容，我们足以通过猜测得出结论：**最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。** - -**每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为key的键值对。** 比如我们在同一个线程中声明了两个 `ThreadLocal` 对象的话，会使用 `Thread`内部都是使用仅有那个`ThreadLocalMap` 存放数据的，`ThreadLocalMap`的 key 就是 `ThreadLocal`对象，value 就是 `ThreadLocal` 对象调用`set`方法设置的值。`ThreadLocal` 是 map结构是为了让每个线程可以关联多个 `ThreadLocal`变量。这也就解释了ThreadLocal声明的变量为什么在每一个线程都有自己的专属本地变量。 - -```java -public class Thread implements Runnable { - ...... -//与此线程有关的ThreadLocal值。由ThreadLocal类维护 -ThreadLocal.ThreadLocalMap threadLocals = null; - -//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 -ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; - ...... -} -``` - -`ThreadLocalMap`是`ThreadLocal`的静态内部类。 +在MQ发送的消息体中自定义属性`requestId`，接收方消费消息后，自己解析`requestId`使用即可。 -### ThreadLocal 内存泄露问题 -`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用,而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候会 key 会被清理掉，而 value 不会被清理掉。这样一来，`ThreadLocalMap` 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法 -```java - static class Entry extends WeakReference> { - /** The value associated with this ThreadLocal. */ - Object value; - - Entry(ThreadLocal k, Object v) { - super(k); - value = v; - } - } -``` - -**弱引用介绍：** - -> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 -> -> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。 diff --git a/docs/java/Multithread/ThreadLocal2.md b/docs/java/Multithread/ThreadLocal2.md deleted file mode 100644 index 656e680e..00000000 --- a/docs/java/Multithread/ThreadLocal2.md +++ /dev/null @@ -1,941 +0,0 @@ -### 前言 - -![Ym8V9H.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba8d77264d4?w=1579&h=1167&f=png&s=217526) - - -**全文共10000+字，31张图，这篇文章同样耗费了不少的时间和精力才创作完成，原创不易，请大家点点关注+在看，感谢。** - -对于`ThreadLocal`，大家的第一反应可能是很简单呀，线程的变量副本，每个线程隔离。那这里有几个问题大家可以思考一下： - -- **ThreadLocal**的key是**弱引用**，那么在 threadLocal.get()的时候,发生**GC之后**，key是否**为null**？ -- **ThreadLocal**中**ThreadLocalMap**的**数据结构**？ -- **ThreadLocalMap**的**Hash算法**？ -- **ThreadLocalMap**中**Hash冲突**如何解决？ -- **ThreadLocalMap**扩容机制？ -- **ThreadLocalMap**中过期key的清理机制？**探测式清理**和**启发式清理**流程？ -- **ThreadLocalMap.set()**方法实现原理？ -- **ThreadLocalMap.get()**方法实现原理？ -- 项目中**ThreadLocal**使用情况？遇到的坑？ -- ...... - -上述的一些问题你是否都已经掌握的很清楚了呢？本文将围绕这些问题使用图文方式来剖析`ThreadLocal`的**点点滴滴**。 - -### 目录 - - - -- [前言](#前言) -- [目录](#目录) -- [ThreadLocal代码演示](#threadlocal代码演示) -- [ThreadLocal的数据结构](#threadlocal的数据结构) -- [GC 之后key是否为null？](#gc-之后key是否为null) -- [ThreadLocal.set()方法源码详解](#threadlocalset方法源码详解) -- [ThreadLocalMap Hash算法](#threadlocalmap-hash算法) -- [ThreadLocalMap Hash冲突](#threadlocalmap-hash冲突) -- [ThreadLocalMap.set()详解](#threadlocalmapset详解) - - [ThreadLocalMap.set()原理图解](#threadlocalmapset原理图解) - - [ThreadLocalMap.set()源码详解](#threadlocalmapset源码详解) -- [ThreadLocalMap过期key的探测式清理流程](#threadlocalmap过期key的探测式清理流程) -- [ThreadLocalMap扩容机制](#threadlocalmap扩容机制) -- [ThreadLocalMap.get()详解](#threadlocalmapget详解) - - [ThreadLocalMap.get()图解](#threadlocalmapget图解) - - [ThreadLocalMap.get()源码详解](#threadlocalmapget源码详解) -- [ThreadLocalMap过期key的启发式清理流程](#threadlocalmap过期key的启发式清理流程) -- [InheritableThreadLocal](#inheritablethreadlocal) -- [ThreadLocal项目中使用实战](#threadlocal项目中使用实战) - - [ThreadLocal使用场景](#threadlocal使用场景) - - [Feign远程调用解决方案](#feign远程调用解决方案) - - [线程池异步调用，requestId传递](#线程池异步调用requestid传递) - - [使用MQ发送消息给第三方系统](#使用mq发送消息给第三方系统) - - - - -**注明：** 本文源码基于`JDK 1.8` - -### ThreadLocal代码演示 - -我们先看下`ThreadLocal`使用示例： - -```java -public class ThreadLocalTest { - private List messages = Lists.newArrayList(); - - public static final ThreadLocal holder = ThreadLocal.withInitial(ThreadLocalTest::new); - - public static void add(String message) { - holder.get().messages.add(message); - } - - public static List clear() { - List 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(); - } -} -``` - -打印结果： - -```java -[一枝花算不算浪漫] -size: 0 -``` - -`ThreadLocal`对象可以提供线程局部变量，每个线程`Thread`拥有一份自己的**副本变量**，多个线程互不干扰。 - -### ThreadLocal的数据结构 - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba819625d64?w=878&h=551&f=png&s=35947) - - -`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`， 也就是我们常说的弱引用类型。 - -### GC 之后key是否为null？ - -回应开头的那个问题， `ThreadLocal` 的`key`是弱引用，那么在` threadLocal.get()`的时候,发生`GC`之后，`key`是否是`null`？ - -为了搞清楚这个问题，我们需要搞清楚`Java`的**四种引用类型**： - -- **强引用**：我们常常new出来的对象就是强引用类型，只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足的时候 -- **软引用**：使用SoftReference修饰的对象被称为软引用，软引用指向的对象在内存要溢出的时候被回收 -- **弱引用**：使用WeakReference修饰的对象被称为弱引用，只要发生垃圾回收，若这个对象只被弱引用指向，那么就会被回收 -- **虚引用**：虚引用是最弱的引用，在 Java 中使用 PhantomReference 进行定义。虚引用中唯一的作用就是用队列接收对象即将死亡的通知 - - -接着再来看下代码，我们使用反射的方式来看看`GC`后`ThreadLocal`中的数据情况：(下面代码来源自：https://blog.csdn.net/thewindkee/article/details/103726942，本地运行演示GC回收场景) - -```java -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 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(); - } - } -} -``` - -结果如下： -```java -弱引用key:java.lang.ThreadLocal@433619b6,值:abc -弱引用key:java.lang.ThreadLocal@418a15e3,值:java.lang.ref.SoftReference@bf97a12 ---gc后-- -弱引用key:null,值:def -``` - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba81584d3ca?w=1568&h=561&f=png&s=137867) - -如图所示，因为这里创建的`ThreadLocal`并没有指向任何值，也就是没有任何引用： - -```java -new ThreadLocal<>().set(s); -``` - -所以这里在`GC`之后，`key`就会被回收，我们看到上面`debug`中的`referent=null`, 如果**改动一下代码：** - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba815948bf9?w=1336&h=590&f=png&s=131688) - -这个问题刚开始看，如果没有过多思考，**弱引用**，还有**垃圾回收**，那么肯定会觉得是`null`。 - -其实是不对的，因为题目说的是在做 `threadlocal.get()` 操作，证明其实还是有**强引用**存在的，所以 `key` 并不为 `null`，如下图所示，`ThreadLocal`的**强引用**仍然是存在的。 - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba81bd745e6?w=1219&h=394&f=png&s=25434) - -如果我们的**强引用**不存在的话，那么 `key` 就会被回收，也就是会出现我们 `value` 没被回收，`key` 被回收，导致 `value` 永远存在，出现内存泄漏。 - -### ThreadLocal.set()方法源码详解 - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba897dc6204?w=1284&h=448&f=png&s=51070) - -`ThreadLocal`中的`set`方法原理如上图所示，很简单，主要是判断`ThreadLocalMap`是否存在，然后使用`ThreadLocal`中的`set`方法进行数据处理。 - -代码如下： - -```java -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`中的，一步步往下看，后面还有更详细的剖析。 - -### ThreadLocalMap Hash算法 - -既然是`Map`结构，那么`ThreadLocalMap`当然也要实现自己的`hash`算法来解决散列表数组冲突问题。 - -```java -int i = key.threadLocalHashCode & (len-1); -``` - -`ThreadLocalMap`中`hash`算法很简单，这里`i`就是当前key在散列表中对应的数组下标位置。 - -这里最关键的就是`threadLocalHashCode`值的计算，`ThreadLocal`中有一个属性为`HASH_INCREMENT = 0x61c88647` - -```java -public class ThreadLocal { - 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` **分布非常均匀**。 - -我们自己可以尝试下： - -![YKbSGn.png](https://user-gold-cdn.xitu.io/2020/5/8/171f4d82ead289da?w=1743&h=887&f=png&s=113401) - -可以看到产生的哈希码分布很均匀，这里不去细纠**斐波那契**具体算法，感兴趣的可以自行查阅相关资料。 - -### ThreadLocalMap Hash冲突 - -> **注明：** 下面所有示例图中，**绿色块**`Entry`代表**正常数据**，**灰色块**代表`Entry`的`key`值为`null`，**已被垃圾回收**。**白色块**表示`Entry`为`null`。 - -虽然`ThreadLocalMap`中使用了**黄金分隔数来**作为`hash`计算因子，大大减少了`Hash`冲突的概率，但是仍然会存在冲突。 - -`HashMap`中解决冲突的方法是在数组上构造一个**链表**结构，冲突的数据挂载到链表上，如果链表长度超过一定数量则会转化成**红黑树**。 - -而`ThreadLocalMap`中并没有链表结构，所以这里不能适用`HashMap`解决冲突的方式了。 - -![Ynzr5D.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba8fc715e1b?w=1478&h=424&f=png&s=66966) - - -如上图所示，如果我们插入一个`value=27`的数据，通过`hash`计算后应该落入第4个槽位中，而槽位4已经有了`Entry`数据。 - -此时就会线性向后查找，一直找到`Entry`为`null`的槽位才会停止查找，将当前元素放入此槽位中。当然迭代过程中还有其他的情况，比如遇到了`Entry`不为`null`且`key`值相等的情况，还有`Entry`中的`key`值为`null`的情况等等都会有不同的处理，后面会一一详细讲解。 - -这里还画了一个`Entry`中的`key`为`null`的数据（**Entry=2的灰色块数据**），因为`key`值是**弱引用**类型，所以会有这种数据存在。在`set`过程中，如果遇到了`key`过期的`Entry`数据，实际上是会进行一轮**探测式清理**操作的，具体操作方式后面会讲到。 - - -### ThreadLocalMap.set()详解 - -#### ThreadLocalMap.set()原理图解 - -看完了`ThreadLocal` **hash算法**后，我们再来看`set`是如何实现的。 - -往`ThreadLocalMap`中`set`数据（**新增**或者**更新**数据）分为好几种情况，针对不同的情况我们画图来说说明。 - -**第一种情况：** 通过`hash`计算后的槽位对应的`Entry`数据为空： - -![YuSniD.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba95568266d?w=1494&h=363&f=png&s=47111) - -这里直接将数据放到该槽位即可。 - -**第二种情况：** 槽位数据不为空，`key`值与当前`ThreadLocal`通过`hash`计算获取的`key`值一致： - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba8ec7d6e78?w=1212&h=376&f=png&s=32578) - -这里直接更新该槽位的数据。 - -**第三种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，没有遇到`key`过期的`Entry`： - -![image.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba902a2896a?w=1238&h=398&f=png&s=41278) - -遍历散列数组，线性往后查找，如果找到`Entry`为`null`的槽位，则将数据放入该槽位中，或者往后遍历过程中，遇到了**key值相等**的数据，直接更新即可。 - -**第四种情况：** 槽位数据不为空，往后遍历过程中，在找到`Entry`为`null`的槽位之前，遇到`key`过期的`Entry`，如下图，往后遍历过程中，一到了`index=7`的槽位数据`Entry`的`key=null`： - -![Yu77qg.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba9509b36c1?w=1318&h=404&f=png&s=75663) - -散列数组下标为7位置对应的`Entry`数据`key`为`null`，表明此数据`key`值已经被垃圾回收掉了，此时就会执行`replaceStaleEntry()`方法，该方法含义是**替换过期数据的逻辑**，以**index=7**位起点开始遍历，进行探测式数据清理工作。 - -初始化探测式清理过期数据扫描的开始位置：`slotToExpunge = staleSlot = 7` - -以当前`staleSlot`开始 向前迭代查找，找其他过期的数据，然后更新过期数据起始扫描下标`slotToExpunge`。`for`循环迭代，直到碰到`Entry`为`null`结束。 - -如果找到了过期的数据，继续向前迭代，直到遇到`Entry=null`的槽位才停止迭代，如下图所示，**slotToExpunge被更新为0**： - -![YuHSMT.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba957014857?w=1347&h=470&f=png&s=100229) - -以当前节点(`index=7`)向前迭代，检测是否有过期的`Entry`数据，如果有则更新`slotToExpunge`值。碰到`null`则结束探测。以上图为例`slotToExpunge`被更新为0。 - -上面向前迭代的操作是为了更新探测清理过期数据的起始下标`slotToExpunge`的值，这个值在后面会讲解，它是用来判断当前过期槽位`staleSlot`之前是否还有过期元素。 - -接着开始以`staleSlot`位置(index=7)向后迭代，**如果找到了相同key值的Entry数据：** - -![YuHEJ1.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba96c6b080d?w=1353&h=487&f=png&s=95173) - -从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，找到后更新`Entry`的值并交换`staleSlot`元素的位置(`staleSlot`位置为过期元素)，更新`Entry`数据，然后开始进行过期`Entry`的清理工作，如下图所示： - -![Yu4oWT.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba9af057e1e?w=1336&h=361&f=png&s=63049) - - -**向后遍历过程中，如果没有找到相同key值的Entry数据：** - -![YuHMee.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba9848c608b?w=1336&h=397&f=png&s=73680) - -从当前节点`staleSlot`向后查找`key`值相等的`Entry`元素，直到`Entry`为`null`则停止寻找。通过上图可知，此时`table`中没有`key`值相同的`Entry`。 - -创建新的`Entry`，替换`table[stableSlot]`位置： - -![YuH3FA.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3ba9da434d2b?w=1341&h=398&f=png&s=61130) - -替换完成后也是进行过期元素清理工作，清理工作主要是有两个方法：`expungeStaleEntry()`和`cleanSomeSlots()`，具体细节后面会讲到，请继续往后看。 - -#### ThreadLocalMap.set()源码详解 - -上面已经用图的方式解析了`set()`实现的原理，其实已经很清晰了，我们接着再看下源码： - -`java.lang.ThreadLocal.ThreadLocalMap.set()`: - -```java -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`对应的桶的位置向后查找，找到可以使用的桶。 - -```java -Entry[] tab = table; -int len = tab.length; -int i = key.threadLocalHashCode & (len-1); -``` - -什么情况下桶才是可以使用的呢？ -1. `k = key` 说明是替换操作，可以使用 -2. 碰到一个过期的桶，执行替换逻辑，占用过期桶 -3. 查找过程中，碰到桶中`Entry=null`的情况，直接使用 - -接着就是执行`for`循环遍历，向后查找，我们先看下`nextIndex()`、`prevIndex()`方法实现： - -![YZSC5j.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa0b7231c8?w=861&h=389&f=png&s=32052) - -```java -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`循环中的逻辑： -1. 遍历当前`key`值对应的桶中`Entry`数据为空，这说明散列数组这里没有数据冲突，跳出`for`循环，直接`set`数据到对应的桶中 -2. 如果`key`值对应的桶中`Entry`数据不为空 -2.1 如果`k = key`，说明当前`set`操作是一个替换操作，做替换逻辑，直接返回 -2.2 如果`key = null`，说明当前桶位置的`Entry`是过期数据，执行`replaceStaleEntry()`方法(核心方法)，然后返回 -3. `for`循环执行完毕，继续往下执行说明向后迭代的过程中遇到了`entry`为`null`的情况 -3.1 在`Entry`为`null`的桶中创建一个新的`Entry`对象 -3.2 执行`++size`操作 -4. 调用`cleanSomeSlots()`做一次启发式清理工作，清理散列数组中`Entry`的`key`过期的数据 -4.1 如果清理工作完成后，未清理到任何数据，且`size`超过了阈值(数组长度的2/3)，进行`rehash()`操作 -4.2 `rehash()`中会先进行一轮探测式清理，清理过期`key`，清理完成后如果**size >= threshold - threshold / 4**，就会执行真正的扩容逻辑(扩容逻辑往后看) - -接着重点看下`replaceStaleEntry()`方法，`replaceStaleEntry()`方法提供替换过期数据的功能，我们可以对应上面**第四种情况**的原理图来再回顾下，具体代码如下： - -`java.lang.ThreadLocal.ThreadLocalMap.replaceStaleEntry()`: - -```java -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=i` - -```java -for (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);`进行启发式过期数据清理。 - -```java -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` 为当前位置，这个前提是前驱节点扫描时未发现过期数据。 - -```java -if (k == null && slotToExpunge == staleSlot) - slotToExpunge = i; -``` - -往后迭代的过程中如果没有找到`k == key`的数据，且碰到`Entry`为`null`的数据，则结束当前的迭代操作。此时说明这里是一个添加的逻辑，将新的数据添加到`table[staleSlot]` 对应的`slot`中。 - -```java -tab[staleSlot].value = null; -tab[staleSlot] = new Entry(key, value); -``` - -最后判断除了`staleSlot`以外，还发现了其他过期的`slot`数据，就要开启清理数据的逻辑： -```java -if (slotToExpunge != staleSlot) - cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); -``` - -### ThreadLocalMap过期key的探测式清理流程 - -上面我们有提及`ThreadLocalMap`的两种过期`key`数据清理方式：**探测式清理**和**启发式清理**。 - -我们先讲下探测式清理，也就是`expungeStaleEntry`方法，遍历散列数组，从开始位置向后探测清理过期数据，将过期数据的`Entry`设置为`null`，沿途中碰到未过期的数据则将此数据`rehash`后重新在`table`数组中定位，如果定位的位置已经有了数据，则会将未过期的数据放到最靠近此位置的`Entry=null`的桶中，使`rehash`后的`Entry`数据距离正确的桶的位置更近一些。操作逻辑如下： - -![YuH2OU.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa1285c833?w=1373&h=324&f=png&s=73657) - -如上图，`set(27)` 经过hash计算后应该落到`index=4`的桶中，由于`index=4`桶已经有了数据，所以往后迭代最终数据放入到`index=7`的桶中，放入后一段时间后`index=5`中的`Entry`数据`key`变为了`null` - -![YuHb6K.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa2cc322cb?w=1351&h=384&f=png&s=96329) - -如果再有其他数据`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()`具体流程，我们还是以先原理图后源码讲解的方式来一步步梳理： - -![Yuf301.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa2a52731c?w=1113&h=377&f=png&s=49974) - -我们假设`expungeStaleEntry(3)` 来调用此方法，如上图所示，我们可以看到`ThreadLocalMap`中`table`的数据情况，接着执行清理操作： - -![YufupF.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa72c52453?w=908&h=231&f=png&s=29340) - -第一步是清空当前`staleSlot`位置的数据，`index=3`位置的`Entry`变成了`null`。然后接着往后探测： - -![YufAwq.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa8b341c89?w=1256&h=396&f=png&s=95675) - -执行完第二步后，index=4的元素挪到index=3的槽位中。 - -继续往后迭代检查，碰到正常数据，计算该数据位置是否偏移，如果被偏移，则重新计算`slot`位置，目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置 - -![YuWjTP.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baa9503bd8d?w=1029&h=287&f=png&s=32999) - -在往后迭代的过程中碰到空的槽位，终止探测，这样一轮探测式清理工作就完成了，接着我们继续看看具体**实现源代码**： - -```java -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--` - -```java -ThreadLocal k = e.get(); - -if (k == null) { - e.value = null; - tab[i] = null; - size--; -} -``` - -如果`key`没有过期，重新计算当前`key`的下标位置是不是当前槽位下标位置，如果不是，那么说明产生了`hash`冲突，此时以新计算出来正确的槽位位置往后迭代，找到最近一个可以存放`entry`的位置。 - -```java -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`位置会更靠近正确位置，这样的话，查询的时候 效率才会更高。 - -### ThreadLocalMap扩容机制 - -在`ThreadLocalMap.set()`方法的最后，如果执行完启发式清理工作后，未清理到任何数据，且当前散列数组中`Entry`的数量已经达到了列表的扩容阈值`(len*2/3)`，就开始执行`rehash()`逻辑： - -```java -if (!cleanSomeSlots(i, sz) && sz >= threshold) - rehash(); -``` - -接着看下`rehash()`具体实现： - -```java -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`扩容机制的时候 我们一定要说清楚这两个步骤： - -![YuqwPs.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baaa9f7fb5f?w=1483&h=511&f=png&s=76905) - -接着看看具体的`resize()`方法，为了方便演示，我们以`oldTab.len=8`来举例： - -![Yu2QOI.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baad1dec348?w=1438&h=366&f=png&s=70262) - -扩容后的`tab`的大小为`oldLen * 2`，然后遍历老的散列表，重新计算`hash`位置，然后放到新的`tab`数组中，如果出现`hash`冲突则往后寻找最近的`entry`为`null`的槽位，遍历完成之后，`oldTab`中所有的`entry`数据都已经放入到新的`tab`中了。重新计算`tab`下次扩容的**阈值**，具体代码如下： - -```java -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; -} -``` - -### ThreadLocalMap.get()详解 - -上面已经看完了`set()`方法的源码，其中包括`set`数据、清理数据、优化数据桶的位置等操作，接着看看`get()`操作的原理。 - -#### ThreadLocalMap.get()图解 - -**第一种情况：** 通过查找`key`值计算出散列表中`slot`位置，然后该`slot`位置中的`Entry.key`和查找的`key`一致，则直接返回： - -![YuWfdx.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3baaed5b6b60?w=1342&h=404&f=png&s=55569) - -**第二种情况：** `slot`位置中的`Entry.key`和要查找的`key`不一致： - -![YuWyz4.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3bab054f8f50?w=1288&h=423&f=png&s=69512) - -我们以`get(ThreadLocal1)`为例，通过`hash`计算后，正确的`slot`位置应该是4，而`index=4`的槽位已经有了数据，且`key`值不等于`ThreadLocal1`，所以需要继续往后迭代查找。 - -迭代到`index=5`的数据时，此时`Entry.key=null`，触发一次探测式数据回收操作，执行`expungeStaleEntry()`方法，执行完后，`index 5,8`的数据都会被回收，而`index 6,7`的数据都会前移，此时继续往后迭代，到`index = 6`的时候即找到了`key`值相等的`Entry`数据，如下图所示： - -![YuW8JS.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3bab26c905a5?w=1443&h=421&f=png&s=91983) - -#### ThreadLocalMap.get()源码详解 - -`java.lang.ThreadLocal.ThreadLocalMap.getEntry()`: - -```java -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; -} -``` - - -### ThreadLocalMap过期key的启发式清理流程 - - -上面多次提及到`ThreadLocalMap`过期可以的两种清理方式：**探测式清理(expungeStaleEntry())**、**启发式清理(cleanSomeSlots())** - -探测式清理是以当前`Entry` 往后清理，遇到值为`null`则结束清理，属于**线性探测清理**。 - -而启发式清理被作者定义为：**Heuristically scan some cells looking for stale entries**. - -![YK5HJ0.png](https://user-gold-cdn.xitu.io/2020/5/8/171f49d18669ff50?w=1434&h=924&f=png&s=90010) - -具体代码如下： - -```java -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; -} -``` - -### InheritableThreadLocal - -我们使用`ThreadLocal`的时候，在异步场景下是无法给子线程共享父线程中创建的线程副本数据的。 - -为了解决这个问题，JDK中还有一个`InheritableThreadLocal`类，我们来看一个例子： - -```java -public class InheritableThreadLocalDemo { - public static void main(String[] args) { - ThreadLocal threadLocal = new ThreadLocal<>(); - ThreadLocal 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(); - } -} -``` - -打印结果： - -```java -子线程获取父类threadLocal数据：null -子线程获取父类inheritableThreadLocal数据：父类数据:inheritableThreadLocal -``` - -实现原理是子线程是通过在父线程中通过调用`new Thread()`方法来创建子线程，`Thread#init`方法在`Thread`的构造方法中被调用。在`init`方法中拷贝父线程数据到子线程中： - -```java -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`组件就可以解决这个问题，这里就不再延伸，感兴趣的可自行查阅资料。 - -### ThreadLocal项目中使用实战 - -#### ThreadLocal使用场景 - -我们现在项目中日志记录用的是`ELK+Logstash`，最后在`Kibana`中进行展示和检索。 - -现在都是分布式系统统一对外提供服务，项目间调用的关系可以通过traceId来关联，但是不同项目之间如何传递`traceId`呢？ - -这里我们使用`org.slf4j.MDC`来实现此功能，内部就是通过`ThreadLocal`来实现的，具体实现如下： - -当前端发送请求到**服务A**时，**服务A**会生成一个类似`UUID`的`traceId`字符串，将此字符串放入当前线程的`ThreadLocal`中，在调用**服务B**的时候，将`traceId`写入到请求的`Header`中，**服务B**在接收请求时会先判断请求的`Header`中是否有`traceId`，如果存在则写入自己线程的`ThreadLocal`中。 - -![YeMO3t.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3bb27f41cec0?w=1657&h=554&f=png&s=65612) - -图中的`requestId`即为我们各个系统链路关联的`traceId`，系统间互相调用，通过这个`requestId`即可找到对应链路，这里还有会有一些其他场景： - -![Ym3861.png](https://user-gold-cdn.xitu.io/2020/5/8/171f3bb290c4d1d1?w=965&h=469&f=png&s=29983) - -针对于这些场景，我们都可以有相应的解决方案，如下所示 - -#### Feign远程调用解决方案 - -**服务发送请求：** -```java -@Component -@Slf4j -public class FeignInvokeInterceptor implements RequestInterceptor { - - @Override - public void apply(RequestTemplate template) { - String requestId = MDC.get("requestId"); - if (StringUtils.isNotBlank(requestId)) { - template.header("requestId", requestId); - } - } -} -``` - -**服务接收请求：** -```java -@Slf4j -@Component -public class LogInterceptor extends HandlerInterceptorAdapter { - - @Override - public void afterCompletion(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, Exception arg3) { - MDC.remove("requestId"); - } - - @Override - public void postHandle(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, ModelAndView arg3) { - } - - @Override - public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { - - String requestId = request.getHeader(BaseConstant.REQUEST_ID_KEY); - if (StringUtils.isBlank(requestId)) { - requestId = UUID.randomUUID().toString().replace("-", ""); - } - MDC.put("requestId", requestId); - return true; - } -} -``` - -#### 线程池异步调用，requestId传递 - -因为`MDC`是基于`ThreadLocal`去实现的，异步过程中，子线程并没有办法获取到父线程`ThreadLocal`存储的数据，所以这里可以自定义线程池执行器，修改其中的`run()`方法： - -```java -public class MyThreadPoolTaskExecutor extends ThreadPoolTaskExecutor { - - @Override - public void execute(Runnable runnable) { - Map context = MDC.getCopyOfContextMap(); - super.execute(() -> run(runnable, context)); - } - - @Override - private void run(Runnable runnable, Map context) { - if (context != null) { - MDC.setContextMap(context); - } - try { - runnable.run(); - } finally { - MDC.remove(); - } - } -} -``` - -#### 使用MQ发送消息给第三方系统 - -在MQ发送的消息体中自定义属性`requestId`，接收方消费消息后，自己解析`requestId`使用即可。 - -[1]:https://juejin.im/post/5eacc1c75188256d976df748 - - - diff --git a/docs/java/Multithread/ThreadLocal（未完成）.md b/docs/java/Multithread/ThreadLocal（未完成）.md new file mode 100644 index 00000000..f69cc1d6 --- /dev/null +++ b/docs/java/Multithread/ThreadLocal（未完成）.md @@ -0,0 +1,170 @@ +[ThreadLocal造成OOM内存溢出案例演示与原理分析](https://blog.csdn.net/xlgen157387/article/details/78298840) + +[深入理解 Java 之 ThreadLocal 工作原理]() + +## ThreadLocal + +### ThreadLocal简介 + +通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。**如果想实现每一个线程都有自己的专属本地变量该如何解决呢？** JDK中提供的`ThreadLocal`类正是为了解决这样的问题。 **`ThreadLocal`类主要解决的就是让每个线程绑定自己的值，可以将`ThreadLocal`类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。** + +**如果你创建了一个`ThreadLocal`变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是`ThreadLocal`变量名的由来。他们可以使用 `get（）` 和 `set（）` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。** + +再举个简单的例子： + +比如有两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么ThreadLocal就是用来这两个线程竞争的。 + +### ThreadLocal示例 + +相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。 + +```java +import java.text.SimpleDateFormat; +import java.util.Random; + +public class ThreadLocalExample implements Runnable{ + + // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本 + private static final ThreadLocal formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm")); + + public static void main(String[] args) throws InterruptedException { + ThreadLocalExample obj = new ThreadLocalExample(); + for(int i=0 ; i<10; i++){ + Thread t = new Thread(obj, ""+i); + Thread.sleep(new Random().nextInt(1000)); + t.start(); + } + } + + @Override + public void run() { + System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern()); + try { + Thread.sleep(new Random().nextInt(1000)); + } catch (InterruptedException e) { + e.printStackTrace(); + } + //formatter pattern is changed here by thread, but it won't reflect to other threads + formatter.set(new SimpleDateFormat()); + + System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern()); + } + +} + +``` + +Output: + +``` +Thread Name= 0 default Formatter = yyyyMMdd HHmm +Thread Name= 0 formatter = yy-M-d ah:mm +Thread Name= 1 default Formatter = yyyyMMdd HHmm +Thread Name= 2 default Formatter = yyyyMMdd HHmm +Thread Name= 1 formatter = yy-M-d ah:mm +Thread Name= 3 default Formatter = yyyyMMdd HHmm +Thread Name= 2 formatter = yy-M-d ah:mm +Thread Name= 4 default Formatter = yyyyMMdd HHmm +Thread Name= 3 formatter = yy-M-d ah:mm +Thread Name= 4 formatter = yy-M-d ah:mm +Thread Name= 5 default Formatter = yyyyMMdd HHmm +Thread Name= 5 formatter = yy-M-d ah:mm +Thread Name= 6 default Formatter = yyyyMMdd HHmm +Thread Name= 6 formatter = yy-M-d ah:mm +Thread Name= 7 default Formatter = yyyyMMdd HHmm +Thread Name= 7 formatter = yy-M-d ah:mm +Thread Name= 8 default Formatter = yyyyMMdd HHmm +Thread Name= 9 default Formatter = yyyyMMdd HHmm +Thread Name= 8 formatter = yy-M-d ah:mm +Thread Name= 9 formatter = yy-M-d ah:mm +``` + +从输出中可以看出，Thread-0已经改变了formatter的值，但仍然是thread-2默认格式化程序与初始化值相同，其他线程也一样。 + +上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA会提示你转换为Java8的格式(IDEA真的不错！)。因为ThreadLocal类在Java 8中扩展，使用一个新的方法`withInitial()`，将Supplier功能接口作为参数。 + +```java + private static final ThreadLocal formatter = new ThreadLocal(){ + @Override + protected SimpleDateFormat initialValue() + { + return new SimpleDateFormat("yyyyMMdd HHmm"); + } + }; +``` + +### ThreadLocal原理 + +从 `Thread`类源代码入手。 + +```java +public class Thread implements Runnable { + ...... +//与此线程有关的ThreadLocal值。由ThreadLocal类维护 +ThreadLocal.ThreadLocalMap threadLocals = null; + +//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 +ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; + ...... +} +``` + +从上面`Thread`类 源代码可以看出`Thread` 类中有一个 `threadLocals` 和 一个 `inheritableThreadLocals` 变量，它们都是 `ThreadLocalMap` 类型的变量,我们可以把 `ThreadLocalMap` 理解为`ThreadLocal` 类实现的定制化的 `HashMap`。默认情况下这两个变量都是null，只有当前线程调用 `ThreadLocal` 类的 `set`或`get`方法时才创建它们，实际上调用这两个方法的时候，我们调用的是`ThreadLocalMap`类对应的 `get()`、`set() `方法。 + +`ThreadLocal`类的`set()`方法 + +```java + public void set(T value) { + Thread t = Thread.currentThread(); + ThreadLocalMap map = getMap(t); + if (map != null) + map.set(this, value); + else + createMap(t, value); + } + ThreadLocalMap getMap(Thread t) { + return t.threadLocals; + } +``` + +通过上面这些内容，我们足以通过猜测得出结论：**最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。** + +**每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为key的键值对。** 比如我们在同一个线程中声明了两个 `ThreadLocal` 对象的话，会使用 `Thread`内部都是使用仅有那个`ThreadLocalMap` 存放数据的，`ThreadLocalMap`的 key 就是 `ThreadLocal`对象，value 就是 `ThreadLocal` 对象调用`set`方法设置的值。`ThreadLocal` 是 map结构是为了让每个线程可以关联多个 `ThreadLocal`变量。这也就解释了ThreadLocal声明的变量为什么在每一个线程都有自己的专属本地变量。 + +```java +public class Thread implements Runnable { + ...... +//与此线程有关的ThreadLocal值。由ThreadLocal类维护 +ThreadLocal.ThreadLocalMap threadLocals = null; + +//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护 +ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; + ...... +} +``` + +`ThreadLocalMap`是`ThreadLocal`的静态内部类。 + + + +### ThreadLocal 内存泄露问题 + +`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用,而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候会 key 会被清理掉，而 value 不会被清理掉。这样一来，`ThreadLocalMap` 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法 + +```java + static class Entry extends WeakReference> { + /** The value associated with this ThreadLocal. */ + Object value; + + Entry(ThreadLocal k, Object v) { + super(k); + value = v; + } + } +``` + +**弱引用介绍：** + +> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。 +> +> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。 diff --git a/docs/java/Multithread/thread-local/1.png b/docs/java/Multithread/thread-local/1.png new file mode 100644 index 00000000..b394e304 Binary files /dev/null and b/docs/java/Multithread/thread-local/1.png differ diff --git a/docs/java/Multithread/thread-local/10.png b/docs/java/Multithread/thread-local/10.png new file mode 100644 index 00000000..c9edb13f Binary files /dev/null and b/docs/java/Multithread/thread-local/10.png differ diff --git a/docs/java/Multithread/thread-local/11.png b/docs/java/Multithread/thread-local/11.png new file mode 100644 index 00000000..06d30638 Binary files /dev/null and b/docs/java/Multithread/thread-local/11.png differ diff --git a/docs/java/Multithread/thread-local/12.png b/docs/java/Multithread/thread-local/12.png new file mode 100644 index 00000000..bd765217 Binary files /dev/null and b/docs/java/Multithread/thread-local/12.png differ diff --git a/docs/java/Multithread/thread-local/13.png b/docs/java/Multithread/thread-local/13.png new file mode 100644 index 00000000..34c8d8c8 Binary files /dev/null and b/docs/java/Multithread/thread-local/13.png differ diff --git a/docs/java/Multithread/thread-local/14.png b/docs/java/Multithread/thread-local/14.png new file mode 100644 index 00000000..b1b3abd6 Binary files /dev/null and b/docs/java/Multithread/thread-local/14.png differ diff --git a/docs/java/Multithread/thread-local/15.png b/docs/java/Multithread/thread-local/15.png new file mode 100644 index 00000000..25f5cb2b Binary files /dev/null and b/docs/java/Multithread/thread-local/15.png differ diff --git a/docs/java/Multithread/thread-local/16.png b/docs/java/Multithread/thread-local/16.png new file mode 100644 index 00000000..45d0424f Binary files /dev/null and b/docs/java/Multithread/thread-local/16.png differ diff --git a/docs/java/Multithread/thread-local/17.png b/docs/java/Multithread/thread-local/17.png new file mode 100644 index 00000000..3194e4a3 Binary files /dev/null and b/docs/java/Multithread/thread-local/17.png differ diff --git a/docs/java/Multithread/thread-local/18.png b/docs/java/Multithread/thread-local/18.png new file mode 100644 index 00000000..2b340b0b Binary files /dev/null and b/docs/java/Multithread/thread-local/18.png differ diff --git a/docs/java/Multithread/thread-local/19.png b/docs/java/Multithread/thread-local/19.png new file mode 100644 index 00000000..4c906279 Binary files /dev/null and b/docs/java/Multithread/thread-local/19.png differ diff --git a/docs/java/Multithread/thread-local/2.png b/docs/java/Multithread/thread-local/2.png new file mode 100644 index 00000000..c9af80e1 Binary files /dev/null and b/docs/java/Multithread/thread-local/2.png differ diff --git a/docs/java/Multithread/thread-local/20.png b/docs/java/Multithread/thread-local/20.png new file mode 100644 index 00000000..234c32a6 Binary files /dev/null and b/docs/java/Multithread/thread-local/20.png differ diff --git a/docs/java/Multithread/thread-local/21.png b/docs/java/Multithread/thread-local/21.png new file mode 100644 index 00000000..1b5a02b9 Binary files /dev/null and b/docs/java/Multithread/thread-local/21.png differ diff --git a/docs/java/Multithread/thread-local/22.png b/docs/java/Multithread/thread-local/22.png new file mode 100644 index 00000000..62eeff12 Binary files /dev/null and b/docs/java/Multithread/thread-local/22.png differ diff --git a/docs/java/Multithread/thread-local/23.png b/docs/java/Multithread/thread-local/23.png new file mode 100644 index 00000000..0b4a0409 Binary files /dev/null and b/docs/java/Multithread/thread-local/23.png differ diff --git a/docs/java/Multithread/thread-local/24.png b/docs/java/Multithread/thread-local/24.png new file mode 100644 index 00000000..ae2fe0df Binary files /dev/null and b/docs/java/Multithread/thread-local/24.png differ diff --git a/docs/java/Multithread/thread-local/25.png b/docs/java/Multithread/thread-local/25.png new file mode 100644 index 00000000..9c66e254 Binary files /dev/null and b/docs/java/Multithread/thread-local/25.png differ diff --git a/docs/java/Multithread/thread-local/26.png b/docs/java/Multithread/thread-local/26.png new file mode 100644 index 00000000..ef53f0a9 Binary files /dev/null and b/docs/java/Multithread/thread-local/26.png differ diff --git a/docs/java/Multithread/thread-local/27.png b/docs/java/Multithread/thread-local/27.png new file mode 100644 index 00000000..61710050 Binary files /dev/null and b/docs/java/Multithread/thread-local/27.png differ diff --git a/docs/java/Multithread/thread-local/28.png b/docs/java/Multithread/thread-local/28.png new file mode 100644 index 00000000..68f67602 Binary files /dev/null and b/docs/java/Multithread/thread-local/28.png differ diff --git a/docs/java/Multithread/thread-local/29.png b/docs/java/Multithread/thread-local/29.png new file mode 100644 index 00000000..d662f80b Binary files /dev/null and b/docs/java/Multithread/thread-local/29.png differ diff --git a/docs/java/Multithread/thread-local/3.png b/docs/java/Multithread/thread-local/3.png new file mode 100644 index 00000000..a0b418c0 Binary files /dev/null and b/docs/java/Multithread/thread-local/3.png differ diff --git a/docs/java/Multithread/thread-local/30.png b/docs/java/Multithread/thread-local/30.png new file mode 100644 index 00000000..27ec27f7 Binary files /dev/null and b/docs/java/Multithread/thread-local/30.png differ diff --git a/docs/java/Multithread/thread-local/31.png b/docs/java/Multithread/thread-local/31.png new file mode 100644 index 00000000..96b83ca1 Binary files /dev/null and b/docs/java/Multithread/thread-local/31.png differ diff --git a/docs/java/Multithread/thread-local/4.png b/docs/java/Multithread/thread-local/4.png new file mode 100644 index 00000000..b0278b70 Binary files /dev/null and b/docs/java/Multithread/thread-local/4.png differ diff --git a/docs/java/Multithread/thread-local/5.png b/docs/java/Multithread/thread-local/5.png new file mode 100644 index 00000000..81f24a08 Binary files /dev/null and b/docs/java/Multithread/thread-local/5.png differ diff --git a/docs/java/Multithread/thread-local/6.png b/docs/java/Multithread/thread-local/6.png new file mode 100644 index 00000000..66dc77c1 Binary files /dev/null and b/docs/java/Multithread/thread-local/6.png differ diff --git a/docs/java/Multithread/thread-local/7.png b/docs/java/Multithread/thread-local/7.png new file mode 100644 index 00000000..d13653a0 Binary files /dev/null and b/docs/java/Multithread/thread-local/7.png differ diff --git a/docs/java/Multithread/thread-local/8.png b/docs/java/Multithread/thread-local/8.png new file mode 100644 index 00000000..b7e466d8 Binary files /dev/null and b/docs/java/Multithread/thread-local/8.png differ diff --git a/docs/java/Multithread/thread-local/9.png b/docs/java/Multithread/thread-local/9.png new file mode 100644 index 00000000..5964fb0c Binary files /dev/null and b/docs/java/Multithread/thread-local/9.png differ diff --git a/media/sponsor/WechatIMG143.jpeg b/media/sponsor/WechatIMG143.jpeg deleted file mode 100644 index 5e1b53b4..00000000 Binary files a/media/sponsor/WechatIMG143.jpeg and /dev/null differ diff --git a/media/sponsor/WechatIMG26.jpeg b/media/sponsor/WechatIMG26.jpeg deleted file mode 100644 index 6659766f..00000000 Binary files a/media/sponsor/WechatIMG26.jpeg and /dev/null differ