使用ThreadLocal不当可能会导致内存泄露

8.2 使用ThreadLocal不当可能会导致内存泄露

基础篇已经讲解了ThreadLocal的原理,本节着重来讲解下使用ThreadLocal会导致内存泄露的原因,并讲解使用ThreadLocal导致内存泄露的案例。

8.2.1 为何会出现内存泄露

基础篇我们讲到了ThreadLocal只是一个工具类,具体存放变量的是在线程的threadLocals变量里面,threadLocals是一个ThreadLocalMap类型的,

 

image.png

如上图ThreadLocalMap内部是一个Entry数组,Entry继承自WeakReference,Entry内部的value用来存放通过ThreadLocal的set方法传递的值,那么ThreadLocal对象本身存放到哪里了吗?下面看看Entry的构造函数:

 Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
 }
 
public WeakReference(T referent) {
   super(referent);
}
    
Reference(T referent) {
   this(referent, null);
}

Reference(T referent, ReferenceQueue<? super T> queue) {
   
   this.referent = referent;
   this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}

可知k被传递到了WeakReference的构造函数里面,也就是说ThreadLocalMap里面的key为ThreadLocal对象的弱引用,具体是referent变量引用了ThreadLocal对象,value为具体调用ThreadLocal的set方法传递的值。

当一个线程调用ThreadLocal的set方法设置变量时候,当前线程的ThreadLocalMap里面就会存放一个记录,这个记录的key为ThreadLocal的引用,value则为设置的值。如果当前线程一直存在而没有调用ThreadLocal的remove方法,并且这时候其它地方还是有对ThreadLocal的引用,则当前线程的ThreadLocalMap变量里面会存在ThreadLocal变量的引用和value对象的引用是不会被释放的,这就会造成内存泄露的。但是考虑如果这个ThreadLocal变量没有了其他强依赖,而当前线程还存在的情况下,由于线程的ThreadLocalMap里面的key是弱依赖,则当前线程的ThreadLocalMap里面的ThreadLocal变量的弱引用会被在gc的时候回收,但是对应value还是会造成内存泄露,这时候ThreadLocalMap里面就会存在key为null但是value不为null的entry项。其实在ThreadLocal的set和get和remove方法里面有一些时机是会对这些key为null的entry进行清理的,但是这些清理不是必须发生的,下面简单说下ThreadLocalMap的remove方法的清理过程:

