ThreadLocal中的3个大坑，内存泄露都是小儿科！

小鱼儿 2023-10-04 12:51 6阅读 0赞

我在参加Code Review的时候不止一次听到有同学说：我写的这个上下文工具没问题，在线上跑了好久了。其实这种想法是有问题的，`ThreadLocal`写错难，但是用错就很容易，本文将会详细总结`ThreadLocal`容易用错的三个坑：

1.  **内存泄露**
2.  **线程池中线程上下文丢失**
3.  **并行流中线程上下文丢失**

### 内存泄露 ###

由于`ThreadLocal`的`key`是弱引用，因此如果使用后不调用`remove`清理的话会导致对应的`value`内存泄露。

@Test
    public void testThreadLocalMemoryLeaks() {
        ThreadLocal<List<Integer>> localCache = new ThreadLocal<>();
       List<Integer> cacheInstance = new ArrayList<>(10000);
        localCache.set(cacheInstance);
        localCache = new ThreadLocal<>();
    }

当`localCache`的值被重置之后`cacheInstance`被`ThreadLocalMap`中的`value`引用，无法被GC，但是其`key`对`ThreadLocal`实例的引用是一个弱引用，本来`ThreadLocal`的实例被`localCache`和`ThreadLocalMap`的`key`同时引用，但是当`localCache`的引用被重置之后，则`ThreadLocal`的实例只有`ThreadLocalMap`的`key`这样一个弱引用了，此时这个实例在GC的时候能够被清理。

![d5713ee50d128d72cb4f04ba1862b94c.png][]

其实看过`ThreadLocal`源码的同学会知道，`ThreadLocal`本身对于`key`为`null`的`Entity`有自清理的过程，但是这个过程是依赖于后续对`ThreadLocal`的继续使用，假如上面的这段代码是处于一个秒杀场景下，会有一个瞬间的流量峰值，这个流量峰值也会将集群的内存打到高位(或者运气不好的话直接将集群内存打满导致故障)，后面由于峰值流量已过，对`ThreadLocal`的调用也下降，会使得`ThreadLocal`的自清理能力下降，造成内存泄露。`ThreadLocal`的自清理是锦上添花，千万不要指望他雪中送碳。

相比于`ThreadLocal`中存储的`value`对象泄露，`ThreadLocal`用在`web`容器中时更需要注意其引起的`ClassLoader`泄露。

`Tomcat`官网对在`web`容器中使用`ThreadLocal`引起的内存泄露做了一个总结，详见：https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection，这里我们列举其中的一个例子。

熟悉`Tomcat`的同学知道，Tomcat中的web应用由`Webapp Classloader`这个类加载器的，并且`Webapp Classloader`是破坏双亲委派机制实现的，即所有的`web`应用先由`Webapp classloader`加载，这样的好处就是可以让同一个容器中的`web`应用以及依赖隔离。

下面我们看具体的内存泄露的例子：

public class MyCounter {
     private int count = 0;
    
     public void increment() {
      count++;
     }
    
     public int getCount() {
      return count;
     }
    }
    
    public class MyThreadLocal extends ThreadLocal<MyCounter> {
    }
    
    public class LeakingServlet extends HttpServlet {
     private static MyThreadLocal myThreadLocal = new MyThreadLocal();
    
     protected void doGet(HttpServletRequest request,
       HttpServletResponse response) throws ServletException, IOException {
    
      MyCounter counter = myThreadLocal.get();
      if (counter == null) {
       counter = new MyCounter();
       myThreadLocal.set(counter);
      }
    
      response.getWriter().println(
        "The current thread served this servlet " + counter.getCount()
          + " times");
      counter.increment();
     }
    }

需要注意这个例子中的两个非常关键的点：

*  `MyCounter`以及`MyThreadLocal`必须放到`web`应用的路径中，保被`Webapp Classloader`加载
 *  `ThreadLocal`类一定得是`ThreadLocal`的继承类，比如例子中的`MyThreadLocal`，因为`ThreadLocal`本来被`Common Classloader`加载，其生命周期与`Tomcat`容器一致。`ThreadLocal`的继承类包括比较常见的`NamedThreadLocal`，注意不要踩坑。

