ThreadLocal内存泄漏问题

先来回顾一下ThreadLocal的原理

每个Thread内部维护一个ThreadLocal, 它是一个Map. 也就是说, ThreadLocal本身并不真正存储线程的变量值, 他只是一个工具, 用来维护Thread内部的Map, 帮助存和取. 

ThreadLocal为什么会内存泄漏

ThreadLocal在ThreadLocalMap中是一个弱引用身份被Entry中的key引用的, 因此如果ThreadLocal没有外部强引用来引用它, 那么ThreadLocal会在下次GC时被回收. 这时候就会出现Entry中key已经被回收的情况, 会出现null key的情况, 外部读取ThreadLocalMap中的元素时, 无法通过null key来找到value. 因此如果当线程的声明周期很长, 一直存在, 那么其内部的ThreadLocalMap对象也一直生存下来, 这些null key就存在一条强引用链的关系一直存在 : Thread -> ThreadLocalMap -> Entry -> value, 这条强引用链会导致Entry不会被回收, value也不会被回收, 但Entry中的key却已经被回收的情况, 造成内存泄漏.

但是JVM已经考虑到这样的情况, 并做了一些措施来保证ThreadLocal尽量不会内存泄漏 : 在ThreadLocal的get(), set(), remove()方法调用的时候会清除掉线程ThreadLocalMap中所有Entry中key为null的value, 并将整个Entry设置为null, 利于下次内存回收. 但是仍然不能保证不会发生内存泄漏, 比如使用static的ThreadLocal, 延长了ThreadLocal的生命周期, 可能会导致内存泄漏, 或者分配使用了ThreadLocal又不再调用get(), set(), remove()方法, 那么也会导致内存泄漏

为什么使用弱引用?

从表面看, 发生内存泄漏, 是因为key使用了弱引用类型, 但其实是因为整个Entry的key为null后, 没有主动清除value导致.

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

让我们来看看官方文档 : To help deal with very large and long-lived useages. the hash table entries use WeakReference for keys.(为了处理非常大和生命周期非常长的线程, 哈希表使用弱引用作为key)

现在来分析一下两种情况 : 

• key使用强引用 : 引用的ThreadLocal的对象被回收了, 但是ThreadLocalMap还持有ThreadLocal的强引用, 如果没有手动删除, 导致Entry内存泄漏
• key使用弱引用 : 引用的ThreadLocal的对象被回收了, 由于ThreadLocalMap持有ThreadLocal的弱引用, 即使没有手动删除, ThreadLocal也会被回收, value在下一次ThreadLocalMap调用set, get, remove的时候就会被清除.

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

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

总结: 

如何避免内存泄漏?  -> 每次使用完ThreadLocal, 都调用它的remove()方法, 清除数据.

在使用线程池的情况下, 没有即使清理ThreadLocal, 不仅是内存泄漏的问题, 更严重的是可能导致业务逻辑出现问题, 所以使用ThreadLocal就跟加锁完要解锁一样, 用完就清理.