ThreadLocal与内存泄漏问题

1. ThreadLocal简介

1.1 应用场景

ThreadLocal在日常业务开发中并不多见，但应用底层必不可少，在多线程环境下，为每个线程提供一份变量副本，实现变量隔离，防止产生线程安全问题。

比如Hibernate就是用了ThreadLocal来管理session的线程安全问题；
再比如controller注入HttpServletRequest对象，属于共享的全局变量，但是如何保证每个线程接受的数据是属于自己的呢？底层是spring生成的是HttpServletRequest代理对象，在实际使用的时候，通过代理拿到ThreadLocal保存的request副本，详见AutoWireUtils类源码。

1.2 举例

举一个应用的例子，SimpleDateFormat转换日期是通过Calendar来操作的，而Calendar是线程不安全的，如果不想在方法内频繁创建SimpleDateFormat对象，而是想做为共享变量来使用，ThreadLocal可以为每个线程提供一个SimpleDateFormat副本，以下是封装的工具类。

public class SimpleDateFormatUtil {

    private static ThreadLocal<Map<String, SimpleDateFormat>> threadLocal = new ThreadLocal<>();

    public static SimpleDateFormat getFormat(String pattern) {
        Map<String, SimpleDateFormat> map = threadLocal.get();
        if (map == null) {
            map = new HashMap<>();
        }
        SimpleDateFormat sdf = map.get(pattern);
        if (sdf == null) {
            sdf = new SimpleDateFormat(pattern);
            map.put(pattern, sdf);
            threadLocal.set(map);
        }
        return sdf;
    }

}

这里建议用java8的 LocalDate、LocalTime

2. 内存泄漏

长生命周期的对象持有短生命周期的引用，就可能发生内存泄漏；
通俗的说就是一个不再被程序使用的对象由于被异常持有引用，导致无法垃圾回收，从而引发内存泄漏。

举一个简单的例子：这里期望a被垃圾回收，虽然方法栈里a引用无法再指向堆内存中创建的对象，但由于b的内部持有对象a的引用，即b内部的成员a仍然能指向堆内存中创建的对象，导致内存泄漏，除非能找到所有引用a的地方将其赋值为null，否则a的生命周期会持续到所有引用对象被回收而一起结束；

A a = new A();
B b = new B(a);
a = null;
System.out.println(b.getA());

再看一个JDK源码设计的例子，ArrayList在移除一个元素的时候，会把 index + 1及后面的元素复制到以index开始的位置，即把后面的元素往前移动一位，然后把最后一个元素置空，否则ArrayList会一直持有最后一个元素的引用，导致内存泄漏，直到ArrayList被垃圾回收；

	public E remove(int index) {
	    rangeCheck(index);
	
	    modCount++;
	    E oldValue = elementData(index);
	
	    int numMoved = size - index - 1;
	    if (numMoved > 0)
	        System.arraycopy(elementData, index+1, elementData, index,
	                         numMoved);
	    elementData[--size] = null; // clear to let GC do its work
	
	    return oldValue;
	}

3. ThreadLocal为什么可能产生内存泄漏

ThreadLocal的内部类ThreadLocalMap中，有一个Entry内部类设计。ThreadLocal做变量隔离都是通过ThreadLocalMap来操作的，里面有一个Entry数组，Entry是真正存值的地方。
产生内存泄漏的关键在于内部类Entry的设计。

   static class Entry extends WeakReference<ThreadLocal<?>> {
       /** The value associated with this ThreadLocal. */
       Object value;

       Entry(ThreadLocal<?> k, Object v) {
           super(k);
           value = v;
       }
   }

Entry继承WeakReference，即泛型ThreadLocal是弱引用，所以在垃圾回收的时候可以顺利被回收，但是对应的value可能不会被回收，原因在于ThreadLocalMap。
ThreadLocalMap是Thread的成员属性，所以生命周期跟随当前线程。

• 如果线程正常结束，ThreadLocal，ThreadLocalMap，Entry都因不可达而会被回收，这样是都是正常的；
• 如果使用的是线程池，线程复用导致ThreadLocalMap一直存在，Entry内部的value就不会被垃圾回收，产生k为null但是value不为null的情况，从而导致内存泄漏。

问题1：k值弱引用导致内存泄漏，为什么不设置为强引用？
答：如果把k设置为强引用，那么当threadLocal被垃圾回收，当前线程因复用等情况而未结束，持有ThreadLocalMap的强引用，ThreadLocalMap的Entry又强引用threadLocal和value，这样导致连threadLocal都不能正常回收。

4. 如何解决这个问题

JDK源码设计的时候已经考虑过这个问题，所以ThreadLocal的set和get方法通过ThreadLocalMap做了对旧值的擦除操作。