假如`LeakingServlet`所在的`Web`应用启动，`MyThreadLocal`类也会被`Webapp Classloader`加载，如果此时web应用下线，而线程的生命周期未结束(比如为`LeakingServlet`提供服务的线程是一个线程池中的线程)，那会导致`myThreadLocal`的实例仍然被这个线程引用，而不能被GC，期初看来这个带来的问题也不大，因为`myThreadLocal`所引用的对象占用的内存空间不太多，问题在于`myThreadLocal`间接持有加载web应用的`webapp classloader`的引用（通过`myThreadLocal.getClass().getClassLoader()`可以引用到），而加载web应用的`webapp classloader`有持有它加载的所有类的引用，这就引起了`Classloader`泄露，它泄露的内存就非常可观了。

### 线程池中线程上下文丢失 ###

`ThreadLocal`不能在父子线程中传递，因此最常见的做法是把父线程中的`ThreadLocal`值拷贝到子线程中，因此大家会经常看到类似下面的这段代码：

for(value in valueList){
         Future<?> taskResult = threadPool.submit(new BizTask(ContextHolder.get()));//提交任务，并设置拷贝Context到子线程
         results.add(taskResult);
    }
    for(result in results){
        result.get();//阻塞等待任务执行完成
    }

提交的任务定义长这样：

class BizTask<T> implements Callable<T>  {
        private String session = null;
        
        public BizTask(String session) {
            this.session = session;
        }
        
        @Override
        public T call(){
            try {
                ContextHolder.set(this.session);
                // 执行业务逻辑
            } catch(Exception e){
                //log error
            } finally {
                ContextHolder.remove(); // 清理 ThreadLocal 的上下文，避免线程复用时context互串
            }
            return null;
        }
    }

对应的线程上下文管理类为：

class ContextHolder {
        private static ThreadLocal<String> localThreadCache = new ThreadLocal<>();
        
        public static void set(String cacheValue) {
            localThreadCache.set(cacheValue);
        }
        
        public static String get() {
            return localThreadCache.get();
        }
        
        public static void remove() {
            localThreadCache.remove();
        }
        
    }

这么写倒也没有问题，我们再看看线程池的设置：

ThreadPoolExecutor executorPool = new ThreadPoolExecutor(20, 40, 30, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(40), new XXXThreadFactory(), ThreadPoolExecutor.CallerRunsPolicy);

其中最后一个参数控制着当线程池满时，该如何处理提交的任务，内置有4种策略

ThreadPoolExecutor.AbortPolicy //直接抛出异常
    ThreadPoolExecutor.DiscardPolicy //丢弃当前任务
    ThreadPoolExecutor.DiscardOldestPolicy //丢弃工作队列头部的任务
    ThreadPoolExecutor.CallerRunsPolicy //转串行执行

可以看到，我们初始化线程池的时候指定如果线程池满，则新提交的任务转为串行执行，那我们之前的写法就会有问题了，串行执行的时候调用`ContextHolder.remove();`会将主线程的上下文也清理，即使后面线程池继续并行工作，传给子线程的上下文也已经是`null`了，而且这样的问题很难在预发测试的时候发现。

### 并行流中线程上下文丢失 ###

如果`ThreadLocal`碰到并行流，也会有很多有意思的事情发生，比如有下面的代码：

class ParallelProcessor<T> {
        
        public void process(List<T> dataList) {
            // 先校验参数，篇幅限制先省略不写
            dataList.parallelStream().forEach(entry -> {
                doIt();
            });
        }
        
        private void doIt() {
            String session = ContextHolder.get();
            // do something
        }
    }

这段代码很容易在线下测试的过程中发现不能按照预期工作，因为并行流底层的实现也是一个`ForkJoin`线程池，既然是线程池，那`ContextHolder.get()`可能取出来的就是一个`null`。我们顺着这个思路把代码再改一下：

class ParallelProcessor<T> {
        
        private String session;
        
        public ParallelProcessor(String session) {
            this.session = session;
        }
        
        public void process(List<T> dataList) {
            // 先校验参数，篇幅限制先省略不写
            dataList.parallelStream().forEach(entry -> {
                try {
                    ContextHolder.set(session);
                    // 业务处理
                    doIt();
                } catch (Exception e) {
                    // log it
                } finally {
                    ContextHolder.remove();
                }
            });
        }
        
        private void doIt() {
            String session = ContextHolder.get();
            // do something
        }
    }