private void remove(ThreadLocal<?> key) {

  //(1)计算当前ThreadLocal变量所在table数组位置,尝试使用快速定位方法
  Entry[] tab = table;
  int len = tab.length;
  int i = key.threadLocalHashCode & (len-1);
  //(2)这里使用循环是防止快速定位失效后,变量table数组
  for (Entry e = tab[i];
       e != null;
       e = tab[i = nextIndex(i, len)]) {
      //(3)找到
      if (e.get() == key) {
          //(4)找到则调用WeakReference的clear方法清除对ThreadLocal的弱引用
          e.clear();
          //(5)清理key为null的元素
          expungeStaleEntry(i);
          return;
      }
  }
}
        
 private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            //(6)去掉去value的引用
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            Entry e;
            int i;
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();
                
                //(7)如果key为null,则去掉对value的引用。
                if (k == null) {
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    if (h != i) {
                        tab[i] = null;
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            return i;
        }
  • 步骤(4)调用了Entry的clear方法,实际调用的是父类WeakReference的clear方法,作用是去掉对ThreadLocal的弱引用。
  • 步骤(6)是去掉对value的引用,到这里当前线程里面的当前ThreadLocal对象的信息被清理完毕了。
  • 代码(7)从当前元素的下标开始看table数组里面的其他元素是否有key为null的,有则清理。循环退出的条件是遇到table里面有null的元素。所以这里知道null元素后面的Entry里面key 为null的元素不会被清理。

总结:ThreadLocalMap内部Entry中key使用的是对ThreadLocal对象的弱引用,这为避免内存泄露是一个进步,因为如果是强引用,那么即使其他地方没有对ThreadLocal对象的引用,ThreadLocalMap中的ThreadLocal对象还是不会被回收,而如果是弱引用则这时候ThreadLocal引用是会被回收掉的,虽然对于的value还是不能被回收,这时候ThreadLocalMap里面就会存在key为null但是value不为null的entry项,虽然ThreadLocalMap提供了set,get,remove方法在一些时机下会对这些Entry项进行清理,但是这是不及时的,也不是每次都会执行的,所以一些情况下还是会发生内存泄露,所以在使用完毕后即使调用remove方法才是解决内存泄露的王道。

8.2.2 线程池中使用ThreadLocal导致的内存泄露

下面先看线程池中使用ThreadLocal的例子:

public class ThreadPoolTest {

    static class LocalVariable {
        private Long[] a = new Long[1024*1024];
    }

    // (1)
    final static ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES,
            new LinkedBlockingQueue<>());
    // (2)
    final static ThreadLocal<LocalVariable> localVariable = new ThreadLocal<LocalVariable>();

    public static void main(String[] args) throws InterruptedException {
        // (3)
        for (int i = 0; i < 50; ++i) {
            poolExecutor.execute(new Runnable() {
                public void run() {
                    // (4)
                    localVariable.set(new LocalVariable());
                    // (5)
                    System.out.println("use local varaible");
                    //localVariable.remove();

                }
            });

            Thread.sleep(1000);
        }
        // (6)
        System.out.println("pool execute over");
    }
  • 代码(1)创建了一个核心线程数和最大线程数为5的线程池,这个保证了线程池里面随时都有5个线程在运行。
  • 代码(2)创建了一个ThreadLocal的变量,泛型参数为LocalVariable,LocalVariable内部是一个Long数组。
  • 代码(3)向线程池里面放入50个任务
  • 代码(4)设置当前线程的localVariable变量,也就是把new的LocalVariable变量放入当前线程的threadLocals变量。
  • 由于没有调用线程池的shutdown或者shutdownNow方法所以线程池里面的用户线程不会退出,进而JVM进程也不会退出。

运行当前代码,使用jconsole监控堆内存变化如下图:

 

image.png

然后解开localVariable.remove()注释,然后在运行,观察堆内存变化如下:

 

image.png

从运行结果一可知,当主线程处于休眠时候进程占用了大概77M内存,运行结果二则占用了大概25M内存,可知运行代码一时候内存发生了泄露,下面分析下泄露的原因。

运行结果一的代码,在设置线程的localVariable变量后没有调用localVariable.remove()
方法,导致线程池里面的5个线程的threadLocals变量里面的new LocalVariable()实例没有被释放,虽然线程池里面的任务执行完毕了,但是线程池里面的5个线程会一直存在直到JVM退出。这里需要注意的是由于localVariable被声明了static,虽然线程的ThreadLocalMap里面是对localVariable的弱引用,localVariable也不会被回收。运行结果二的代码由于线程在设置localVariable变量后即使调用了localVariable.remove()方法进行了清理,所以不会存在内存泄露。

总结:线程池里面设置了ThreadLocal变量一定要记得及时清理,因为线程池里面的核心线程是一直存在的,如果不清理,那么线程池的核心线程的threadLocals变量一直会持有ThreadLocal变量。

8.2.3 Tomcat的Servlet中使用ThreadLocal导致内存泄露

首先看一个Servlet的代码如下:


public class HelloWorldExample extends HttpServlet {

    private static final long serialVersionUID = 1L;

    static class LocalVariable {
        private Long[] a = new Long[1024 * 1024 * 100];
    }

    //(1)
    final static ThreadLocal<LocalVariable> localVariable = new ThreadLocal<LocalVariable>();

    @Override
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
        //(2)
        localVariable.set(new LocalVariable());

        response.setContentType("text/html");
        PrintWriter out = response.getWriter();

        out.println("<html>");
        out.println("<head>");

        out.println("<title>" + "title" + "</title>");
        out.println("</head>");
        out.println("<body bgcolor=\"white\">");
        //(3)
        out.println(this.toString());
        //(4)
        out.println(Thread.currentThread().toString());

        out.println("</body>");
        out.println("</html>");
    }
}
  • 代码(1)创建一个localVariable对象,
  • 代码(2)在servlet的doGet方法内设置localVariable值
  • 代码(3)打印当前servlet的实例
  • 代码(4)打印当前线程

修改tomcat的conf下sever.xml配置如下:


    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" 
        maxThreads="10" minSpareThreads="5"/>

    <Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

这里设置了tomcat的处理线程池最大线程为10个,最小线程为5个,那么这个线程池是干什么用的那?这里回顾下Tomcat的容器结构,如下图:

image.png

Tomcat中Connector组件负责接受并处理请求,其中Socket acceptor thread 负责接受用户的访问请求,然后把接受到的请求交给Worker threads pool线程池进行具体处理,后者就是我们在server.xml里面配置的线程池。Worker threads pool里面的线程则负责把具体请求分发到具体的应用的servlet上进行处理。

