Java多线程编程-（9）-ThreadLocal造成OOM内存溢出案例演示与原理分析

怼烎@ 2022-06-07 12:14 96阅读 0赞

前几篇：  
[Java多线程编程-（1）-线程安全和锁Synchronized概念][Java_-_1_-_Synchronized]

[Java多线程编程-（2）-可重入锁以及Synchronized的其他基本特性][Java_-_2_-_Synchronized]

[Java多线程编程-（3）-线程本地ThreadLocal的介绍与使用][Java_-_3_-_ThreadLocal]

[Java多线程编程-（4）-线程间通信机制的介绍与使用][Java_-_4_-]

[Java多线程编程-（5）-使用Lock对象实现同步以及线程间通信][Java_-_5_-_Lock]

[Java多线程编程-（6）-两种常用的线程计数器CountDownLatch和循环屏障CyclicBarrier][Java_-_6_-_CountDownLatch_CyclicBarrier]

[Java多线程编程-（7）-使用线程池实现线程的复用和一些坑的避免][Java_-_7_-]

[Java多线程编程-（8）-多图深入分析ThreadLocal原理][Java_-_8_-_ThreadLocal]

--------------------

## 案例代码 ##

1、首先看一下代码，模拟了一个线程数为500的线程池，所有线程共享一个ThreadLocal变量，每一个线程执行的时候插入一个大的List集合：

