ThreadLocal三大坑是什么

本篇内容主要讲解“ThreadLocal三大坑是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“ThreadLocal三大坑是什么”吧!

在海宁等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供网站设计、成都做网站 网站设计制作按需开发网站,公司网站建设,企业网站建设,品牌网站制作,成都全网营销,成都外贸网站制作,海宁网站建设费用合理。

内存泄露

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

@Test  public void testThreadLocalMemoryLeaks() {      ThreadLocal> localCache = new ThreadLocal<>();     List 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源码的同学会知道,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 {  }  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 implements Callable  {      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 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(40), new XXXThreadFactory(), ThreadPoolExecutor.CallerRunsPolicy);

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

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

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

并行流中线程上下文丢失

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

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

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

class ParallelProcessor {        private String session;         public ParallelProcessor(String session) {          this.session = session;      }          public void process(List 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,同样产生丢失上下文的问题,关于并行流的实现可

到此,相信大家对“ThreadLocal三大坑是什么”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


分享文章:ThreadLocal三大坑是什么
链接分享:http://pwwzsj.com/article/pieojh.html