ThreadLocalMap.set方法：每一次set新值的时候，首先根据threadLocal的hashCode计算在Entry数组中的位置，然后向后环形对entry进行以下操作：

• 如果entry为null，则直接插入，然后调用cleanSomeSlots方法检测并清除旧entry；
• 如果entry的k等于当前的threadLocal，代表是同一个threadLocal，直接替换value；
• 如果当前的entry不为null但k为null，代表上述内存泄漏的情况，调用replaceStaleEntry处理旧entry并set新值；
• 如果entry不为null，entry的k不为null也不等于当前的threadLocal，代表hash冲突，可能是不同的threadLocal计算出相同的位置，已经有其他threadLocal在这个位置了，然后向后环形重复上述操作；

      private void set(ThreadLocal<?> key, Object value) {

          // We don't use a fast path as with get() because it is at
          // least as common to use set() to create new entries as
          // it is to replace existing ones, in which case, a fast
          // path would fail more often than not.

          Entry[] tab = table;
          int len = tab.length;
          int i = key.threadLocalHashCode & (len-1);

          for (Entry e = tab[i];
               e != null;
               e = tab[i = nextIndex(i, len)]) {
              ThreadLocal<?> k = e.get();

              if (k == key) {
                  e.value = value;
                  return;
              }

              if (k == null) {
                  replaceStaleEntry(key, value, i);
                  return;
              }
          }

          tab[i] = new Entry(key, value);
          int sz = ++size;
          if (!cleanSomeSlots(i, sz) && sz >= threshold)
              rehash();
      }

ThreadLocalMap.getEntry方法：每一次get的时候，首先根据threadLocal的hashCode计算在Entry数组中的位置，然后进行以下操作：

• 如果entry不为null，并且entry中的k等于当前threadLocal，返回entry中存储的value；
• 如果entry为null，或者entry的k不等于当前threadLocal，查看getEntryAfterMiss方法，对entry数组向后环形遍历：当entry不为null且entry的k等于当前threadLocal，返回entry里的value；当entry不为null但entry的k为null，处理当前entry及其value防止内存泄漏；当entry既不等于当前threadLocal也不为null，说明hash冲突，向后查找下一个entry继续上述操作；

      private Entry getEntry(ThreadLocal<?> key) {
          int i = key.threadLocalHashCode & (table.length - 1);
          Entry e = table[i];
          if (e != null && e.get() == key)
              return e;
          else
              return getEntryAfterMiss(key, i, e);
      }
      
      private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
          Entry[] tab = table;
          int len = tab.length;

          while (e != null) {
              ThreadLocal<?> k = e.get();
              if (k == key)
                  return e;
              if (k == null)
                  expungeStaleEntry(i);
              else
                  i = nextIndex(i, len);
              e = tab[i];
          }
          return null;
      }

问题2：如果两个threadLocal产生hash冲突，按相邻位置set，比如[0]和[1]，如果第一个已经垃圾回收，按上述条件会调用expungeStaleEntry，第二个threadLocal处于正常状态是怎么取到值的？

答：关键就在于expungeStaleEntry，如代码所示，首先会将第一个threadLocal所属entry清理掉，然后把相邻threadLocal的entry改到这个位置，即由[1]改到[0]，并将[1]上的entry置为null。

      private int expungeStaleEntry(int staleSlot) {
          Entry[] tab = table;
          int len = tab.length;

          // expunge entry at staleSlot
          tab[staleSlot].value = null;
          tab[staleSlot] = null;
          size--;

          // Rehash until we encounter null
          Entry e;
          int i;
          for (i = nextIndex(staleSlot, len);
               (e = tab[i]) != null;
               i = nextIndex(i, len)) {
              ThreadLocal<?> k = e.get();
              if (k == null) {
                  e.value = null;
                  tab[i] = null;
                  size--;
              } else {
                  int h = k.threadLocalHashCode & (len - 1);
                  if (h != i) {
                      tab[i] = null;

                      // Unlike Knuth 6.4 Algorithm R, we must scan until
                      // null because multiple entries could have been stale.
                      while (tab[h] != null)
                          h = nextIndex(h, len);
                      tab[h] = e;
                  }
              }
          }
          return i;
      }

更多关于ThreadLocal源码的解释可参考：

https://www.jianshu.com/p/dde92ec37bd1

5. 开发中如何避免

每次使用完ThreadLocal及时调用remove()方法，remove方法会将key和value擦除；
c.clear负责清楚entry的k，expungeStaleEntry负责清楚entry的value。

      private void remove(ThreadLocal<?> key) {
          Entry[] tab = table;
          int len = tab.length;
          int i = key.threadLocalHashCode & (len-1);
          for (Entry e = tab[i];
               e != null;
               e = tab[i = nextIndex(i, len)]) {
              if (e.get() == key) {
                  e.clear();
                  expungeStaleEntry(i);
                  return;
              }
          }
      }