add 万字图文深度解析ThreadLocal

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)
+4. [万字图文深度解析ThreadLocal](docs/java/Multithread/ThreadLocal.md)
-5. [AQS 原理以及 AQS 同步组件总结](docs/java/Multithread/AQS.md)
+5. [JUC 中的 Atomic 原子类总结](docs/java/Multithread/Atomic.md)
+6. [AQS 原理以及 AQS 同步组件总结](docs/java/Multithread/AQS.md)
 
 ### JVM
 

docs/java/Multithread/ThreadLocal2.md

@@ -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`的**点点滴滴**。
-
-### 目录
-
-<!-- TOC -->
-
-- [前言](#前言)
-- [目录](#目录)
-- [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发送消息给第三方系统)
-
-<!-- /TOC -->
-
-
-**注明：** 本文源码基于`JDK 1.8`
-
-### ThreadLocal代码演示
-
-我们先看下`ThreadLocal`使用示例：
-
-```java
-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();
-    }
-}
-```
-
-打印结果：
-
-```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<? 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();
-        }
-    }
-}
-```
-
-结果如下：
-```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<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` **分布非常均匀**。
-
-我们自己可以尝试下：
-
-![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<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();
-    }
-}
-```
-
-打印结果：
-
-```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<String, String> context = MDC.getCopyOfContextMap();
-        super.execute(() -> run(runnable, context));
-    }
-
-    @Override
-    private void run(Runnable runnable, Map<String, String> context) {
-        if (context != null) {
-            MDC.setContextMap(context);
-        }
-        try {
-            runnable.run();
-        } finally {
-            MDC.remove();
-        }
-    }
-}
-```
-
-#### 使用MQ发送消息给第三方系统
-
-在MQ发送的消息体中自定义属性`requestId`，接收方消费消息后，自己解析`requestId`使用即可。
-
-[1]:https://juejin.im/post/5eacc1c75188256d976df748
-
-
-

docs/java/Multithread/ThreadLocal（未完成）.md

@@ -0,0 +1,170 @@
+[ThreadLocal造成OOM内存溢出案例演示与原理分析](https://blog.csdn.net/xlgen157387/article/details/78298840)
+
+[深入理解 Java 之 ThreadLocal 工作原理](<https://allenwu.itscoder.com/threadlocal-source>)
+
+## 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<SimpleDateFormat> 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<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
+        @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<ThreadLocal<?>> {
+            /** The value associated with this ThreadLocal. */
+            Object value;
+
+            Entry(ThreadLocal<?> k, Object v) {
+                super(k);
+                value = v;
+            }
+        }
+```
+
+**弱引用介绍：**
+
+> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
+>
+> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。