百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

细数ThreadLocal三大坑,内存泄露仅是小儿科

zhezhongyun 2025-06-10 04:05 1 浏览

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

内存泄露

线程池中线程上下文丢失

并行流中线程上下文丢失

内存泄露

由于ThreadLocalkey是弱引用,因此如果使用后不调用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的值被重置之后cacheInstanceThreadLocalMap中的value引用,无法被GC,但是其keyThreadLocal实例的引用是一个弱引用,本来ThreadLocal的实例被localCacheThreadLocalMapkey同时引用,但是当localCache的引用被重置之后,则ThreadLocal的实例只有ThreadLocalMapkey这样一个弱引用了,此时这个实例在GC的时候能够被清理。

其实看过ThreadLocal源码的同学会知道,ThreadLocal本身对于keynullEntity有自清理的过程,但是这个过程是依赖于后续对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,同样产生丢失上下文的问题,关于并行流的实现可以参考文章啥?用了并行流还更慢了。

原文链接:
https://mp.weixin.qq.com/s/AWTDurC5Kx-M-TBTYZmcDA

相关推荐

屏幕属性详解:DCI-P3、对比度、色域、Nit

屏幕属性详解:DCI-P3、对比度、色域、Nit---一、DCI-P3(色域标准)1.定义DCI-P3是由美国电影工业制定的广色域标准,覆盖CIE1931色彩空间的约96%,尤其强化红色和绿...

Qt属性系统(Qt Property System)(qt的pro文件属性说明)

Qt提供了巧妙的属性系统,它与某些编译器支持的属性系统相似。然而,作为平台和编译器无关的库,Qt不能够依赖于那些非标准的编译器特性,比如__property或者[property]。Qt的解决方案...

用 Cursor 开发 10 +项目后,汇总了40 多条提示词

每次跟新手讲解Cursor的使用技巧时,他们总会说:"哎呀,这工具好是好,就是不知道该怎么跟它对话..."是的,不少小伙伴都在为这个困扰:手握着强大的AI编程工具,却像拿着一把...

Excel常用技能分享与探讨(5-宏与VBA简介 VBA与数据库)

在VBA(VisualBasicforApplications)中使用数据库(如Access、SQLServer、MySQL等)具有以下优点,适用于需要高效数据管理和复杂业务逻辑的场景:1....

汽车诊断协议J1850-VPW 测试(汽车诊断协议工程师干啥的)

硬件说明:MCU:GD32C103120M,128K,32kRAM.输入:USB5V.OBD功能口定义:OBD(2,10)VPWM、OBD7(K线)、OBD6(CANH)、OBD14(...

ssl证书有哪些类型?有什么区别?(ssl证书的区别)

以下是**Windows服务器常用快捷命令大全(100条)**,涵盖系统管理、网络诊断、安全维护、文件操作等场景,适合管理员快速操作和故障排查:---###**一、系统信息与配置**1.**`s...

嵌入式工程师竟然看不懂这些专业语句,那真别怪人说你菜

本文出自公众号:硬件笔记本,原创文章,转载请注明出处AASIC(专用集成电路)Application-SpecificIntegratedCircuit.Apieceofcustom-de...

同星提供SecOC信息安全解决方案(上海同星)

需求背景在传统的汽车电子结构中,车内的电控单元(ECU)数量和复杂性受到限制,通信带宽也受到限制。因此,人们普遍认为车内各个ECU之间的通信是可靠的。只要ECU节点接收到相应的消息,就会对其进行处理。...

H3C MSR系列路由器EAA监控策略配置举例

1简介本文档介绍使用EAA监控策略进行网络监控的典型配置举例。2配置前提本文档适用于使用ComwareV7软件版本的MSR系列路由器,如果使用过程中与产品实际情况有差异,请参考相关产品手册,或以...

网卡DM9000裸机驱动开发详解(网卡驱动9462)

一、网卡1.概念网卡是一块被设计用来允许计算机在计算机网络上进行通讯的计算机硬件。由于其拥有MAC地址,因此属于OSI模型的第2层。它使得用户可以通过电缆或无线相互连接。每一个网卡都有一个被称为MA...

如何检验自己的手机有没有问题,实操干货!包学会

此贴供已购买二手苹果或正打算购买的朋友参考,已入新机的朋友也可以验一下你的手机有没有问题。无废话,直接上干货以小编随机挑的一台12为例1.外观:拿到手机先看整体外观,是否与商家描述的外观一致,磕碰和划...

再不看就删了!超详细的Ribbon源码解析

Ribbon简介什么是Ribbon?Ribbon是springcloud下的客户端负载均衡器,消费者在通过服务别名调用服务时,需要通过Ribbon做负载均衡获取实际的服务调用地址,然后通过httpcl...

细数ThreadLocal三大坑,内存泄露仅是小儿科

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

微服务架构下的Java服务监控:让程序“健康自检”不再难

微服务架构下的Java服务监控:让程序“健康自检”不再难引言:为什么需要服务监控?在微服务架构的世界里,我们的系统由众多小型且独立的服务组成。想象一下,这些服务就像一群跳舞的小精灵,在各自的舞台上表演...

6. 并发编程(并发编程模型)

本章深入解析Go语言并发编程核心机制,涵盖调度原理、通信模式及工程实践,结合性能优化与陷阱规避策略。6.1Goroutine基础6.1.1创建与调度//启动goroutinegofunc()...