java并发系列—超详细ThreadLocal详解

java.lang.ThreadLocal< T >（多看多理解）

​ 概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而 ThreadLocal 采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。
ThreadLocal 并不能替代同步机制，两者面向的问题领域不同。

1. 同步机制是为了同步多个线程对相同资源的并发访问，是为了多个线程之间进行通信的有效方式
2. 而 threadLocal 是隔离多个线程的数据共享，从根本上就不在多个线程之间共享变量，这样当然不需要对多个线程进行同步了。（每个线程有单独的数据，在线程内共享，在线程外独立）

最常见的 ThreadLocal 使用场景为用来解决数据库连接、Session 管理等

	private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<Connection>() {
		protected Connection initialValue() {
			return DriverManager.getConnection(DB_URL);
	}
};
	public static Connection getConnection() {
		return connectionHolder.get();
}

JDK 中建议 ThreadLocal 实例通常来说都是 private static 类型的。（下文有讲）

​ jdk早期的设计为每个 ThreadLocal 类创建一个 Map，然后用线程的 ID 作为 Map 的 key，实例对象作为Map 的 value，这样就能达到各个线程的值隔离的效果。

ThreadLocal 底层实现

​ ThreadLocal 类中有一个静态内部类 ThreadLocalMap，ThreadLocalMap 相当于一个哈希表，用 private Entry[] table;存储数据，而 Entry 是一个实现了弱引用（下一次 gc 时就会被回收）的内部类，它的 key 弱引用。

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

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

​ ThreadLocalMap 的初始大小为 16，负载因子为 2/3（即超过了长度的三分之二就要扩容），每次扩容为原来的 2 倍，可以保证大小始终为 2 的 N 次方。ThreadLocalMap 解决哈希冲突的方法与 hashmap 不同（数组+链表），**ThreadLocalMap 如果 i 位置已经存储了对象，那么就往后挪一个位置依次类推，直到找到空的位置，再将对象存放。**另外，在最后还需要判断一下当前的存储的对象个数是否已经超出了阈值（threshold 的值）大小，如果超出了，需要重新扩充并将所有的对象重新计算位置（rehash 函数来实现）。rehash 函数里面先调用了 expungeStaleEntries（擦除value为null的entry） 函数，然后再判断当前存储对象的大小是否超出了阈值的 3/4。如果超出了，再扩容。看的有点混乱。

**问题：**为什么不直接扩容并重新摆放对象？为啥要搞成这么复杂？

回答：ThreadLocalMap里面存储的Entry对象本质上是一个WeakReference< ThreadLocal>。也就是说，ThreadLocalMap里面存储的对象本质是一个对ThreadLocal对象的弱引用，该ThreadLocal随时可能会被回收！即导致ThreadLocalMap里面对应的Value的Key是null。我们需要把这样的Entry给清除掉，不要让它们占坑。expungeStaleEntries函数就是做这样的清理工作，清理完后，实际存储的对象数量自然会减少，清理完后，实际存储的对象数量自然会减少。这时候再判断，如果存储对象数量还是过多，才会扩容这也不难理解后面的判断的约束条件为阈值的3/4，而不是阈值的大小。

​ ThreadLocalMap 中根据 key 值获得 entry 对象的方法是，得到 table 中的位置 i（根据len-1，低位掩码），如果没找到，则有可能发生哈希冲突，所以调用 getEntryAfterMiss函数从当前位置继续向后找

​ threadLocalHashCode 方法就是在 ThreadLocal 中定义了一个 static 的 atomicInteger，每次调用 threadLocalHashCode 方法都要给它加上一个固定的值（不知道为什么）

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

也就是说，每个线程中内部都有一个 ThreadLocalMap 类型的 threadLocals，

简单解析一下，get方法的流程是这样的：

