ThreadLocal，可以理解为线程局部变量。同一份变量在每一个线程中都保存一份副本，线程对该副本的操作对其他线程完全是不可见的，是封闭的。
一、ThreadLocal简单示例
public class Main {
private static ThreadLocal<Integer> tl = new ThreadLocal<>();
public static void main(String[] args) {
tl.set(1);
Thread t = new Thread(() -> {
tl.set(2);
System.out.println("子线程:" + tl.get());
});
t.start();
System.out.println("主线程:" + tl.get());
}
}
最终的输出如下：
可以看出，各个线程内的ThreadLocal互不干扰，每个线程也只能访问自己独有的ThreadLocal变量。
那么ThreadLocal的结构是怎么样的呢？
二、ThreadLocal的结构
Thread、ThreadLocal与ThreadLocalMap的关系图如下：
从上面的结构图我们可以看出：
（1）每个Thread内部都有一个ThreadLocalMap，可以理解为简单版的HashMap。
（2）map的key是ThreadLocal类型的，而value的类型则是ThreadLocal的泛型类型。在本例中，value是Intege类型的。
在我刚学ThreadLocal的时候，我觉得他应该是这样设计的：
ThreadLocal里面有一个map容器，key是线程id或线程名称，value是副本的值，简单又好理解。那为什么jdk不这样设计呢（当然早期就是这样设计的）？
在jdk8中，map被放入到了Thread中，ThreadLocal更像是一个工具类。
那么，jdk8这样设计的好处是什么呢？
（1）如果map被放到ThreadLocal中，那么map的大小取决于线程数量。当线程数特别多的时候，势必会影响到map的查找、插入与扩容的效率。而在jdk8中，map的大小取决于ThreadLocal的数量，这个数量是可控的，一般不可能声明出那么多的ThreadLocal。
（2）在早期的设计中，当线程消亡时，需要在每一个关联的ThreadLocal的map中做一些清理工作，比较麻烦。而在jdk8中，线程消亡时，内部的map容器也随之消亡。
三、ThreadLocal有哪些方法
先从比较简单的set与get方法说起
有关ThreadLocalMap的方法，我们将会在下个章节进行梳理。
set方法
public void set(T value) {
//获取当前的操作线程
Thread t = Thread.currentThread();
//获取线程内部的ThreadLocalMap
ThreadLocalMap map = getMap(t);
if (map != null)
//如果map不为空，则直接将（k:当前ThreadLocal实例，v:副本值）放入进map中
map.set(this, value);
else
//如果map为空，则创建该线程的ThreadLocalMap,并将（k,v）放入进map中
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
可以看到，Thread内部的ThreadLocalMap是懒加载的，只有在第一次使用的时候，才会创建map。
get方法
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
//如果map不为空，则获取键为该ThreadLocal对象的Entry实例
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
private T setInitialValue() {
//获取初始值，默认是null
T value = initialValue();
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
return value;
}
protected T initialValue() {
return null;
}
看的出，get方法同样会触发map的初始化。
remove方法
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
//最终还是调用ThreadLocalMap的方法，移除key为当前ThreadLocal的Entry
m.remove(this);
}
好家伙，ThreadLocal工具人的身份石锤了。
核心的代码都在ThreadLocalMap中，他是ThreadLocal内的一个静态内部类。
四、ThreadLocalMap探究
ThreadLocalMap的结构
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
ThreadLocalMap没有直接使用HashMap，而是一个经过定制化的map。map中的每一项都是一个Entry，key是对ThreadLocal的一个弱引用（这个后面会再解释）。
成员变量
//初始容量，必须是2的整数次方
private static final int INITIAL_CAPACITY = 16;
//Entry数组。其长度也必须是2的整数次方
private Entry[] table;
//数组中不为null的Entry个数
private int size = 0;
//扩容阈值，当size≥threshold时，就会发生扩容。默认为0，会在构造方法中重新设置
private int threshold;
基本方法
//设置扩容阈值为表长度的2/3
private void setThreshold(int len) {
threshold = len * 2 / 3;
}
//下一个索引，当索引为len-1时，下一个索引为0
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
//上一个索引，当索引为0时，上一个索引为len-1
private static int prevIndex(int i, int len) {
return ((i - 1 >= 0) ? i - 1 : len - 1);
}
ThreadLocalMap不同于HashMap，HashMap使用链地址法解决冲突，而ThreadLocalMap使用线性探测法。即当前下标存在冲突时，检查下一个下标是否存在冲突，你可以把数组看成一个环。
构造方法
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
//初始化一个容量为16的table
table = new Entry[INITIAL_CAPACITY];
//计算当前ThreadLocal的下标
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
//设置扩容阈值为16的2/3,即10
setThreshold(INITIAL_CAPACITY);
}
在计算ThreadLocal的下标的时候，用到了
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1)
生成哈希值的时候，用到了以下代码：
private final int threadLocalHashCode = nextHashCode();
//使用AtomicInteger类型是保证加法的原子操作
private static AtomicInteger nextHashCode =
new AtomicInteger();
//该魔数使得在该table上散列均匀，这里不细究其原理
private static final int HASH_INCREMENT = 0x61c88647;
//返回下一个哈希值，仅仅是在当前值的基础上再加上魔数
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
在计算下标的时候，使用到了& (INITIAL_CAPACITY - 1)，这里和HashMap是一样的算法（有关HashMap的连环问，可以参考我的这篇文章HashMap夺命连环问）。
前面说过，Entry数组的容量必须是2的整数次方，那么在这样的前提下，hashCode%len是和hashCode&(len-1)相等的，而位运算更加的快速。
例如len=16，len-1的二进制为01111，即将最高位变为0，小于16的部分全为1。那么hashCode&(len-1)之后，hashCode中≥16的位全部被与为0，小于16的被保留了下来，从而达到对容量取余相同的效果。
getEntry方法
这个就是ThreadLocal.get方法调用的底层逻辑
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;
//只要Entry不为null，就一直寻找。如果为null，说明真的找不到了
while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
//key为null，说明ThreadLocal已经被回收，那么回收其value
expungeStaleEntry(i);
else
//寻找i的下一个下标
i = nextIndex(i, len);
//将e设置为下一个Entry
e = tab[i];
}
return null;
}
expungeStaleEntry方法
即清理那些key为null的Entry
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
//断开对value的强引用
tab[staleSlot].value = null;
//断开对Entry的强引用
tab[staleSlot] = null;
size--;
Entry e;
int i;
//从staleSlot的下一个位置开始，直到遇到为null的Entry结束
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
//断开对value与Entry的强引用
e.value = null;
tab[i] = null;
size--;
} else {
//如果当前的Entry不为null，则进行重新散列
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
//如果重新散列后，位置发生变动
tab[i] = null;
//一直找到一个空位置
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
expungeStaleEntry方法有两个作用：
（1）从staleSlot位置开始，在遇到空Entry之前，清理当前位置的Entry
（2）如果当前Entry不为空，则进行重新散列。重新散列后的位置不为空Entry的话，则选择下一个下标。
明明清理空Entry就行了，为什么需要对非空Entry还要再做一次重新散列呢？
是为了下一次get的时候，避免遇到空Entry需要执行expungeStaleEntry方法。
expungeStaleEntry方法可以理解为清理某一段数组，遇到null就停下来了，并不是全量清理。
set方法
private void set(ThreadLocal<?> key, Object value) {
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) {
//替换当前失效的Entry
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
//当没清理到任何数据且size≥阈值的时候，进行扩容
rehash();
}
replaceStaleEntry与cleanSomeSlots方法，我们不继续深入了，两个方法的主要想法依然是去清理无效Entry，即key为null的Entry。
rehash方法
private void rehash() {
//该方法对于table上每一个Entry,都执行了expungeStaleEntry方法
//可以理解为整体清理
expungeStaleEntries();
//threshold - threshold / 4 =3/4*threshold
//默认的threshold =2/3*len,因此只要size>=1/2*len,即占了一半之后，就考虑扩容
//为什么不按传统的size>=threshold来考虑扩容呢？
//因为执行一次全部清理后，依然还占有一半容量，那么就说明冲突可能会趋于严重，不如早点执行扩容操作。
if (size >= threshold - threshold / 4)
resize();
}
//对每一个位置上都进行检查并清理
private void expungeStaleEntries() {
Entry[] tab = table;
int len = tab.length;
for (int j = 0; j < len; j++) {
Entry e = tab[j];
if (e != null && e.get() == null)
expungeStaleEntry(j);
}
}
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
//扩容为原来的两倍
int newLen = oldLen * 2;
Entry[] newTab = new Entry[newLen];
int count = 0;
//将旧位置的Entry重新计算下标放入新table中
for (int j = 0; j < oldLen; ++j) {
Entry e = oldTab[j];
if (e != null) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null; // Help the GC
} else {
int h = k.threadLocalHashCode & (newLen - 1);
while (newTab[h] != null)
h = nextIndex(h, newLen);
newTab[h] = e;
count++;
}
}
}
setThreshold(newLen);
size = count;
table = newTab;
}
可以看得出来，在ThreadLocal的get与set方法中，都会去检查Entry的key是否为null，如果为null的话，会进行一些局部的清理工作。
当需要进行扩容时，会进行一次整体清理。
五、InheritableThreadLocal是什么鬼
ThreadLocal是用于线程之间隔离的，但是InheritableThreadLocal可以使得子线程去自动拷贝来自父线程的副本数据。
简单的例子：
public static void main(String[] args) {
InheritableThreadLocal<Integer> threadLocal = new InheritableThreadLocal<>();
threadLocal.set(1);
System.out.println("父线程的副本值:" + threadLocal.get());
new Thread(() -> System.out.println("子线程的副本值:" + threadLocal.get())).start();
}
两个线程的副本值都是1，说明子线程确实自动拷贝了父线程的副本值。
原理很简单：
InheritableThreadLocal继承了ThreadLocal，
重写了childValue方法，直接返回了传入参数值。因为InheritableThreadLocal默认不对原值进行转换，如果我们需要对原值进行转换的话，可以重写该方法。
重写了getMap方法，返回当前线程的inheritableThreadLocals，也是ThreadLocalMap类型。createMap则是懒加载该inheritableThreadLocals。
protected T childValue(T parentValue) {
return parentValue;
}
ThreadLocalMap getMap(Thread t) {
return t.inheritableThreadLocals;
}
void createMap(Thread t, T firstValue) {
t.inheritableThreadLocals = new ThreadLocalMap(this, firstValue);
}
说白了，当前的副本不在threadLocals存了，而是存在了inheritableThreadLocals中。
接着看Thread的构造方法：
public Thread(Runnable target) {
init(null, target, "Thread-" + nextThreadNum(), 0);
}
private void init(ThreadGroup g, Runnable target, String name,
long stackSize) {
init(g, target, name, stackSize, null, true);
}
private void init(ThreadGroup g, Runnable target, String name,
long stackSize, AccessControlContext acc,
boolean inheritThreadLocals) {
if (name == null) {
throw new NullPointerException("name cannot be null");
}
this.name = name;
Thread parent = currentThread();
...省略无关代码
//inheritThreadLocals为true，父线程的inheritableThreadLocals也不为空
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
//则利用父线程的inheritableThreadLocals去创建子线程的inheritableThreadLocals
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
/* Stash the specified stack size in case the VM cares */
this.stackSize = stackSize;
/* Set thread ID */
tid = nextThreadID();
}
接着进入createInheritedMap方法：
static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
return new ThreadLocalMap(parentMap);
}
private ThreadLocalMap(ThreadLocalMap parentMap) {
Entry[] parentTable = parentMap.table;
int len = parentTable.length;
setThreshold(len);
table = new Entry[len];
//将parentTable上key不为null的Entry复制到当前table上
for (int j = 0; j < len; j++) {
Entry e = parentTable[j];
if (e != null) {
@SuppressWarnings("unchecked")
ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
if (key != null) {
//key.childValue返回e.value
Object value = key.childValue(e.value);
Entry c = new Entry(key, value);
int h = key.threadLocalHashCode & (len - 1);
while (table[h] != null)
h = nextIndex(h, len);
table[h] = c;
size++;
}
}
}
}
不过需要注意的是，如果在拷贝之后，父线程再进行set的话，子线程肯定是感知不到的。
六、ThreadLocal与内存泄漏
什么是内存泄露？
大白话讲，就是我自己创建的对象，在一系列操作后，我访问不到该对象了，我认为它已经被回收掉了，但该对象却一直存在与内存中。
那什么是内存溢出呢？
内存溢出是在有限的堆内存中（当然内存溢出的区域不止这一块）申请了大量的对象，造成oom的情况。
那两者的区别呢？
内存泄露比较严重的时候会导致内存溢出，如果每次gc后，堆内存都不能下降到一个比较低的占用量，那么可以使用jmap dump堆内存，再使用MAT找出导致内存泄漏的对象。
我们以一开头的例子来画出运行时的堆栈图：
为什么这里的key保持着对ThreadLocal的一个弱引用呢？保持强引用行不行？
假设这里的key保持对ThreadLocal的强引用，则当我的程序用不到该ThreadLocal时，我手动执行了tl=null，此时1号线断开，而这里的5号线是实线，5号线没有断开，因此ThreadLocal对象无法被回收掉，一直存在于内存中，造成内存泄露。
看来，这里的弱引用，能够保证用不到的ThreadLocal被回收掉。
弱引用就能完全防止内存泄露了吗？
由上面的分析，弱引用能够防止释放不掉ThreadLocal引起的内存泄露。但是，却不能防止释放不掉Integer引起的内存泄露。首先，执行tl=null，则1号线断开，GC到来时，5号线断开，此时ThreadLocal被回收掉了，这个key被置为了null，可是这个key对应的value强引用着Integer对象，该Integer无法在用户代码中访问到了，但却依然存在于内存中，造成内存泄露。
既然依然存在着内存泄露，那么JDK团队是怎么解决的呢？
从上文的源码分析来看，ThreadLocal中的get()、set()方法，不是单纯地去做获取、设置的操作。在它们的方法内部，依然会遍历该Entry数组，删除所有key为null的Entry，并将相关的value置为null，从而够解决因释放不掉value而引起的内存泄露。
有这些get()、set()方法，就能完全地防止内存泄漏吗？
但我们手动将tl置为null后，就已经没法调用这些get()、set()方法了。所以，预防内存泄露的最佳实践是，在使用完ThreadLocal后，先调用tl.remove()，再调用tl=null。tl.remove()能够使得ThreadLocalMap删除该ThreadLocal所在的Entry，以及将value置为null，tl=null使得ThreadLocal对象真正地被回收掉。
其实内存泄露的问题，核心在于ThreadLocal与Thread的生命周期不一致。
有两种情况：
（1）ThreadLocal的生命周期长于Thread，此时的Thread销毁后，内部的ThreadLocalMap也逐渐销毁，这种情况是不会发生内存泄露的。
（2）在线程池相关的场景下，ThreadLocal的生命周期是明显短于Thread的。当ThreadLocal被置为null，而又没在其之前调用remove时，内存泄露就开始了，一直持续到Thread销毁。
还有哪些内存泄露的场景呢？怎么去解决呢？
【1】长生命周期的对象持有短生命周期对象的引用，就很有可能造成内存泄露。
长生命周期的对象往往和整个程序的生命周期相同，若是当它们持有短生命周期的对象的引用，尽管短对象不再被使用，也无法被垃圾回收器回收，因为垃圾回收器无法回收被强引用所关联的对象。
解决方案：
（1）像一些静态的集合类，它们的生命周期和整个程序相同，尽管放入集合中的元素不再需要，就算将元素强行置为null，但由于集合类持有它们的引用，这些元素占据的空间也得不到释放，那么在必要的时候，我们可以将集合类对象类型的变量置为null。
（2）单例模式中，单例与整个程序的生命周期一致，如果单例对象持有其他短对象的引用，也很容易造成内存泄露，这还得靠我们谨慎编码。
（3）又或是数据库连接对象（长生命周期），ResultSet与Statement对象（短生命周期），连接不再被使用时，需要调用其close（）方法，释放长对象与短对象。同理，需要显式调用close（）方法的长生命周期的对象还有Socket、IO流、Session等。
【2】非静态的外部类会隐式地持有外部类的一个强引用
在Android中，如果在Activity内声明一个非静态的内部类，那么只要该内部类没有被回收的话，那么外部类Activity就无法被回收，Activity所关联的视图和资源也不会被回收，这样的内存泄露比较严重。
解决方案：
（1）将非静态内部类改为静态内部类，静态内部类是属于类的，因此不会依赖于外部类的实例，从而不持有外部类实例的引用。
（2）显式地声明非静态内部类持有外部类的一个弱引用，被弱引用关联的对象，在下一次垃圾回收器活动时，就会被回收。
七、ThreadLocal的使用场景
ThreadLocal一个典型的场景就是，我们需要在某个线程内保存全局可流通的属性，避免参数传递的麻烦。
大可以使用拦截器，将请求的token信息解析成用户属性，放在ThreadLocal中，之后在该线程执行的任何地方都可以获取到用户属性。
不会真有人在不知道ThreadLocal的时候，一直把HttpServletRequest当作方法的常用参数吧？不会吧不会吧
当然，线程池以及异步程序中是不建议使用ThreadLocal的，你永远不知道你拿到的副本到底是哪个Thread的遗产。
此外，java8中的并行流也不是不建议使用ThreadLocal的，有关对并行流的介绍，可以移步我的另外一篇文章谈谈并行流parallelStream
