存储结构
threadLocal存储于Thread类上的ThreadLocalMap类型的threadLocals中。
从ThreadLocalMap的名字上可以看出其结构类似于HashMap,它也是使用key-value结构的Entry数组table来存储ThreadLocal和值。
但区别在于Entry继承于WeakReference,key使用弱引用,其好处在于当threadlocal没有强引用时,key将在下一次gc中被回收,但仅仅key被回收,value不会被回收,这就是ThreadLocal会导致内存泄漏的原因,但ThreadLocal也有一些机制去处理这种情况,后续会说。
还有一种区别在于解决hash冲突的方式,HashMap是使用数组+链表,即拉链法来解决的,而ThreadLocalMap使用线性探测法,即当前位置冲突,探测下一个地址是否冲突,不冲突插入。
set过程
首先是获取thread上的ThreadLocalMap
public void set(T value) {
//1.获取当前线程
Thread t = Thread.currentThread();
//2.获取线程上的ThreadLocalMap
ThreadLocalMap map = getMap(t);
if (map != null)
//3.1.存在调用ThreadLocalMap的set方法
map.set(this, value);
else
//3.2.不存在初始化ThreadLocalMap
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
获取到ThreadLocalMap之后,将threadlocal和value封装为Entry保存到数组中。
private void set(ThreadLocal<?> key, Object value) {
Entry[] tab = table;
int len = tab.length;
//1.通过threadlocal的threadLocalHashCode获取到存放位置
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
//2.1.当前存放位置key相等,替换值
if (k == key) {
e.value = value;
return;
}
//2.2.当前存放位置key已经被gc回收,替换当前位置的entry
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
//2.3.当前位置已存放别的threadlocal,线性探测下一个位置
}
//3.当前位置为空,存放
tab[i] = new Entry(key, value);
int sz = ++size;
//4.回收key已经gc的entry,然后判断是否扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
我们看下threadLocalHashCode的获取。
private final int threadLocalHashCode = nextHashCode();
private static AtomicInteger nextHashCode =
new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
每次实例化ThreadLocal的时候都会从nextHashCode获取,而每次获取都会加上`0x61c88647,HASH_INCREMENT的注释是比起连续的自增序列能使threadlocal在ThreadLocalMap分布更加均匀。
for (int i = 0; i < 16; i++) {
System.out.println(0x61c88647 * i & 15);
}
运行这段代码,我们确实可以发现16个值随机均匀的分布在0-15之间,正好符合threadlocalMap上面的16个entry大小数组。
我们知道threadLocalMap在到达threshold的时候会发生扩容,这时ThreadLocal会进行rehash重新存放,我们将上面的i改为32会发现还是均匀的分布在0-32之间,那么一直不会发生hash冲突。那么到底什么时候会发生hash冲突?
前面我们提到Entry的key为弱引用,在没有强引用下,下次gc将会回收,在set方法中我们可以看replaceStaleEntry和cleanSomeSlots方法,这里就是回收key被回收后的Entry节点。
我们先说回hash冲突,假设在size达到threshold之前,有些key已经被回收,那么在新建了16个threadlocal之后,将出现一个再次填充到第一个threadlocal位置的threadlocal,这时就会导致hash冲突。
我们假设ThreadLocalMap大小为4,阈值为4,如下图所示:
ThreadLocalMap填入ThreadLocal4时,ThreadLocal2、ThreadLocal3已经没有强引用触发gc,那么Entry2、Entry3的key将会为null。
这时将会触发cleanSomeSlots,回收Entry2、Entry3。
这时我们才填入ThreadLocal5,这时就会和Entry1发生hash冲突,探测下一个位置填入。
以上就是整个set过程中hash冲突发生的情况和ThreadLocalMap如何处理的过程。
下面我们再看下replaceStaleEntry和cleanSomeSlots如何回收Entry的。
我们追踪replaceStaleEntry和cleanSomeSlots会发现其都调用expungeStaleEntry方法。
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
//释放当前位置的过期Entry
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
Entry e;
int i;
//从当前位置开始探测下一个,如果已经过期则清除,如果未过期重新rehash插入。
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
//已经gc清除Entry
e.value = null;
tab[i] = null;
size--;
} else {
//Threadlocal还没被gc,进行rehash
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;
}
这个清除过期Entry的逻辑,我们可以看到在get和remove等方法中进行了调用,这也是ThreadLocal解决内存泄漏的机制。
总结
- ThreadLocal使用类似HashMap的结构进行存储,区别在于其key使用弱引用,还有解决hash冲突使用线性探测法。
- ThreadLocal发生hash冲突的情况,只在ThreadLocalMap达到阈值之前已经发生弱引用被gc的情况下,否则ThreadLocalMap只会进行扩容,极少发生hash冲突。
- ThreadLocal解决因为弱引用被gc导致Entry节点还存在的内存泄漏,使用在set、get、remove等方法中进行回收弱引用被gc的Entry节点。因此唯一存在内存泄漏的情况是在弱引用被gc之后从未调过set、get、remove等方法,对此阿里规范中要求,对不在使用ThreadLocal要调用remove方法。
子线程继承父线程的ThreadLocal——InheritableThreadLocal
InheritableThreadLocal会让子线程拥有父线程的InheritableThreadLocal,其原理就在于Thread在创建的时候会获取当前线程的inheritableThreadLocals,然后使用创建自己的inheritableThreadLocals会将当前的inheritableThreadLocals复制。
Netty对ThreadLocal的优化——FastThreadLocal
存储结构
FastThreadLocal对应的map为InternalThreadLocalMap,他抛弃了ThreadLocalMap的结构,使用Object数组进行存储。
其中头部存放的是Set集合的FastThreadLocal,而其他部分存放的是FastThreadLocal的值。FastThreadLocal上有一个index变量存放其值在Object数组中的位置。
而FastThreadLocal index的值是全局自增的。
优化点
set仅仅只需要将FastThreadLocal的值存放到Object上对应的位置,同时将FastThreadLocal存放到Object头部的set集合中
get操作也只需要拿到FastThreadLocal的index,去object上获取值
remove操作也只需要拿到FastThreadLocal的index,将object对应的值置为unset,同时从object头部的set集合移除FastThreadLocal。
这样一来不需要处理hash冲突和清除过期的节点,但由于index是一直自增的,会导致Object上无效的位置无法重复使用,Object一直增大,相当于用空间换时间。
还有FastThreadLocal的内存泄漏问题解决在于同样需要手动调用FastThreadLocal的remove方法,当Netty提供更方便的操作,使用FastThreadLocalRunnable对Runnable进行封装,其在run方法中调用FastThreadLocal的removeAll方法进行清除。
ThreadLocal在线程池中使用的问题
ThreadLocal销毁问题
由于线程池中的线程在使用完,不会进行销毁,只是重新放入线程池中,如果线程在使用完不对ThreadLocal进行remove,那么这会导致下次使用这个线程时获取到上次使用的ThreadLocal。
Spring中大量使用ThreadLocal,例如RequestContextHolder使用THreadLocal存放Request和Respons,Spring对它处理就是使用RequestContextFilter在逻辑处理完成之后调用remove方法。
ThreadLocal传输问题
如果ThreadLocal要在线程池中传输,我想到的是对Runnable进行包装,在创建的时候拷贝一份ThreadLocal的值,在run方法中重新设置回去ThreadLocal中。
阿里的TransmittableThreadLocal对其的处理就是如此做的。
ThreadLocal在Hystrix中传输问题
Hystrix的处理有两种,一种线程池,一种信号量。
ThreadLocal在Hystrix中传输问题也就是线程池中传输的问题,安照上面的解决方案,我们也只需要对Runnable和Callable进行封装。
Hystrix提供HystrixPlugin让我们定制化自己的HystrixConcurrencyStrategy,HystrixConcurrencyStrategy提供对Callable进行包装的方法wrapCallable,那么我们只需要在这里对Callable进行包装即可。