讲一下ThreadLocal

首先应该知道的前提条件是每个Thread线程都有一个ThreadLocalMap成员变量，

 每个ThreadLocalMap中都有一个Entry数组，

这个Enty的key是ThreadLocal实例的引用，而value是用这个ThrealLocal实例设置的值

比如，threadLocal.get(5)

那么我们在使用ThreadLocal的时候，其实就是将这个实例引用threadLocal作为key，5作为vlaue，

计算引用对应的数组下标，获取对应下标下的Entry，调用entry.get方法，获取当前Entry对应的引用是否是 当前ThrealLocal对象的引用，如果不是，则从当前位置开始继续寻找下一个下标对比直至找到和对象引用一样的Entry，就可以返回对应的value了

 

 

 

set(5)

存储也是，首先从当前线程获取对应的ThreadLocalMap

 然后根据当前对象的引用计算出下标，根据下标获取对应的数组的Entry,匹配 对应的引用是否和当前引用一样，如果一样，则进行覆盖value ，也就是update。

如果一直向下查找找不到直至数组元素是null，则进行新增，在第一个出现的null位置设置新Entry

 size值更新，如果size达到设置阈值，则进行rehash扩容

从而实现线程维度的变量。也就是每个线程单独维护一份数据。

所以它是线程安全的，不涉及到共享问题.

1.内存泄漏问题

我们需要注意到，如果在线程对象持续存在，而某个ThrealLocal实例的引用已经失效的情况下，那么可能存在"短时"的内存泄漏，比如，我们有个线程A实例，在某个时刻我们创建了一个ThreadLocal B 对象，并用该对象为当前线程A设置了值C ，那么此时其实就是在线程A实例中的ThreadLocalMap中有一个key为B，value为C的Entry对象，此时我们结束了这个方法，更直白点说就是ThreadLocal 的B对象的引用已经在方法栈帧中弹栈了，那么ThreadLocal B实例在堆内存中将被回收(因为Entry中的B key是个弱引用)，那么这个Entry的key将会是null，就会造成这个Entry永远都不能被显示的引用到，但是其value依旧指向的C将无法被回收，这就导致了内存泄漏，

虽然他会随着线程实例的结束而结束，虽然在ThreadLocalMap中的put，get方法都会有清楚key为null的Entry的机制，但是都存在的一定的"延时"。尤其是对线程池这种会让线程长久存在的场景更容易引发'长时间"的内存泄漏，所以我们建议养成及时调用ThreadLocal的remove方法以让不用的内存能够被及时的回收

2. 线程不安全问题

如果不同的线程的ThreadLocalMap中的Entry   存放的是同一个key，且value是指向同一个对象的地址，那么就会存在指向同一个对象的线程安全问题了。

比如线程A 在ThreadLocal A对象上设置了Integer 6，线程B在ThreadLocalA对象上也设置了这个Integer 6的引用，那么就会造成其所存放的Entry key为ThreadLocalA 的value都是Integer的引用，指向了同一个Integer对象，在没有锁控制的情况下就会产生线程安全的问题。