深入了解Threadlocal

摘要：通过将保存在中，每个线程都会拥有属于自己的，代码如下所示然后你就可以安心地调用了，不用考虑线程安全问题。这样设计的好处就是，当线程死掉之后，没有强引用，方便收集器回收。

想必大家都对Threadlocal很熟悉吧，今天我们就一起来深入学习一下。Threadlocal我更倾向于将其翻译成线程局部变量。它有什么用处呢？Threadlocal对象通常用于防止对可变的单实例变量或全局变量进行共享。在spring中，通过将事务上下文保存在静态的threadlocal中，当框架代码需要判断当前运行的是哪一个事务时，只需要从ThreadLocal对象中获取事务上下文，这种机制很方便，避免了在每个方法都要传递上下文信息。

众所周知，SimpleDateFormat不是一个线程安全的类，在多线程环境下使用同一个实例是不正确的。通过将SimpleDateFormat保存在Threadlocal中，每个线程都会拥有属于自己的SimpleDateFormat，代码如下所示:

public class DateFormatUtil {

    public static ThreadLocal dataFormatlocal = new ThreadLocal() {
        @Override
        protected SimpleDateFormat initialValue() {
            return new SimpleDateFormat();
        }
    };

    public static SimpleDateFormat getInstance() {
        return dataFormatlocal.get();
    }

}

然后你就可以安心地调用了，不用考虑线程安全问题。当然你也可以在每个线程内部调用new SimpleDateFormat(),但现实情况是大部分开发可能并不知道它是线程不安全的，并且将其封装成一个单例的工具类。至于如何使用，全凭各位读者爱好，这个例子主要用来演示Threadloca的基本用法。

通过之前的演示，我们已经大致知道threadlocal怎么用，并且清楚threadlocal保证了每个线程都有一个局部变量副本。如果以此为需求，让我们自己去设计，会是什么样子的呢？

static Map threadlocal = new HashMap();

这就是我设计的....好吧(╯▽╰)，原谅我水平有限....在这个hashMap中，threadId为key，Object为value,也是可以实现Threadlocal的。那么我们现在要来考虑几个问题。jdk是这样设计的吗？这样设计很low，但是low在哪了？
答：大师们当然不是这样设计了。如果这样设计，每个线程的变量都会永久的保存在hashMap中，存在内存泄漏。

low的写法我们已经见过了，现在我们一起来分下jdk是如何设计的，本文引用jdk1.8。
让我们看下threadlocal的结构图:

类核心方法set、get、initialValue、setInitialValue、remove，后面主要围绕着这几个方法介绍。

类核心变量threadLocalHashCode,nextHashCode,HASH_INCREMENT,其中nextHashCode和HASH_INCREMENT都是静态的，所以对于一个threadlocal对象，成员变量只有一个threadLocalHashCode，这是一个自定义的hash函数，主要为了减少散列桶的冲突（不是本文重点，好奇的可以看下这篇博客https://www.cnblogs.com/ilell...）。

那到底Threadlocal将变量存到哪了呢？眼尖的同学肯定已经发现了ThreadLocalMap，再来看下ThreadlocalMap的结构:

相信读过hashMap源码同学的一定会觉得非常眼熟，ThreadlocalMap的主体也是Entry[]，有resize()和rehash(),区别仅仅就是在于没有使用链表结构和红黑树来处理散列冲突了。Entry的结构我们也很有必要了解一下：

Entry继承了一个弱引用，这里简单介绍下弱引用的知识。弱引用是用来描述非必需对象的，被弱引用关联的对象只能生存到下次垃圾收集发生之前。无论当前内存是否足够，都会回收掉只被弱引用关联的对象。很多面试官都喜欢问Threadlocal是怎么发生内存泄漏的，其实就是在问这个，这个需要我们对Threadlocal有一个整体的了解才能明白，所以放在最后讲。

当我们看完Threadlocal的结构了，我们发现ThreadlocalMap是用来存储的数据结构，那它是怎么和线程关联起来的呢？这里我们开始研究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);
    }

步骤1：获取当前线程
步骤2：通过当前线程获取ThreadLocalMap
步骤3：如果map不为null，将当前线程和value放到map中，否则创建一个map。
如何和线程绑定的玄机就在getMap(t)中。

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

public class Thread implements Runnable {
/* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

看到这里，我们就知道了原来Threadlocal有一个内部类ThreadlocalMap，对于任何一个线程都会有唯一的一个ThreadlocalMap来对应，而这个map实际并不存储在Threadlocal中，而是存在Thread当中，只不过由Threadlocal暴露了一套api来维护Thread的ThreadLocalMap。这样设计的好处就是，当线程死掉之后，ThreadLocalMap没有强引用，方便收集器回收。

继续来看get()

public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;
        }
        return setInitialValue();
    }

如果前面的流程看懂了，这就很简单了。当ThreadLocalMap为null或者Entry为null的时候将会调用setInitialValue();

private T setInitialValue() {
        T value = initialValue();
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
        return value;
    }

流程也很简单，调用initialValue()初始化一个值，获取当前线程的ThreadLocalMap，后面的流程之前都已经介绍过了，这里不再重复，我们主要来看下initialValue()

protected T initialValue() {
        return null;
    }

请注意，protected修饰，return null;这是一个初始化值得方法，也就意味着如果业务允许的话，需要我们自己实现initialValue();

ThreadLocal的remove实现

public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }

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

都非常简单，就留给大家自己看了~。~.

先回顾一下ThreadlocalMap的结构

static class ThreadLocalMap {

        /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */
        static class Entry extends WeakReference {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal k, Object v) {
                super(k);
                value = v;
            }
        }
        .....
        .....
}

然后套用网上的一张图（实线表示强引用，虚线表示虚引用）

ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用引用他，那么系统gc的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：ThreadLocal Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄露。其实jdk已经考虑到了这种情况，ThreadLocalMap的genEntry函数或者set函数会去遍历将key为null的给移除掉，但这明显不是所有情况都成立的，所以需要调用者自己去调用remove函数，手动删除掉需要的threadlocal，防止内存泄露。然后jdk并不建议在栈内声明threadlocal，而是建议将ThreadLocal变量定义成private static的，这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收，也就能保证任何时候都能根据ThreadLocal的弱引用访问到Entry的value值，然后remove它，防止内存泄露。
放图证明这是jdk说的~~

再不睡觉，就天明了..