ThreadLocal内存泄露原因分析

你的名字 2023-02-21 12:29 12阅读 0赞

# 欢迎关注本人公众号 #

![在这里插入图片描述][20200515113638671.jpg_pic_center]

# 线程本地变量相关的博客目录 #

*  [ThreadLocal内存泄露原因分析][ThreadLocal]
 *  [ThreadLocal 内存泄漏 代码演示 实例演示][ThreadLocal _ _]
 *  [InheritableThreadLocal：子线程继承父线程的本地变量][InheritableThreadLocal]
 *  [当InheritableThreadLocal遇到线程池：主线程本地变量修改后，子线程无法读取到新值][InheritableThreadLocal 1]
 *  [transmittable-thread-local:解决线程池之间ThreadLocal本地变量传递的问题][transmittable-thread-local_ThreadLocal]

# 背景知识 #

## 引用 ##

Object o = new Object();

这个o，我们可以称之为对象引用，而new Object()我们可以称之为在内存中产生了一个对象实例。

当写下 o=null时，只是表示o不再指向堆中object的对象实例，不代表这个对象实例不存在了。

## 强引用 ##

一直活着：类似“Object obj=new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象实例。

## 软引用 ##

有一次活的机会：软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象实例列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。

## 弱引用 ##

回收就会死亡：被弱引用关联的对象实例只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象实例。在JDK 1.2之后，提供了WeakReference类来实现弱引用。

## 虚引用 ##

也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象实例是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象实例被收集器回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。

# ThreadLocal的基本原理 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70]  
上图中的Map是`ThreadLocalMap`。  
ThreadLocalMap关键属性：

static class ThreadLocalMap { 
    
            /** * 这里entry继承了WeakReference<ThreadLocal<?>>。 * entry也是Key-Value的数据格式。key是ThreadLocal对象的弱引用。value是实际存储的值 */
            static class Entry extends WeakReference<ThreadLocal<?>> { 
                /** The value associated with this ThreadLocal. */
                Object value;
    
                Entry(ThreadLocal<?> k, Object v) { 
                    super(k);
                    value = v;
                }
            }
    
            /** * The initial capacity -- MUST be a power of two. */
            private static final int INITIAL_CAPACITY = 16;
    
            /** * 可能会有多个threadlocal对象，存储在table数组中。 * */
            private Entry[] table;
    
            /** * The number of entries in the table. */
            private int size = 0;
    
            /** * The next size value at which to resize. */
            private int threshold; // Default to 0
    }

ThreadLocalMap 实际存储在Thread对象中。  
每个Thread 维护一个 ThreadLocalMap 映射表，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object。

public class Thread implements Runnable { 
    
    	ThreadLocal.ThreadLocalMap threadLocals = null;
    
    }

通过set方法，来简单看一下存储数据的过程。

public void set(T value) { 
            Thread t = Thread.currentThread();
            ThreadLocalMap map = getMap(t);
            if (map != null) { 
                map.set(this, value);
            } else { 
                createMap(t, value);
            }
        }
    
    ThreadLocalMap getMap(Thread t) { 
            return t.threadLocals;//这个threadLocals是Thread对象中的属性
        }

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

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

总的来说就是，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方法，这也是等会后边要说的。

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

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

（1）使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致内存泄漏。
    （2）分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏，因为这块内存一直存在。

# 为什么使用弱引用，OOM是否是弱引用的锅？ #

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

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

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

下面我们分两种情况讨论：

（1）key 使用强引用：引用ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。

（2）key 使用弱引用：引用ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set、get、remove的时候会被清除。

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

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

# ThreadLocal 最佳实践 #

1、综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？

答案就是：`每次使用完ThreadLocal，都调用它的remove()方法，清除数据。`

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

注意：

并不是所有使用ThreadLocal的地方，都在最后remove（），他们的生命周期可能是需要和项目的生存周期一样长的，所以要进行恰当的选择，以免出现业务逻辑错误！但首先应该保证的是ThreadLocal中保存的数据大小不是很大！

[20200515113638671.jpg_pic_center]: https://img-blog.csdnimg.cn/20200515113638671.jpg#pic_center
[ThreadLocal]: https://blog.csdn.net/liubenlong007/article/details/107046897
[ThreadLocal _ _]: https://blog.csdn.net/liubenlong007/article/details/107048843
[InheritableThreadLocal]: https://blog.csdn.net/liubenlong007/article/details/107049375
[InheritableThreadLocal 1]: https://blog.csdn.net/liubenlong007/article/details/107049975
[transmittable-thread-local_ThreadLocal]: https://editor.csdn.net/md/?articleId=107050929
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020063017304679.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp,size_16,color_FFFFFF,t_70