java中ThreadLocal的基本原理

基本流程

ThreadLoalMap数据结构

ThreadLoalMap是ThreadLocal中的一个静态内部类，类似HashMap的数据结构，但并没有实现Map接口。

				?

									static class ThreadLocalMap {

									    static class Entry extends WeakReference<ThreadLocal<?>> {

									        /** The value associated with this ThreadLocal. */

									        Object value;

									        Entry(ThreadLocal<?> k, Object v) {

									            super(k);

									            value = v;

									        }

									    }

									    private static final int INITIAL_CAPACITY = 16;

									    // ...

									}

ThreadLoalMap中初始化了一个大小16的Entry数组，Entry对象用来保存每一个key-value键值对。通过上面的set方法，我们已经知道其中的key永远都是ThreadLocal对象。

java中ThreadLocal的基本原理

Hash冲突及解决

Entry在table中存储位置是通过hashcode算法获得。
在向ThreadLocalMap中的Entry数值存储Entry对象时，会根据ThreadLocal对象的hash值，定位到table中的位置i。分三种情况：

如果当前位置为空的，直接将Entry存放在对应位置；
如果位置i已经有值且这个Entry对象的key正好是即将设置的key，那么重新设置Entry中的value；
如果位置i的Entry对象和即将设置的key没关系，则寻找一个空位置；

计算hash值便会有hash冲突出现，常见的解决方法有：再哈希法、开放地址法、建立公共溢出区、链式地址法等。

上面的流程可以看出这里采用的是开放地址方法，如果当前位置有值，就继续寻找下一个位置，注意table[len-1]的下一个位置是table[0]，就像是一个环形数组，所以也叫闭散列法。如果一直都找不到空位置就会出现死循环，发生内存溢出。当然有扩容机制，一般不会找不到空位置的。

ThreadLocal内存泄露

内存引用链路

根据前面对ThreadLocal的分析，得知每个Thread维护一个ThreadLocalMap，它key是ThreadLocal实例本身，value是业务需要存储的Object。也就是说ThreadLocal本身并不存储值，它只是作为一个key来让线程从ThreadLocalMap获取value。

ThreadLocalMap是使用ThreadLocal的弱引用作为Key的，弱引用的对象在GC时会被回收。因此使用了ThreadLocal后，引用链如图所示：(其中虚线表示弱引用。)

java中ThreadLocal的基本原理

引用类型

强引用：java默认的引用类型，例如 Object a = new Object();其中 a 为强引用，new Object()为一个具体的对象。一个对象从根路径能找到强引用指向它，jvm虚拟机就不会回收。

软引用(SoftReference)：进行年轻代的垃圾回收不会触发SoftReference所指向对象的回收；但如果触发Full GC，那SoftReference所指向的对象将被回收。备注：是除了软引用之外没有其他强引用引用的情况下。

弱引用(WeakReference) ：如果对象除了有弱引用指向它后没有其他强引用关联它，当进行年轻代垃圾回收时，该引用指向的对象就会被垃圾回收器回收。

虚引用(PhantomeReference) ：该引用指向的对象，无法对垃圾收集器收集对象时产生任何影响，但在执行垃圾回收后垃圾收集器会通过注册在PhantomeReference上的队列来通知应用程序对象被回收。

为什么使用弱引用而不是强引用?

问题1：从表面上看内存泄漏的根源在于使用了弱引用，但为什么JDK采用了弱引用的实现而不是强引用呢？

答案是：弱引用反而是为了解决内存存储问题而专门使用的。

问题2：如果应用程序觉得ThreadLocal对象的使命完成，将threadLocal ref 设置为null，如果Entry中引用ThreadLocald对象的引用类型设置为强引用的话，会发生什么问题？

答案是：ThreadLocal对象会无法被垃圾回收器回收，因为从thread对象出发，有强引用指向ThreadLocal的object。此时会违背用户的初衷，造成所谓的内存泄露。

我们先来假设一下，如果key使用强引用，那么在其他持有ThreadLocal引用的对象都回收了，但ThreadLocalMap依旧持有ThreadLocal的强引用，这就导致ThreadLocal不会被回收，从而导致Entry内存泄露。

对照一下，弱引用的情况。持有ThreadLocal引用的对象都回收了，ThreadLocalMap持有的是ThreadLocal的弱引用，会被自动回收。只不过对应的value值，需要在下次调用set/get/remove方法时会被清除。

泄露原因分析

当Thread执行完会被销毁，Thread.threadLocals指向的ThreadLocalMap实例也随之变为垃圾，它里面存放的Entity也会被回收。这种情况是不会发生内存泄漏的。

发生内存泄露的场景一般存在于线程池的情况下。 此时，Thread生命周期比较长（存在循环使用），threadLocals引用一直存在，当其存放的ThreadLocal被回收（弱引用生命周期比较短）后，对应的Entity就成了key为null的实例，但value值不会被回收。 如果此Entity一直不被get()、set()、remove()，就一直不会被回收，也就发生了内存泄漏。

所以，通常在使用完ThreadLocal后需要调用remove()方法进行内存的清除。

接下来我们再延伸一下，想再来谈谈网络上关于ThreadLocalMap中存储大量Entry对象导致的内存“泄露”问题？

网络观点：在使用ThreadLocal中set方法与remove方法需要成对执行，需要没有执行remove方法会造成内存泄露？甚至造成内存溢出？

我的观点：当然能成对使用当然更好，但在实际情况中，其实不调用remove方法也不太容易造成内存溢出，因为从存储结构来看，除非创建海量线程，并且这些线程都不释放，导致大量线程内部持有的ThreadLocalMap中对象一直不会释放，但一个线程所持有的Entry对象个数不多，取决于关联的ThreadLocal对象个数，故我们需要的关注点而不是remove方法，而是防止线程资源泄露。