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

我在参加Code Review的时候不止一次听到有同学说我写的这个上下文工具没问题在线上跑了好久了。其实这种想法是有问题的ThreadLocal写错难但是用错就很容易本文将会详细总结ThreadLocal容易用错的三个坑内存泄露线程池中线程上下文丢失并行流中线程上下文丢失内存泄露由于ThreadLocal的key是弱引用因此如果使用后不调用remove清理的话会导致对应的value内存泄露。Test public void testThreadLocalMemoryLeaks() { ThreadLocalListInteger localCache new ThreadLocal(); ListInteger 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 ThreadLocalMyCounter { } 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 BizTaskT implements CallableT { 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 ThreadLocalString 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 LinkedBlockingQueueRunnable(40), new XXXThreadFactory(), ThreadPoolExecutor.CallerRunsPolicy);其中最后一个参数控制着当线程池满时该如何处理提交的任务内置有4种策略ThreadPoolExecutor.AbortPolicy //直接抛出异常 ThreadPoolExecutor.DiscardPolicy //丢弃当前任务 ThreadPoolExecutor.DiscardOldestPolicy //丢弃工作队列头部的任务 ThreadPoolExecutor.CallerRunsPolicy //转串行执行可以看到我们初始化线程池的时候指定如果线程池满则新提交的任务转为串行执行那我们之前的写法就会有问题了串行执行的时候调用ContextHolder.remove();会将主线程的上下文也清理即使后面线程池继续并行工作传给子线程的上下文也已经是null了而且这样的问题很难在预发测试的时候发现。并行流中线程上下文丢失如果ThreadLocal碰到并行流也会有很多有意思的事情发生比如有下面的代码class ParallelProcessorT { public void process(ListT dataList) { // 先校验参数篇幅限制先省略不写 dataList.parallelStream().forEach(entry - { doIt(); }); } private void doIt() { String session ContextHolder.get(); // do something } }这段代码很容易在线下测试的过程中发现不能按照预期工作因为并行流底层的实现也是一个ForkJoin线程池既然是线程池那ContextHolder.get()可能取出来的就是一个null。我们顺着这个思路把代码再改一下class ParallelProcessorT { private String session; public ParallelProcessor(String session) { this.session session; } public void process(ListT 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同样产生丢失上下文的问题