修改完后的这段代码可以工作吗？如果运气好，你会发现这样改又有问题，运气不好，这段代码在线下运行良好，这段代码就顺利上线了。不久你就会发现系统中会有一些其他很诡异的bug。原因在于并行流的设计比较特殊，父线程也有可能参与到并行流线程池的调度，那如果上面的`process`方法被父线程执行，那么父线程的上下文会被清理。导致后续拷贝到子线程的上下文都为`null`，同样产生丢失上下文的问题。

![16bc6ddbfcfb632cef1f7660c478a88f.gif][]

往期推荐

[![ad12fc7176c1ace613a98758342b0f36.png][]][ad12fc7176c1ace613a98758342b0f36.png 1]

[额！Java中用户线程和守护线程区别这么大？][ad12fc7176c1ace613a98758342b0f36.png 1]

[![0e89c6a646cfc595d676c8e54f8cf516.png][]][0e89c6a646cfc595d676c8e54f8cf516.png 1]

[线程的故事：我的3位母亲成就了优秀的我！][0e89c6a646cfc595d676c8e54f8cf516.png 1]

[![b91e8c01398213f7ca6fe587f70f13ab.png][]][b91e8c01398213f7ca6fe587f70f13ab.png 1]

[Semaphore自白：限流器用我就对了！][b91e8c01398213f7ca6fe587f70f13ab.png 1]

[![4c8cff9e0af6bd732e10e01bdb13d302.png][]][4c8cff9e0af6bd732e10e01bdb13d302.png 1]

[CyclicBarrier：人齐了，老司机就发车了！][4c8cff9e0af6bd732e10e01bdb13d302.png 1]

[d5713ee50d128d72cb4f04ba1862b94c.png]: https://img-blog.csdnimg.cn/img_convert/d5713ee50d128d72cb4f04ba1862b94c.png
[16bc6ddbfcfb632cef1f7660c478a88f.gif]: https://img-blog.csdnimg.cn/img_convert/16bc6ddbfcfb632cef1f7660c478a88f.gif
[ad12fc7176c1ace613a98758342b0f36.png]: https://img-blog.csdnimg.cn/img_convert/ad12fc7176c1ace613a98758342b0f36.png
[ad12fc7176c1ace613a98758342b0f36.png 1]: http://mp.weixin.qq.com/s?__biz=MzU1NTkwODE4Mw%3D%3D&chksm=fbcf835eccb80a48d244250ca7d6725de2a72091602994e402b97b51e5f4b63f8ecbf2c60f99&idx=1&mid=2247495270&scene=21&sn=33c3316028dd1cb8883e63da328fdbd4#wechat_redirect
[0e89c6a646cfc595d676c8e54f8cf516.png]: https://img-blog.csdnimg.cn/img_convert/0e89c6a646cfc595d676c8e54f8cf516.png
[0e89c6a646cfc595d676c8e54f8cf516.png 1]: http://mp.weixin.qq.com/s?__biz=MzU1NTkwODE4Mw%3D%3D&chksm=fbcf830cccb80a1a69c0b37109082b541b5ed1df80943b9ec50a6a663393a8fc7a7a1d033979&idx=1&mid=2247495220&scene=21&sn=c81f58dad1b384181bf2e5af6cf12440#wechat_redirect
[b91e8c01398213f7ca6fe587f70f13ab.png]: https://img-blog.csdnimg.cn/img_convert/b91e8c01398213f7ca6fe587f70f13ab.png
[b91e8c01398213f7ca6fe587f70f13ab.png 1]: http://mp.weixin.qq.com/s?__biz=MzU1NTkwODE4Mw%3D%3D&chksm=fbcf8325ccb80a332977b10d31ff0ea07be3fb91c7f4cb696605c38d5ac4258167c46bbf62e3&idx=1&mid=2247495197&scene=21&sn=12b9e794ea7f425cd50b2b79cf0aa80b#wechat_redirect
[4c8cff9e0af6bd732e10e01bdb13d302.png]: https://img-blog.csdnimg.cn/img_convert/4c8cff9e0af6bd732e10e01bdb13d302.png
[4c8cff9e0af6bd732e10e01bdb13d302.png 1]: http://mp.weixin.qq.com/s?__biz=MzU1NTkwODE4Mw%3D%3D&chksm=fbcf80abccb809bd3bf7f69ecb785db9fcd296aa49ed27ea378a5d6a9f2a7aa46931b762f8f4&idx=1&mid=2247495059&scene=21&sn=ba5f236b755897ec5a2de37f3977aa50#wechat_redirect