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

 

瑶海ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！

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

内存泄露

线程池中线程上下文丢失

并行流中线程上下文丢失

内存泄露

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

 
 
 
 
    
  
  
  
  
  1. @Test  
    2. 
  
  
  
  
  2. public void testThreadLocalMemoryLeaks() {  
    3. 
  
  
  
  
  3.     ThreadLocal> localCache = new ThreadLocal<>();  
    4. 
  
  
  
  
  4.    List cacheInstance = new ArrayList<>(10000);  
    5. 
  
  
  
  
  5.     localCache.set(cacheInstance);  
    6. 
  
  
  
  
  6.     localCache = new ThreadLocal<>();  
    7. 
  
  
  
  
  7. } 
    8.

当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应用以及依赖隔离。

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

 
 
 
 
    
  
  
  
  
  1. public class MyCounter {  
    2. 
  
  
  
  
  2.  private int count = 0;  
    3. 
  
  
  
  
  3.  public void increment() {  
    4. 
  
  
  
  
  4.   count++;  
    5. 
  
  
  
  
  5.  }  
    6. 
  
  
  
  
  6.  public int getCount() {  
    7. 
  
  
  
  
  7.   return count;  
    8. 
  
  
  
  
  8.  }  
    9. 
  
  
  
  
  9. }  
    10. 
  
  
  
  
  10. public class MyThreadLocal extends ThreadLocal {  
    11. 
  
  
  
  
  11. }  
    12. 
  
  
  
  
  12. public class LeakingServlet extends HttpServlet {  
    13. 
  
  
  
  
  13.  private static MyThreadLocal myThreadLocal = new MyThreadLocal();  
    14. 
  
  
  
  
  14.  protected void doGet(HttpServletRequest request,  
    15. 
  
  
  
  
  15.    HttpServletResponse response) throws ServletException, IOException {  
    16. 
  
  
  
  
  16.   MyCounter counter = myThreadLocal.get();  
    17. 
  
  
  
  
  17.   if (counter == null) {  
    18. 
  
  
  
  
  18.    counter = new MyCounter();  
    19. 
  
  
  
  
  19.    myThreadLocal.set(counter);  
    20. 
  
  
  
  
  20.   }  
    21. 
  
  
  
  
  21.   response.getWriter().println(  
    22. 
  
  
  
  
  22.     "The current thread served this servlet " + counter.getCount()  
    23. 
  
  
  
  
  23.       + " times"); 
    24. 
  
  
  
  
  24.    counter.increment();  
    25. 
  
  
  
  
  25.  }  
    26. 
  
  
  
  
  26. } 
    27.

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

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值拷贝到子线程中，因此大家会经常看到类似下面的这段代码： 

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

提交的任务定义长这样： 

 
 
 
 
    
  
  
  
  
  1. class BizTask implements Callable  {  
    2. 
  
  
  
  
  2.     private String session = null;     
    3. 
  
  
  
  
  3.     public BizTask(String session) {  
    4. 
  
  
  
  
  4.         this.session = session;  
    5. 
  
  
  
  
  5.     }      
    6. 
  
  
  
  
  6.     @Override  
    7. 
  
  
  
  
  7.     public T call(){ 
    8. 
  
  
  
  
  8.          try {  
    9. 
  
  
  
  
  9.             ContextHolder.set(this.session);  
    10. 
  
  
  
  
  10.             // 执行业务逻辑  
    11. 
  
  
  
  
  11.         } catch(Exception e){  
    12. 
  
  
  
  
  12.             //log error  
    13. 
  
  
  
  
  13.         } finally {  
    14. 
  
  
  
  
  14.             ContextHolder.remove(); // 清理 ThreadLocal 的上下文，避免线程复用时context互串  
    15. 
  
  
  
  
  15.         }  
    16. 
  
  
  
  
  16.         return null;  
    17. 
  
  
  
  
  17.     }  
    18. 
  
  
  
  
  18. } 
    19.

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

 
 
 
 
    
  
  
  
  
  1. class ContextHolder {  
    2. 
  
  
  
  
  2.     private static ThreadLocal localThreadCache = new ThreadLocal<>();     
    3. 
  
  
  
  
  3.     public static void set(String cacheValue) {  
    4. 
  
  
  
  
  4.         localThreadCache.set(cacheValue); 
    5. 
  
  
  
  
  5.     }      
    6. 
  
  
  
  
  6.     public static String get() {  
    7. 
  
  
  
  
  7.         return localThreadCache.get();  
    8. 
  
  
  
  
  8.     }      
    9. 
  
  
  
  
  9.     public static void remove() {  
    10. 
  
  
  
  
  10.         localThreadCache.remove();  
    11. 
  
  
  
  
  11.     }     
    12. 
  
  
  
  
  12. } 
    13.

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

 
 
 
 
    
  
  
  
  
  1. ThreadPoolExecutor executorPool = new ThreadPoolExecutor(20, 40, 30, TimeUnit.SECONDS, new LinkedBlockingQueue(40), new XXXThreadFactory(), ThreadPoolExecutor.CallerRunsPolicy); 
    2.

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

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

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

