ThreadLocal与内存泄漏分析

本文转自：[ThreadLocal与内存泄漏] https://zhuanlan.zhihu.com/p/58636499

阅读本文前，需要先了解ThreadLocal的原理。
我们将从下面这些问题开始，寻找ThreadLocal中内存泄漏的罪魁祸首。

一、ThreadLocal，Thread，ThreadLocalMap，Entry<k,v>之间的关系？
先来看看Thread源码

image.png
可以发现，每一个Thread中维护了一个ThreadLocalMap成员变量（也称threadLocals）。
再来看看ThreadLocal中的源码
image.png
不难看出ThreadLocalMap类是ThreadLocal类的静态内部类，而Entry是ThreadLocalMap的静态内部类，key是ThreadLocal（声明为弱引用），value是Object，也就是我们要存的值。

二、ThreadLocal在预防内存泄漏方面，做了哪些努力？
Thread中维护了ThreadLocalMap，所以ThreadLocalMap的生命周期和Thread（当前线程）一样长。使用不当就可能会导致内存泄漏问题。但是，在ThreadLocal中，进行get，set操作的时候会清除Map里所有key为null的value。

三、ThreadLocal的实现原理？

image.png
ThreadLocal自身并不储存值，而是作为一个key来让线程从ThreadLocal获取value。Entry是中的key是弱引用，所以jvm在垃圾回收时如果外部没有强引用来引用它，ThreadLocal必然会被回收。但是，作为ThreadLocalMap的key，ThreadLocal被回收后，ThreadLocalMap就会存在null，但value不为null的Entry。若当前线程一直不结束，可能是作为线程池中的一员，线程结束后不被销毁，或者分配（当前线程又创建了ThreadLocal对象）使用了又不再调用get/set方法，就可能引发内存泄漏。其次，就算线程结束了，操作系统在回收线程或进程的时候不是一定杀死线程或进程的，在繁忙的时候，只会清除线程或进程数据的操作，重复使用线程或进程（线程id可能不变导致内存泄漏）。因此，key弱引用并不是导致内存泄漏的原因，而是因为ThreadLocalMap的生命周期与当前线程一样长，并且没有手动删除对应key。
那么，为什么要将Entry中的key设为弱引用？相反，设置为弱引用的key能预防大多数内存泄漏的情况。如果key 使用强引用，引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。如果key为弱引用，引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

四、如何避免上述弱引用引发的内存泄漏？
在使用完ThreadLocal时，及时调用它的的remove方法清除数据。

总而言之，如果开发者希望将类的某个静态变量与线程状态关联，可以考虑使用ThreadLocal。ThreadLocal的设计本身就是为了能够在当前线程中有属于自己的变量，并不是为了解决并发或者共享变量的问题。