ThreadLocal的弱引用以及可能引起的内存泄漏

冷不防 2024-05-01 16:01 167阅读 0赞

ThreadLocal：线程本地副本，可在多线程环境下，为每个线程创建独立的副本保证线程安全

ThreadLocal总会有一些疑惑的地方：

1.  听说ThreadLocal中有有使用弱引用，为什么要用弱引用？用弱引用，发生一次gc后，set进去的值再get就是null了吗？
2.  听说ThreadLocal可能引起内存泄露？啥场景会内存泄露？为何使用了弱引用依然可能发生内存泄露？怎么避免？

解释这两个问题之前先看一下什么是弱引用

Java中的弱引用具体指的是java.lang.ref.WeakReference<T>类，官方文档说明是

> 弱引用对象的存在不会阻止它所指向的对象被垃圾回收器回收。弱引用最常见的用途是实现规范映射(canonicalizing mappings，比如哈希表）。假设垃圾收集器在某个时间点决定一个对象是弱可达的(weakly reachable)（也就是说当前指向它的全都是弱引用），这时垃圾收集器会清除所有指向该对象的弱引用，然后把这个弱可达对象标记为可终结(finalizable)的，这样它随后就会被回收。与此同时或稍后，垃圾收集器会把那些刚清除的弱引用放入创建弱引用对象时所指定的引用队列(Reference Queue)中。

首先先来一段代码，看下最基本的使用

>     public class TestThreadLocal {
>     
>         final static ThreadLocal<String> LOCAL = new ThreadLocal();
>     
>         public static void main(String[] args) throws InterruptedException {
>             ExecutorService executorService = Executors.newFixedThreadPool(3);
>             // 线程1
>             executorService.execute(() -> {
>                 // 存值
>                 LOCAL.set(Thread.currentThread().getName());
>                 // 获取值
>                 System.out.println(Thread.currentThread().getName() + "-->" +LOCAL.get());
>             });
>             // 线程2
>             executorService.execute(() -> {
>                 LOCAL.set(Thread.currentThread().getName());
>                 System.out.println(Thread.currentThread().getName() + "-->" +LOCAL.get());
>             });
>             executorService.shutdown();
>         }
>     }

运行结果

pool-1-thread-1-->pool-1-thread-1
    pool-1-thread-2-->pool-1-thread-2

结果没有什么悬念，现在我们就点源码，看下它内部是怎么存储和获取数据的（源码基于jdk1.8，不同版本的jdk实现方式可能稍有不同）

首先看下ThreadLocal的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);
>         }

获取当前线程，然后调用getMap()，返回的是线程下的ThreadLocalMap，ThreadLocalMap对象是Thread类中的成员变量，存放线程独享的一些数据，简单看一些ThreadLocalMap的实现

>     static class ThreadLocalMap {
>             static class Entry extends WeakReference<ThreadLocal<?>> {
>                 /** The value associated with this ThreadLocal. */
>                 Object value;
>     
>                 Entry(ThreadLocal<?> k, Object v) {
>                     super(k);
>                     value = v;
>                 }
>             }
>         ...
>     }

ThreadLocalMap是ThreadLocal类中独立声明的一个内部类，虽然它的名字叫Map，但并没有实现Map接口，而是自己单独实现的。同大多数的Map的实现类似，其内部也是维护了一个Entry存储数据，Entry里有key和value，其中的value维护在Entry里，但是key却并没有直接在Entry里声明，看一看这个Entry，继承WeakReference，泛型是ThreadLocal，是一个弱引用，继续点进去WeakReference，WeakReference集成Reference，再点到Reference里，发现一成员变量

我们再回到ThreadLocal的set()方法中，ThreadLocal的set，第四行上，实际上调用的是ThreadLocalMap的set()，点进去，继续看map.set(this, value)的逻辑。

> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70][]

这就是个简易版的Map的put存放数据的方法，相信大家都知道HashMap的实现，对此应该很清楚，存值的时候，没有当前key，直接新增，有当前key，替换掉其value。但说明一点，与HashMap这种哈希链表存储不同的是，在寻址冲突时，ThreadLocalMap并没有使用链表或红黑树等方式链地址来解决，而是当前地址不可用，就在当前map的数据数组中继续查找下一个可用的地址，有兴趣的可以看下replaceStaleEntry(key, value, i)的具体实现，我们中的看一下新增key的逻辑，也就是tab\[i\] = new Entry(key, value);  
点进去之后，又到了ThreadLocalMap的内部类Entry的构造方法中

> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70 1][]

构造方法第一行，也就是把key存放于Reference的成员变量中了；  
兜了一圈，一句话总结这个ThreadLocal的set(T value)，就是**在当前线程的ThreadLocalMap里存放了数据，key是使用弱引用的ThreadLocal，value就是我们set进去的value**