有了上述知识,下面启动tomcat访问该servlet多次,会发现有可能输出下面结果

HelloWorldExample@2a10b2d2 Thread[catalina-exec-5,5,main]
HelloWorldExample@2a10b2d2 Thread[catalina-exec-1,5,main]
HelloWorldExample@2a10b2d2 Thread[catalina-exec-4,5,main]

其中前半部分是打印的servlet实例,这里都一样说明多次访问的都是一个servlet实例,后半部分中catalina-exec-5,catalina-exec-1,catalina-exec-4,说明使用了connector中线程池里面的线程5,线程1,线程4来执行serlvet的。
如果在访问该servlet的同时打开了jconsole观察堆内存会发现内存会飙升,究其原因是因为工作线程调用servlet的doGet方法时候,工作线程的threadLocals变量里面被添加了new LocalVariable()实例,但是没有被remove,另外多次访问该servlet可能用的不是工作线程池里面的同一个线程,这会导致工作线程池里面多个线程都会存在内存泄露。

更糟糕的还在后面,上面的代码在tomcat6.0的时代,应用reload操作后会导致加载该应用的webappClassLoader释放不了,这是因为servlet的doGet方法里面创建new LocalVariable()的时候使用的是webappclassloader,所以LocalVariable.class里面持有webappclassloader的引用,由于LocalVariable的实例没有被释放,所以LocalVariable.class对象也没有没释放,所以
webappclassloader也没有被释放,那么webappclassloader加载的所有类也没有被释放。这是因为应用reload的时候connector组件里面的工作线程池里面的线程还是一直存在的,并且线程里面的threadLocals变量并没有被清理。而在tomcat7.0里面这个问题被修复了,应用在reload时候会清理工作线程池中线程的threadLocals变量,tomcat7.0里面reload后会有如下提示:

十二月 31, 2017 5:44:24 下午 org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
严重: The web application [/examples] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@63a3e00b]) and a value of type [HelloWorldExample.LocalVariable] (value [HelloWorldExample$LocalVariable@4fd7564b]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

8.2.4 总结

Java提供的ThreadLocal给我们编程提供了方便,但是如果使用不当也会给我们带来致命的灾难,编码时候要养成良好的习惯,线程中使用完ThreadLocal变量后,要记得及时remove掉。

欢迎关注微信公众号 ‘技术原始积累’

image.png

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 使用ThreadLocal不当可能会导致内存泄露

加多

加多

Java 攻城狮 at 阿里巴巴
加多,目前就职于阿里巴巴,热衷并发编程、ClassLoader,Spring等开源框架,分布式RPC框架dubbo,springcloud等;爱好音乐,运动。微信公众号:技术原始积累。知识星球账号:技术原始积累
加多

Latest posts by 加多 (see all)

FavoriteLoading添加本文到我的收藏
  • Trackback are closed
  • Comments (5)
    • archerda
    • 01/19. 2018 1:07pm

    “如果当前线程一直存在而没有调用ThreadLocal的remove方法,并且这时候其它地方还是有对ThreadLocal的引用,则当前线程的ThreadLocalMap变量里面会存在ThreadLocal变量的引用和value对象的引用是不会被释放的,这就会造成内存泄露的。”

    — 如果其他地方还有对ThreadLocal的引用的话,这里就应该不算内存泄露了吧。

      • 加多
      • 01/19. 2018 9:59pm

      如果其他地方有引用,也会泄露,只是这时候会泄露value对象

        • 琅琊
        • 01/23. 2018 3:10pm

        我的理解是不算。ThreadLocal内存泄漏其实指的就是value对象,如果其他地方有对ThreadLocal的强引用,那ThreadLocalMap里就不会出现key为null的情况,这样value对象就是有效数据,不算内存泄漏

    • yuhaibo6646737
    • 02/28. 2018 11:43pm

    在“先看线程池中使用ThreadLocal的例子”代码中,在注释localVariable.remove()的情况下,弱引用对象所占内存在下次GC后会被清理,如果是这样可以被GC回收的话,那么严格来说这还是真正的内存泄露吗?

      • yuhaibo6646737
      • 03/01. 2018 12:01am

      这个评论写的有问题,没法删除,只能无视了。如果博主可以删除的话,帮忙删除一下。谢谢!

You must be logged in to post a comment.

return top