如何探究ThreadLocal内存泄漏的原因

本篇文章给大家分享的是有关如何探究ThreadLocal内存泄漏的原因，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

1、首先看下ThreadLocal的原理图：

在ThreadLocal的生命周期中，都存在这些引用。

其中，实线代表强引用，虚线代表弱引用；

2、ThreadLocal的实现：每个Thread维护一个ThreadLocalMap映射表，这个映射表的key是ThreadLocal实例本身，value是真正需要存储的Object;

3、也就是说ThreadLocal本身不存储值，它只是作为一个key来让线程从ThreadLocalMap获取value，值得注意的是图中的虚线，表示ThreadLocalMap是使用ThreadLocal的弱引用作为key，其在GC时会被回收；

4、ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。

5、总的来说就是，ThreadLocal里面使用了一个存在弱引用的map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例。这个Map的确使用了弱引用，不过弱引用只是针对key。每个key都弱引用指向threadlocal。当把threadlocal实例置为null以后，没有任何强引用指向threadlocal实例，所以threadlocal将会被gc回收。

但是，我们的value却不能回收，而这块value永远不会被访问到了，所以存在着内存泄露。因为存在一条从current thread连接过来的强引用。只有当前thread结束以后，current thread就不会存在栈中，强引用断开，Current Thread、Map value将全部被GC回收。最好的做法是将调用threadlocal的remove方法，这也是等会后边要说的。

6、其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。这一点在上一节中也讲到过！

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

a、使用static的ThreadLocal，延长ThreadLocal的生命周期，可能导致内存泄漏；

b、分配只用了ThreadLocal又不再调用get()、set()、remove()方法，那么可能导致内存泄漏，因为这块内存会一直存在；

以下是源码：

/**
 * The entries in this hash map extend WeakReference, using
 * its main ref field as the key (which is always a
 * ThreadLocal object). Note that null keys (i.e. entry.get()
 * == null) mean that the key is no longer referenced, so the
 * entry can be expunged from table. Such entries are referred to
 * as "stale entries" in the code that follows.
 */
static class Entry extends WeakReference> {
     /** The value associated with this ThreadLocal. */
     Object value;
     Entry(ThreadLocal k, Object v) {
     super(k);
     value = v;
     }
}

以上就是如何探究ThreadLocal内存泄漏的原因，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注行业资讯频道。