ThreadLocal的获取值等其他方法就不做过多分析了，下面重点分析下开始时抛出的问题一：关于弱引用的问题。  
弱引用，在经历一次gc后，不管当前内存是否足够，都会被清除，我们把开始的代码修改一下，看会不会被清除。为了确认到底有没有发生gc，在启动时我们加入参数  
`-XX:+PrintGCDetails`

> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70 2][]

结果如下

> ![20191213165605942.png][]

可见ThreadLocal的使用没有受到gc的影响，原因何在？  
我们先分析一下里面的引用链，其中实现为强引用，虚线为弱引用

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODYyODgy_size_16_color_FFFFFF_t_70][]

可见，现在的ThreadLocal，是有两条引用链的，一条是当前线程中的，另一条则是当前执行的测试类的成员变量，且为强引用，所以并不会收到gc影响。

那么我们为什么要用弱引用呢？正是因为 只有弱引用指向的对象会被GC，可以充分利用内存空间，防止内存泄漏

然而，对于ThreadLocal，当线程池与其搭配使用时，使用不当仍会产生内存泄漏，我们来看一下代码

我们再来看下问题二，内存泄露的问题，还是来段代码跑跑再说，这段代码，主要做的就是，开100个线程，每个线程都向ThreadLocal存入1M的对象，为了尽快实验出效果，我们把最大堆内存调小点  
`-Xmx50m -XX:+PrintGCDetails`

>     public class TestThreadLocalLeak
>     {
>        static ThreadLocal local = new ThreadLocal();
>        final static ThreadLocal<byte[]> byteLocal = new ThreadLocal();
>        final static int _1M = 1024 * 1024;
>     
>        public static void main(String[] args)
>        {
>           testUseThread();
>           //    testUseThreadPool();
>        }
>     
>        /**
>         * 使用线程
>         */
>        private static void testUseThread()
>        {
>           for (int i = 0; i < 100; i++)
>           {
>              new Thread(() -> byteLocal.set(new byte[_1M])).start();
>           }
>        }
>     
>        /**
>         * 使用线程池
>         */
>        private static void testUseThreadPool()
>        {
>           ExecutorService executorService = Executors.newFixedThreadPool(100);
>           for (int i = 0; i < 100; i++)
>           {
>              executorService.execute(() -> byteLocal.set(new byte[_1M]));
>           }
>           executorService.shutdown();
>        }
>     
>     }

使用线程打印结果（部分日志）

> ![20191213170530121.png][]

使用线程池打印结果（部分日志）

![2019121317195733.png][]

当调用testUseThread()时，系统随执行了大量YGC，内存始终稳定回收，最后正常执行，但是执行testUseThreadPool()时，经历的频繁的Full GC，内存却没有降下去，最终发生了OOM，原因就在于，使用Thread的时候，当线程执行完毕时，随着线程的终止，该线程下的ThreadLocalMap此时是GC Root不可达的，同理，下面的Entry、里面的key、value都会在下一次gc时被回收，而使用线程池后，由于线程使用后，不会被回收，自然ThreadLocalMap不会被回收引起内存泄露直至OOM。至于怎么避免出现内存泄露，大家基本上也都知道，就是在使用完后，及时调用ThreadLocal的remove()即可，这个方法会把ThreadLocalMap中的相关key和value分别置为null，就能在下次GC时回收了。

最后看一下弱引用的现象：

>     static ThreadLocal local = new ThreadLocal();
>     
>        public static void main(String[] args) {
>           testWeakReference
>        }
> 
>     private static void testWeakReference(){
>        local.set("测试ThreadLocalMap弱引用自动回收");
>        Thread thread = Thread.currentThread();
>        local = null;
>        System.gc();
>        System.out.println("");
>     }

在gc前和gc后打断点，之前我们分析了，之所以ThreadLocal的数据不会被回收，是因为有两个引用链指向ThreadLocal，一个是当前线程的ThreadLocalMap，另一条就是当前类中的成员变量LOCAL，所以我们手动把LOCAL置为null，再次调用System.gc()，看一下弱引用是不是被回收了  
System.gc()前

参考资料：[https://www.jianshu.com/p/94de80aee1bf][https_www.jianshu.com_p_94de80aee1bf]

[https://blog.csdn.net/qq\_42862882/article/details/89820017][https_blog.csdn.net_qq_42862882_article_details_89820017]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/aa7c8ae94f8749c981019715e00374aa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/8e797140c5ab411e953b3f91c03b6c0b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZW4xMjI5_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/eb2ec8c7ec574949a8da47b48a05a85e.png
[20191213165605942.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/0a5629c59d62469ea4c93080fb87637d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyODYyODgy_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/4e1e8ccd4cbd422c815cace1c35d5673.jpg
[20191213170530121.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/63fbacc7c6ed44ccb4589a7cd7104af7.png
[2019121317195733.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/a427067268aa45d98749a80503edb330.png
[https_www.jianshu.com_p_94de80aee1bf]: https://www.jianshu.com/p/94de80aee1bf
[https_blog.csdn.net_qq_42862882_article_details_89820017]: https://blog.csdn.net/qq_42862882/article/details/89820017