ThreadLocal 不是用来解决共享变量问题的，它与多线程的并发问题没有任何关系。

1.简介

　　早在 JDK 1.2 的版本中就提供Java.lang.ThreadLocal，1.5 开始，ThreadLocal 开始支持泛型。ThreadLocal 为解决多线程程序的并发问题提供了一种新的思路。使用这个工具类可以很简洁地编写出优美的多线程程序。
　　当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
　　从线程的角度看，目标变量就象是线程的本地变量，这也是类名中“Local”所要表达的意思。

2.用法

  • ThreadLocal.get: 获取ThreadLocal中当前线程共享变量的值。
  • ThreadLocal.set: 设置ThreadLocal中当前线程共享变量的值。
  • ThreadLocal.remove: 移除ThreadLocal中当前线程共享变量的值。
  • ThreadLocal.initialValue: ThreadLocal没有被当前线程赋值时或当前线程刚调用remove方法后调用get方法，返回此方法值。

3.原理

3.1 线程共享变量缓存

Thread.ThreadLocalMap<ThreadLocal, Object>

  • Thread: 当前线程，可以通过Thread.currentThread()获取。
  • ThreadLocal：我们的 static ThreadLocal变量。
  • Object: 当前线程共享变量。

我们调用 ThreadLocal.get 方法时，实际上是从当前线程中获取 ThreadLocalMap<ThreadLocal, Object>，然后根据当前 ThreadLocal 获取当前线程共享变量 Object。
ThreadLocal.set，ThreadLocal.remove实际上是同样的道理。

3.2 这种存储结构的好处

  1. 线程死去的时候，线程共享变量 ThreadLocalMap 则销毁。
  2. ThreadLocalMap 键值对数量为 ThreadLocal 的数量，一般来说 ThreadLocal数量很少，相比在ThreadLocal中用 Map 键值对存储线程共享变量（Thread数量一般来说比ThreadLocal数量多），性能提高很多。

3.3 ThreadLocalMap 大致实现

ThreadLocalMap是ThreadLocal的内部类，没有实现Map接口，用独立的方式实现了Map的功能（采用线性探测的方式解决Hash冲突，效率较低），其内部的Entry也独立实现Entry继承自WeakReference。

Entry中的 key 只能是ThreadLocal对象，这点已经被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（弱引用，生命周期只能存活到下次 GC 前），但只有Key是弱引用类型的（注意看 3.1 中的虚线），Value并非弱引用。

ThreadLocalMap的成员变量： 

static class ThreadLocalMap {  
    /**
     * The initial capacity -- MUST be a power of two.
     */
    private static final int INITIAL_CAPACITY = 16;

    /**
     * The table, resized as necessary.
     * table.length MUST always be a power of two.
     */
    private Entry[] table;

    /**
     * The number of entries in the table.
     */
    private int size = 0;

    /**
     * The next size value at which to resize.
     */
    private int threshold; // Default to 0
}

3.4 ThreadLocalMap 的 Hash 冲突怎么解决

和HashMap的最大的不同在于，ThreadLocalMap结构非常简单，没有 next 引用，也就是说ThreadLocalMap中解决 Hash 冲突的方式并非链表的方式，而是采用线性探测的方式，所谓线性探测，就是根据初始 key 的 hashcode 值确定元素在 table 数组中的位置，如果发现这个位置上已经有其他 key 值的元素被占用，则利用固定的算法寻找一定步长的下个位置，依次判断，直至找到能够存放的位置。

