ThreadLocal与内存泄漏

一，内存泄漏？

　　首先说下结论，ThreadLocal导致内存泄漏？no，内存泄漏是由于使用不当导致的，姿势不对导致的问题多了去了，但这不是ThreadLocal的锅。

　　接着，我们来分析分析ThreadLocal的底层原理。

二，底层代码

　　1，看下Thread和ThreadLocal，ThreadLocalMap之间的关系。

 

 

 

　　　可以发现，每一个Thread中维护了一个ThreadLocalMap成员变量（也称threadLocals）。

　　2，再来看看ThreadLocal中的源码

 

 　　可以看出ThreadLocalMap类是ThreadLocal类的静态内部类，而Entry是ThreadLocalMap的静态内部类，key是ThreadLocal（声明为弱引用），value是Object，也就是我们要存的值。

三，实现原理

　　Thread中维护了ThreadLocalMap，所以ThreadLocalMap的生命周期和Thread（当前线程）一样长。使用不当就可能会导致内存泄漏问题。

 

 　　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的设计本身就是为了能够在当前线程中有属于自己的变量，并不是为了解决并发或者共享变量的问题。