使用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掉。

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