ThreadLocalMap解决 Hash 冲突的方式就是简单的步长加 1 或减 1，寻找下一个相邻的位置。

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {  
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {  
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

显然ThreadLocalMap采用线性探测的方式解决Hash冲突的效率很低，如果有大量不同的ThreadLocal对象放入map中时发送冲突，或者发生二次冲突，则效率很低。

所以建议：每个线程只存一个ThreadLocal变量，这样的话所有的线程存放到 map 中的 Key 都是相同的ThreadLocal，如果一个线程要保存多个变量，就需要创建多个ThreadLocal，多个ThreadLocal放入 Map 中时会极大的增加Hash冲突的可能。

3.5 ThreadLocalMap 弱引用问题

Entry继承自WeakReference（3.3 讲述过），这就导致了一个问题：ThreadLocal在没有外部对象强引用时，发生 GC 时弱引用 Key 会被回收，而 Value 不会回收，如果创建ThreadLocal的线程一直持续运行，但是 ThreadLocal 已经被回收，那么这个 Entry 对象中的 value 就有可能一直得不到回收（线程中存在ThreadLocalMap<null, Object>的键值对），发生内存泄露。（ThreadLocal被回收，ThreadLocal关联的线程共享变量还存在）。

JVM团队已经考虑到这样的情况，并做了一些措施来保证ThreadLocal尽量不会内存泄漏：在ThreadLocal的get()、set()、remove()方法调用的时候会清除掉线程ThreadLocalMap中所有 Entry 中 Key 为 null 的 Value，并将整个 Entry 设置为 null，利于下次内存回收。

但这样也并不能保证ThreadLocal不会发生内存泄漏，例如：

  • 使用 static 的 ThreadLocal，延长了 ThreadLocal 的生命周期，可能导致的内存泄漏。
  • 虽然ThreadLocal的get，set方法可以清除ThreadLocalMap中key为null的value，但是get，set方法在内存泄露后并不会必然调用。

所以为了防止此类情况的出现，我们有两种手段：

  • 1.使用完线程共享变量后，显式调用ThreadLocalMap.remove方法清除线程共享变量；
  • 2.JDK建议ThreadLocal定义为private static，这样ThreadLocal的弱引用问题则不存在了（我并不确定）。

3.6 为什么使用弱引用？

从表面上看，发生内存泄漏，是因为 Key 使用了弱引用类型。但其实是因为整个 Entry 的 key 为 null 后，没有主动清除 value 导致。很多文章大多分析 ThreadLocal 使用了弱引用会导致内存泄漏，但为什么使用弱引用而不是强引用？

官方说法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
为了处理非常大和生命周期非常长的线程，哈希表使用弱引用作为 key。

分析一下：

  • 假如key 使用强引用：引用的 ThreadLocal 的对象被回收了，但是 ThreadLocalMap 还持有 ThreadLocal 的强引用，如果没有手动删除，ThreadLocal 不会被回收，导致 Entry 内存泄漏。
  • 假如key 使用弱引用：引用的 ThreadLocal 的对象被回收了，由于 ThreadLocalMap 持有 ThreadLocal 的弱引用，即使没有手动删除，ThreadLocal 也会被回收。value 在下一次 ThreadLocalMap调用set,get，remove的时候会被清除。

比较两种情况，我们可以发现：由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果都没有手动删除对应 key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的 value 在下一次 ThreadLocalMap 调用 set,get,remove 的时候会被清除。

因此，ThreadLocal内存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果没有手动删除对应 key 的 value 就会导致内存泄漏，而不是因为弱引用。

在使用线程池的情况下，没有及时清理 ThreadLocal，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用 ThreadLocal 就跟加锁完要解锁一样，用完就清理。

4.使用示例

public class Run {  
    private static ThreadLocal tl = new ThreadLocal();

    public static void main(String[] args) {
        if (tl.get() == null) {
            System.out.println("从未放过值");
            tl.set("我的值");
        }
        System.out.println(tl.get());
        System.out.println(tl.get());
    }

}

5.Java开发手册（阿里巴巴）对ThreadLocal的要求

【参考】 ThreadLocal 对象使用 static 修饰，ThreadLocal 无法解决共享对象的更新问题。

说明：这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。

必须回收自定义的 ThreadLocal 变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的ThreadLocal 变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量在代理中使用 try-finally 块进行回收。

可参考：
ThreadLocal-面试必问深度解析
ThreadLocal内存泄漏真因探究

Q.E.D.

Think Big, Act Small