转载

ThreadLocal尾篇:ThreadLocal内存泄漏到底因为啥

最近看ThreadLocal内存泄漏这块，网上说法很多。呼声最多的是因为弱引用导致的内存泄漏。

ThreadLocal 在 ThreadLocalMap 中是以一个弱引用身份被Entry中的Key引用,当GC发生时， ThreadLocal 会不会被回收？

这里就用到引用的知识点了。在 java的四种引用讲过。当一个对象被强引用指向时(这里指可达)。垃圾回收器不会回收他。

例如

ThreadLocal threadlocal1 = new ThreadLocal();
threadlocal1.set("测试");
复制代码

ThreadLocal 对象此时有两种索引指向的。

threadlocal1
Key（WeakReference(threadlocal1)）

所以GC发生时，堆内ThreadLocal对象不会被回收。

但是当我们把 threadlocal1 =null; 断开强引用时，此时 ThreadLoca l对象只有一个弱引用，那么GC发生时， ThreadLocal 对象被回收了， Entry 变成了一个key为null的 Entry 。也叫脏Entry

特点是：

key为null，value不能被应用程序访问到，因为我们已经没有引用到他的引用了
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value 链存在，当前线程迟迟不结束（ 例如线程池 ），但不能被使用，成了脏数据，造成了内存泄漏。

看上去好像真是软引用造成的内存泄漏。

那换做强引用分析： ThreadLocal 对象被两个强引用指向

当我们断开程序中的强引用 threadlocal1 时。 ThreadLocal 对象仍然被强引用 Entry.key 指向，不会回收，这就造成， ThreadLocal 对象与 value 都成为了脏数据。

对比这两种情况: 不管软引用还是强引用，都可能出现内存泄漏问题，弱引用反而将内存泄漏的程度降低

利用弱引用的 Entry会有key为null这个特征 ，可以识别哪些是不用的数据，进行清理操作，弱引用反而提高了ThreadLocal的安全性。

事实上当调用 ThreadLocal 的 get(),set(),reomve() 方法，都会清除掉线程 ThreadLocalMap 中所有Entry中Key为null的Value，并将整个Entry设置为null，利于下次内存回收。

原文 https://juejin.im/post/5dcb78c06fb9a04a6554f256

正文到此结束

所属分类： Java 编程技术

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。