从源码看ThreadLocal 实现原理及其内存泄露分析

前言

ThreadLocal的作用:

  ThreadLocal提供的实际上就是一种线程隔离，不同的线程的变量归属不同的线程，线程之间不能想问访问各自的变量，当线程生命周期结束的时候，线程会被销毁。

  之前只知道它的作用，大概还了解一点原理知道内部用的是Map，今天又遇见了，于是有了这篇源码分析.

几个变量

    //线程hashcode值来标识线程,nextHashCode()是获得下一次的值
    private final int threadLocalHashCode = nextHashCode();
    //AtomicInteger类型的hashcode，从0开始
    private static AtomicInteger nextHashCode =new AtomicInteger();
    //每次hash增长的值
    private static final int HASH_INCREMENT = 0x61c88647;

  依稀记得AtomicInteger是通过自选式的CAS操作来维护原子性的，通常类似于i++这种，读取，计算，写的步骤都不是原子性的。

构造函数

public ThreadLocal() {
}

构造函数很简单，啥也没有。

ThreadLocal Set方法

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

  这里关键的是getMap这个方法，它把Thread传进getMap去获得ThreadLocalMap。ThreadLocal.ThreadLocalMap threadLocals = null;虽然写在了Thread中，但是用的确实ThreadLocal中的map。初次使用map一定为空，这个时候就会创建map

CreateMap

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

抛砖引玉，我们进入ThreadLocalMap中。

ThreadLocalMap

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
    table = new Entry[INITIAL_CAPACITY];
    int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
    table[i] = new Entry(firstKey, firstValue);
    size = 1;
    setThreshold(INITIAL_CAPACITY);
}

由这个构造函数，我们可以画出ThreadLocal所用的map结构。

  图中，黄线代表弱引用。我们挑出这两个重要的引用，别的不用特别看。需要注意的是，当弱引用作为不可达对象的时候，会在下一次GC的时候会被回收。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 set方法

        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();
        }

  代码逻辑比hashMap简单多了，hashMap是拉链法，它这边直接使用的table数组，如果那个位置已经有了对象，就nextIndex，探测下一个位置，就是标准的线性探测法解决冲突，HashMap是链地址法。就是如果冲突了就向后再挂一个对象。由此我们引入内存泄露的问题。

内存泄露

  这里面的细节小逻辑，新手也看不懂，但是需要挑出来的是这里的cleanSomeSlots，清除引用，因为key ThreadLocal是弱引用，当外面没有强引用引用它的时候，即成为无法到达的key将会被GC掉，但是这个时候会存在键为null的value还没有被清除，所以就要通过这个方法去清除。这个清除方法就不贴出来了，只要知道它是一次遍历看看有哪些key为null的，然后将值设置为null来帮助GC。
　　总结下来就是，set方法会触发一次清除弱引用残留下来的value值。同样get和remove也会进行清理。

特殊情况: from:例子出处

public class HelloWorldExample extends HttpServlet {

    private static final long serialVersionUID = 1L;

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

    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("");
        out.println("");

        out.println("");
        out.println("");
        out.println("");
        //(3)
        out.println(this.toString());
        //(4)
        out.println(Thread.currentThread().toString());

        out.println("");
        out.println("");
    }
}

在Servlet中，有一个类为ThreadLocal的静态变量，打个比方，如果说有5个线程访问这个Servlet实例，Servlet 为5个线程都创建了map，但是没有进行remove久而久之内存自然会蹭蹭往上涨, 用完了线程没有被销毁而是回到了线程池里面，当Thread被销毁了还好，强引用链断了，自然就会被销毁了。官方tomcat在7.0+的时候会解决这个问题，上面的from连接最后给出了答案，重新启动的时候线程会被renew。

十二月 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.

不得不注意的问题: 试想一下，当Thread被销毁的时候，静态变量是在类加载的时候就初始化了的，所以说内存中除非JVM停掉，那么这个静态变量永远会存在，及时Thread线程被回收了，那么这个ThreadLocal引用还是存在的，所以remove方法对ThreadLocalMap中的引用清除是清除了就是说map里面的Entry被清掉了，但是这个强引用new 出来的实例依旧是存在的。

总结一下: 用完了就remove掉，静态变量 会一直存在。

get方法

    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }
      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;
        }

不难看出在最后expungeStaleEntry(i);也执行了一次清理。

remove方法

        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;
                }
            }
        }

remove方法是最正宗的手动清除了

get，set，remove总结

  由上面的分析不难发现，在进行set方法的时候是清除some，get和remove的时候是大清除，如果是同一个线程执行代码的话，那么还可以通过多次的get，set进行清楚，如果是多线程的环境下，你用了不remove，极有可能会造成内存泄漏，不完全清理的问题也可能存在。线程不结束，那么这个Thread引用链将会永远存在。所以用完了remove掉是个好习惯。也是必须这样用的。

总结

  此次就ThreadLocal这个类的实现进行了分析，从get、set、remove这三个方法把内存泄漏的问题搞清楚了，它的内部是Thread维护的一个Map属性，键是ThreadLocal变量，值是set进去的值，冲突处理是线性探测法。重要的部分都已经列出来了，每一个字都是手打，希望对和我一样不了解的人一些帮助。如果错误或者理解不对的地方还望纠正

经典一句:
　　同步机制以时间换空间，多个线程排队等待资源释放。ThreadLocal空间换时间每个线程单独一份资源，互不相干。妙哉妙哉。

参考链接

https://www.sczyh30.com/posts/Java/java-concurrent-threadlocal/
http://blog.xiaohansong.com/2016/08/06/ThreadLocal-memory-leak/

9.18日补充：
　　为什么ThreadLocal内部用的是弱引用？大概是因为内部ThreadLocalMap不是人new出来的，它不归人管，而是在内部使用的，倘若new出来的ThreadLocal变量被gc了，那么ThreadLocalMap中引用ThreadLocal的Entry也应该被gc，这就是所说的弱引用一旦没有了别处的引用就会被gc这个道理，Entry继承的是WeakReference，它应该被回收，毕竟key是ThreadLocal。