并行流中线程上下文丢失

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

 
 
 
 
    
  
  
  
  
  1. class ParallelProcessor {   
    2. 
  
  
  
  
  2.     public void process(List dataList) {  
    3. 
  
  
  
  
  3.         // 先校验参数，篇幅限制先省略不写  
    4. 
  
  
  
  
  4.         dataList.parallelStream().forEach(entry -> {  
    5. 
  
  
  
  
  5.             doIt();  
    6. 
  
  
  
  
  6.         }); 
    7. 
  
  
  
  
  7.     } 
    8. 
  
  
  
  
  8.      private void doIt() {  
    9. 
  
  
  
  
  9.         String session = ContextHolder.get();  
    10. 
  
  
  
  
  10.         // do something  
    11. 
  
  
  
  
  11.     }  
    12. 
  
  
  
  
  12. } 
    13.

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

 
 
 
 
    
  
  
  
  
  1. class ParallelProcessor {   
    2. 
  
  
  
  
  2.      private String session;     
    3. 
  
  
  
  
  3.     public ParallelProcessor(String session) {  
    4. 
  
  
  
  
  4.         this.session = session;  
    5. 
  
  
  
  
  5.     }      
    6. 
  
  
  
  
  6.     public void process(List dataList) {  
    7. 
  
  
  
  
  7.         // 先校验参数，篇幅限制先省略不写  
    8. 
  
  
  
  
  8.         dataList.parallelStream().forEach(entry -> {  
    9. 
  
  
  
  
  9.             try {  
    10. 
  
  
  
  
  10.                 ContextHolder.set(session);  
    11. 
  
  
  
  
  11.                 // 业务处理  
    12. 
  
  
  
  
  12.                 doIt();  
    13. 
  
  
  
  
  13.             } catch (Exception e) {  
    14. 
  
  
  
  
  14.                 // log it  
    15. 
  
  
  
  
  15.             } finally {  
    16. 
  
  
  
  
  16.                 ContextHolder.remove();  
    17. 
  
  
  
  
  17.             }  
    18. 
  
  
  
  
  18.         });  
    19. 
  
  
  
  
  19.     }  
    20. 
  
  
  
  
  20.      private void doIt() {  
    21. 
  
  
  
  
  21.         String session = ContextHolder.get();  
    22. 
  
  
  
  
  22.         // do something  
    23. 
  
  
  
  
  23.     }  
    24. 
  
  
  
  
  24. } 
    25.

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

网页题目：细数ThreadLocal三大坑，内存泄露仅是小儿科
当前URL：http://www.csdahua.cn/qtweb/news47/304897.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网

成都快上网为您推荐相关内容

网页设计公司知识

分类信息网

成都移动托管　　 　php空间　　 　成都网站建设　　 　app制作　　 　营销型网站建设　　 　成都网站建设公司　　 　成都托管服务器　　 　泸州做网站　　 　成都花箱厂家　　 　成都力比特　　 　seo关键词优化　　 　成都柴油发电机组　　 　成都免费网站建设公司　　 　网络推广外包　　 　四川成都网站建设　　 　成都微商城开发　　 　400电话办理　　 　铁科精智测控　　 　成都做网站　　 　云服务器