1. 首先获取当前线程
2. 根据当前线程获取一个Map， map.getEntry(this)，注意这里的 key 是 this，也就是该 ThreadLocal 类。
3. 如果获取的Map不为空，则在Map中以ThreadLocal的引用作为key来在Map中获取对应的value e，否则转到5
4. 如果e不为null，则返回e.value，否则转到5
5. Map为空或者e为空，则通过setInitialValue()（给当前线程的 map new 一个 ThreadLocalMap，传入 initialValue 方法的初值【没重写的话为 null】）函数获取初始值value，然后用ThreadLocal的引用和value作为firstKey和firstValue创建一个新的Map

ThreadLocal 的 set 方法

注意，因为这里 set 的 key 是 this （ThreadLocal 类），所以每一个线程在每一个 ThreadLocal中只能对应一个 value。若想保存多个 value，则需要创建多个 ThreadLocal 类对象。

**总结：**每一个 Thread 内部都封装了一个 ThreadLocalMap，这个 map 的 key 是 ThreadLocal（map.getEntry(this)），value 是具体的变量对象。也就是说，一个 thread 可以保存多个 threadlocal，而正因为 threadlocal 保存在 thread 内部，多线程并发时，每次处理的都是自己内部的数据。

流程

1. 新建一个 ThreadLocal 类（名叫 t1）
2. 重写它的 initialValue 方法，
3. 当一个线程调用 tl 的 get 方法时（此时进入 t1 类内部），
4. 先获得调用 get 方法线程保存的 map，用map.getEntry(this)获得对应的变量对象（因为调用的是 tl 的 get 方法，所以 this 指针为这个 t1）

与早期 JDK 中设计的区别（早期使用线程id作为key，现在每个Thread维护一个ThreadLocalMap映射表，这个映射表的key是ThreadLocal实例本身，value是真正需要存储的Object。）

1. 这样设计之后每个 Map 的 Entry 数量变小了：之前是 Thread 的数量，现在是ThreadLocal 的数量，能提高性能，据说性能的提升不是一点两点(没有亲测)
2. 当 Thread 销毁之后对应的 ThreadLocalMap 也就随之销毁了，能减少内存使用量。

弱引用

​ threadlocal 里面使用了一个存在弱引用的 map，当释放掉 threadlocal 的强引用以后，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，而这块 value 永远不会被访问到了， 如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄露。所以存在着内存泄露。

​ 最好的做法是将调用 threadlocal 的 remove 方法。手动删除不再需要的ThreadLocal，防止内存泄露。所以JDK建议将ThreadLocal变量定义成private static的，这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收，也就能保证任何时候都能根据ThreadLocal的弱引用访问到Entry的value值，然后remove它，防止内存泄露。

​ 例如： ThreadLocal< String > tl = new ThreadLocal< String >()；当 tl=null 时，即释放了强引用，此时这个 ThreadLocal 会被 gc 掉，每个线程中 ThreadLocalMap 的 key（key为 threadlocal），如果 key 为强引用，则这个 ThreadLocal 不会被 gc，就会发生我已经不想要这个 ThreadLocal 了，但还没被 gc。所以为弱引用。value 是我 threadlocal 中 initial出来的

​ 当把 threadlocal 实例置为 null 以后,没有任何强引用指向 threadlocal 实例,所以threadlocal 将会被 gc 回收. 但是,我们的 value 却不能回收,因为存在一条从 currentthread 连接过来的强引用. 只有当前 thread 结束以后, current thread 就不会存在栈中,强引用断开, Current Thread, Map, value 将全部被 GC 回收.

​ 所以得出一个结论就是只要这个线程对象被 gc 回收，就不会出现内存泄露，但在threadLocal 设为 null 和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。其实这是一个对概念理解的不一致，也没什么好争论的。

​ PS.Java 为了最小化减少内存泄露的可能性和影响，在 ThreadLocal 的get,set 的时候都会清除线程 Map 里所有 key 为null 的 value 。 所以最怕的情况就是，lthreadLocal 对象设null 了 ， 开始发生 “ 内存泄露 ” ， 然后使用线程池 ， 这个线程结束 ， 线程放回线程池中不销毁，这个线程一直不被使用，或者分配使用了又不再调用 t get,set 方法，那么这个期间就会发生真正的内存泄露。