import java.util.ArrayList;
    import java.util.List;
    import java.util.concurrent.ExecutorService;
    import java.util.concurrent.Executors;
    
    public class ThreadLocalOOMDemo { 
    
        private static final int THREAD_LOOP_SIZE = 500;
        private static final int MOCK_DIB_DATA_LOOP_SIZE = 10000;
    
        private static ThreadLocal<List<User>> threadLocal = new ThreadLocal<>();
    
        public static void main(String[] args) throws InterruptedException {
    
            ExecutorService executorService = Executors.newFixedThreadPool(THREAD_LOOP_SIZE);
    
            for (int i = 0; i < THREAD_LOOP_SIZE; i++) {
                executorService.execute(() -> {
                    threadLocal.set(new ThreadLocalOOMDemo().addBigList());
                    Thread t = Thread.currentThread();
                    System.out.println(Thread.currentThread().getName());
                    //threadLocal.remove(); //不取消注释的话就可能出现OOM
                });
                try {
                    Thread.sleep(1000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            //executorService.shutdown();
        }
    
        private List<User> addBigList() {
            List<User> params = new ArrayList<>(MOCK_DIB_DATA_LOOP_SIZE);
            for (int i = 0; i < MOCK_DIB_DATA_LOOP_SIZE; i++) {
                params.add(new User("xuliugen", "password" + i, "男", i));
            }
            return params;
        }
    
        class User {
            private String userName;
            private String password;
            private String sex;
            private int age;
    
            public User(String userName, String password, String sex, int age) {
                this.userName = userName;
                this.password = password;
                this.sex = sex;
                this.age = age;
            }
        }
    }

2、设置JVM参数设置最大内存为256M，以便模拟出OOM：

![这里写图片描述][20171020195603236]

3、运行代码，输出结果：

![这里写图片描述][20171020195649643]

可以看出，单线程池执行到第212的时候，就报了错误，出现OOM内存溢出错误。

4、在运行代码的时候，同时打开JDK工具**jconsole** 监控内存变化：

![这里写图片描述][20171020195824605]

可以看出，上述内存一直递增到JVM设置的最大值，然后抛出异常，程序退出。

5、这个实例可以很好的演示了：线程池的一个线程使用完ThreadLocal对象之后，再也不用，由于线程池中的线程不会退出，线程池中的线程的存在，同时ThreadLocal变量也会存在，占用内存！造成OOM溢出！

## ThreadLocal为什么会内存泄漏 ##

在上一篇的时候，已经简单的介绍了不正当的使用ThreadLocal造成OOM的原因，下边详细的介绍一下：

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

Thread、ThreadLocal、ThreadLocalMap、Entry之间的关系：

![这里写图片描述][20171020172529956]

上图中描述了：一个Thread中只有一个ThreadLocalMap，一个ThreadLocalMap中可以有多个ThreadLocal对象，其中一个ThreadLocal对象对应一个ThreadLocalMap中一个的Entry（也就是说：一个Thread可以依附有多个ThreadLocal对象）。

在ThreadLocal的生命周期中，都存在这些引用。看下图: **实线代表强引用，虚线代表弱引用。**

![这里写图片描述][20171020200142500]

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、但是这些被动的预防措施并不能保证不会内存泄漏：

（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中保存的数据大小不是很大！

2、那么我们修改最开始的代码为：

取消注释：threadLocal.remove(); 结果不会出现OOM，可以看出堆内存的变化呈现锯齿状，证明每一次remove()之后，ThreadLocal的内存释放掉了！线程池中的线程的数量持续增加！

import java.util.ArrayList;
    import java.util.List;
    import java.util.concurrent.ExecutorService;
    import java.util.concurrent.Executors;
    
    public class ThreadLocalOOMDemo { 
    
        private static final int THREAD_LOOP_SIZE = 500;
        private static final int MOCK_DIB_DATA_LOOP_SIZE = 10000;
    
        private static ThreadLocal<List<User>> threadLocal = new ThreadLocal<>();
    
        public static void main(String[] args) throws InterruptedException {
    
            ExecutorService executorService = Executors.newFixedThreadPool(THREAD_LOOP_SIZE);
    
            for (int i = 0; i < THREAD_LOOP_SIZE; i++) {
                executorService.execute(() -> {
                    threadLocal.set(new ThreadLocalOOMDemo().addBigList());
                    Thread t = Thread.currentThread();
                    System.out.println(Thread.currentThread().getName());
                    threadLocal.remove(); //模拟每次使用完之后都要调用remove()掉，记住是在当前线程内部调用
                });
                try {
                    Thread.sleep(1000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            executorService.shutdown();
        }
    
        private List<User> addBigList() {
            List<User> params = new ArrayList<>(MOCK_DIB_DATA_LOOP_SIZE);
            for (int i = 0; i < MOCK_DIB_DATA_LOOP_SIZE; i++) {
                params.add(new User("xuliugen", "password" + i, "男", i));
            }
            return params;
        }
    
        class User {
            private String userName;
            private String password;
            private String sex;
            private int age;
    
            public User(String userName, String password, String sex, int age) {
                this.userName = userName;
                this.password = password;
                this.sex = sex;
                this.age = age;
            }
        }
    }

取消注释：`threadLocal.remove();` 结果不会出现OOM，可以看出堆内存的变化呈现锯齿状，证明每一次remove()之后，ThreadLocal的内存释放掉了！线程池中的线程的数量持续增加！

![这里写图片描述][20171020203455543]

![这里写图片描述][20171020203514504]

--------------------

参考文章：

1、[http://www.importnew.com/22039.html][http_www.importnew.com_22039.html]

--------------------

**关注公众号，及时获取内容更新！**

![这里写图片描述][SouthEast]

[Java_-_1_-_Synchronized]: http://blog.csdn.net/xlgen157387/article/details/77920497
[Java_-_2_-_Synchronized]: http://blog.csdn.net/xlgen157387/article/details/78005352
[Java_-_3_-_ThreadLocal]: http://blog.csdn.net/xlgen157387/article/details/78114278
[Java_-_4_-]: http://blog.csdn.net/xlgen157387/article/details/78195817
[Java_-_5_-_Lock]: http://blog.csdn.net/xlgen157387/article/details/78197583
[Java_-_6_-_CountDownLatch_CyclicBarrier]: http://blog.csdn.net/xlgen157387/article/details/78218736
[Java_-_7_-]: http://blog.csdn.net/xlgen157387/article/details/78253096
[Java_-_8_-_ThreadLocal]: http://blog.csdn.net/xlgen157387/article/details/78297568
[20171020195603236]: /images/20220607/e86dcbcf365f4363be0be466e5b28ce1.png
[20171020195649643]: /images/20220607/17f766ea6c3248e191714c7c91e90d8a.png
[20171020195824605]: /images/20220607/0d4d37e7952248b9adafa9d3cef1fa92.png
[20171020172529956]: /images/20220607/1b34f996aa6f4c8ab51979127464e4d1.png
[20171020200142500]: /images/20220607/c3ae3219cc3f4c5dbdb9c0bfd20a8d7c.png
[20171020203455543]: /images/20220607/1e52905129ae4c4fb2a8e5d4b6a0c263.png
[20171020203514504]: /images/20220607/abab7d2d75d149cda26017bd6de97150.png
[http_www.importnew.com_22039.html]: http://www.importnew.com/22039.html
[SouthEast]: /images/20220607/ed6b7a8b197c4ae7910b6a92a39d81ff.png