类ThreadLocal的使用：

   变量值的共享可以使用public static变量的形式，所有的线程都使用同一个public static变量。如果想实现每一个线程都有自己的共享变量，那就可以使用ThreadLocal类。

   类ThreadLocal主要解决的就是每个线程绑定自己的值，可以将ThreadLocal类比喻成全局存放数据的盒子，盒子中可以存储每个线程的私有数据。

ThreadLocal详解：

ThreadLocal定义了四个方法：

get()：返回此线程局部变量的当前线程副本中的值。

initialValue()：返回此线程局部变量的当前线程的“初始值”。

remove()：移除此线程局部变量当前线程的值。

set(T value)：将此线程局部变量的当前线程副本中的值设置为指定值。

除了这四个方法，ThreadLocal内部还有一个静态内部类ThreadLocalMap，该内部类才是实现线程隔离机制的关键，get()、set()、remove()都是基于该内部类操作。ThreadLocalMap提供了一种用键值对方式存储每一个线程的变量副本的方法，key为当前ThreadLocal对象，value则是对应线程的变量副本。

对于ThreadLocal需要注意的有两点：

ThreadLocal实例本身是不存储值，它只是提供了一个在当前线程中找到副本值得key。

是ThreadLocal包含在Thread中，而不是Thread包含在ThreadLocal中，有些小伙伴会弄错他们的关系。

set方法：

set方法

上述代码可以看出set（）方法会先当前线程Thread，之后取出它的成员变量ThreadLocalMap，如果ThreadLocalMap存在，那么进行KEY/VALUE设置，KEY就是ThreadLocal。如果ThreadLocalMap没有，那么创建一个。说白了，当前线程中存在一个Map变量，KEY是ThreadLocal，VALUE是你设置的值。

可以看出map.set（this，value）中this指代ThreadLocal，而value就是你设置的值

get方法：

get

这里其实揭示了ThreadLocalMap里面的数据存储结构，从上面的代码来看，ThreadLocalMap中存放的就是Entry，Entry的KEY就是ThreadLocal，VALUE就是值。

private void set(ThreadLocal key, Object value){ 

 ThreadLocal.ThreadLocalMap.Entry[] tab = table;

intlen = tab.length;// 根据 ThreadLocal 的散列值，查找对应元素在数组中的位置

inti = key.threadLocalHashCode & (len-1);// 采用“线性探测法”，寻找合适位置for(ThreadLocal.ThreadLocalMap.Entry e = tab[i]; 

 e !=null; 

 e = tab[i = nextIndex(i, len)]) { 

 ThreadLocal k = e.get();// key 存在，直接覆盖

if(k == key) { e.value = value;return; }// key == null，但是存在值（因为此处的e != null），说明之前的ThreadLocal对象已经被回收了

if(k ==null) {// 用新元素替换陈旧的元素replaceStaleEntry(key, value, i);return;

 } }// ThreadLocal对应的key实例不存在也没有陈旧元素，new 一个tab[i] =newThreadLocal.ThreadLocalMap.Entry(key, value);

intsz = ++size;// cleanSomeSlots 清楚陈旧的Entry（key == null）// 如果没有清理陈旧的 Entry 并且数组中的元素大于了阈值，则进行 rehashif(!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); }

这个set()操作和我们在集合了解的put()方式有点儿不一样，虽然他们都是key-value结构，不同在于他们解决散列冲突的方式不同。集合Map的put()采用的是拉链法，而ThreadLocalMap的set()则是采用开放定址法

除此之外set（）和get（）方法还有一个重要的作用就是清楚key为null的entry。

ThreadLocal的内存泄漏问题：

1.ThreadLocal为什么会存在内存泄漏问题？

再来看一下这个图

示意图

ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。

其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

2.那么使用了弱引用后还会存在？

a>使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏

b>分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏。

3.为什么使用弱引用？

弱引用是对一个对象（称为referent）的引用的持有者。使用弱引用后，可以维持对 referent 的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个 referent 就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。

   下面我们分两种情况讨论：

a>key 使用强引用：引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。

b>key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。

因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏，而不是因为弱引用。