我在参加Code Review的时候不止一次听到有同学说:我写的这个上下文工具没问题,在线上跑了好久了。其实这种想法是有问题的,ThreadLocal
写错难,但是用错就很容易,本文将会详细总结ThreadLocal
容易用错的三个坑:
- 内存泄露
- 线程池中线程上下文丢失
- 并行流中线程上下文丢失
内存泄露
由于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的时候能够被清理。
其实看过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
,同样产生丢失上下文的问题。