深刻分析 ThreadLocal 内存泄漏问题

ThreadLocal 的做用是提供线程内的局部变量，这种变量在线程的生命周期内起做用，减小同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。可是若是滥用 ThreadLocal，就可能会致使内存泄漏。下面，咱们将围绕三个方面来分析 ThreadLocal 内存泄漏的问题

• ThreadLocal 实现原理
• ThreadLocal为何会内存泄漏
• ThreadLocal 最佳实践

ThreadLocal 实现原理

ThreadLocal的实现是这样的：每一个Thread 维护一个 ThreadLocalMap 映射表，这个映射表的 key 是 ThreadLocal 实例自己，value 是真正须要存储的 Object。

也就是说 ThreadLocal 自己并不存储值，它只是做为一个 key 来让线程从 ThreadLocalMap 获取 value。值得注意的是图中的虚线，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用做为 Key 的，弱引用的对象在 GC 时会被回收。

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。

可是这些被动的预防措施并不能保证不会内存泄漏：

• 使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能致使的内存泄漏（参考ThreadLocal 内存泄露的实例分析）。
• 分配使用了ThreadLocal又再也不调用get(),set(),remove()方法，那么就会致使内存泄漏。

为何使用弱引用

从表面上看内存泄漏的根源在于使用了弱引用。网上的文章大多着重分析ThreadLocal使用了弱引用会致使内存泄漏，可是另外一个问题也一样值得思考：为何使用弱引用而不是强引用？

咱们先来看看官方文档的说法：

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
为了应对很是大和长时间的用途，哈希表使用弱引用的 key。

下面咱们分两种状况讨论：

• key 使用强引用：引用的ThreadLocal的对象被回收了，可是ThreadLocalMap还持有ThreadLocal的强引用，若是没有手动删除，ThreadLocal不会被回收，致使Entry内存泄漏。
• key 使用弱引用：引用的ThreadLocal的对象被回收了，因为ThreadLocalMap持有ThreadLocal的弱引用，即便没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

比较两种状况，咱们能够发现：因为ThreadLocalMap的生命周期跟Thread同样长，若是都没有手动删除对应key，都会致使内存泄漏，可是使用弱引用能够多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。

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

ThreadLocal 最佳实践

综合上面的分析，咱们能够理解ThreadLocal内存泄漏的来龙去脉，那么怎么避免内存泄漏呢？

• 每次使用完ThreadLocal，都调用它的remove()方法，清除数据。

在使用线程池的状况下，没有及时清理ThreadLocal，不只是内存泄漏的问题，更严重的是可能致使业务逻辑出现问题。因此，使用ThreadLocal就跟加锁完要解锁同样，用完就清理。