公众号后台回复“面试”,获取精品学习资料

扫描下方海报了解专栏详情

本文来源公众号投稿:壹枝花算不算浪漫
《Java工程师面试突击(第3季)》重磅升级,由原来的70讲增至160讲,内容扩充一倍多,升级部分内容请参见文末
首先贴出一张图:

前几天写了一篇AQS
相关的文章:我画了35张图就是为了让你深入 AQS,反响不错,还上了博客园首页编辑推荐,有生之年系列呀,哈哈。

这次趁热打铁再写一篇ThreadLocal
的文章,同样是深入原理,图文并茂。
全文共10000+字,31张图,这篇文章同样耗费了不少的时间和精力才创作完成,原创不易,请大家多多关注我的公众号壹枝花算不算浪漫,感谢。
对于ThreadLocal
,大家的第一反应可能是很简单呀,线程的变量副本,每个线程隔离。那这里有几个问题大家可以思考一下:
ThreadLocal的key是弱引用,那么在 threadLocal.get()的时候,发生GC之后,key是否为null?
ThreadLocal中ThreadLocalMap的数据结构?
ThreadLocalMap的Hash算法?
ThreadLocalMap中Hash冲突如何解决?
ThreadLocalMap扩容机制?
ThreadLocalMap中过期key的清理机制?探测式清理和启发式清理流程?
ThreadLocalMap.set()方法实现原理?
ThreadLocalMap.get()方法实现原理?
项目中ThreadLocal使用情况?遇到的坑?
……
上述的一些问题你是否都已经掌握的很清楚了呢?本文将围绕这些问题使用图文方式来剖析ThreadLocal
的点点滴滴。
全文目录
ThreadLocal代码演示
ThreadLocal的数据结构
GC 之后key是否为null?
ThreadLocal.set()方法源码详解
ThreadLocalMap Hash算法
ThreadLocalMap Hash冲突
ThreadLocalMap.set()详解
7.1 ThreadLocalMap.set()原理图解
7.2 ThreadLocalMap.set()源码详解ThreadLocalMap过期key的探测式清理流程
ThreadLocalMap扩容机制
ThreadLocalMap.get()详解
10.1 ThreadLocalMap.get()图解
10.2 ThreadLocalMap.get()源码详解ThreadLocalMap过期key的启发式清理流程
InheritableThreadLocal
ThreadLocal项目中使用实战
13.1 ThreadLocal使用场景
13.2 分布式TraceId解决方案
注明: 本文源码基于JDK 1.8
ThreadLocal代码演示
我们先看下ThreadLocal
使用示例:
public class ThreadLocalTest {
private List<String> messages = Lists.newArrayList();
public static final ThreadLocal<ThreadLocalTest> holder = ThreadLocal.withInitial(ThreadLocalTest::new);
public static void add(String message) {
holder.get().messages.add(message);
}
public static List<String> clear() {
List<String> messages = holder.get().messages;
holder.remove();
System.out.println("size: " + holder.get().messages.size());
return messages;
}
public static void main(String[] args) {
ThreadLocalTest.add("一枝花算不算浪漫");
System.out.println(holder.get().messages);
ThreadLocalTest.clear();
}
}
打印结果:
[一枝花算不算浪漫]
size: 0
ThreadLocal
对象可以提供线程局部变量,每个线程Thread
拥有一份自己的副本变量,多个线程互不干扰。
ThreadLocal的数据结构

Thread类有一个类型为
ThreadLocal.ThreadLocalMap的实例变量
threadLocals,也就是说每个线程有一个自己的
ThreadLocalMap。
ThreadLocalMap有自己的独立实现,可以简单地将它的
key视作
ThreadLocal,
value为代码中放入的值(实际上
key并不是
ThreadLocal本身,而是它的一个弱引用)。
ThreadLocal里放值的时候,都会往自己的
ThreadLocalMap里存,读也是以
ThreadLocal作为引用,在自己的
map里找对应的
key,从而实现了线程隔离。
ThreadLocalMap有点类似
HashMap的结构,只是
HashMap是由数组+链表实现的,而
ThreadLocalMap中并没有链表结构。
Entry, 它的
key是
ThreadLocal<?> k,继承自
WeakReference, 也就是我们常说的弱引用类型。
GC 之后key是否为null?
ThreadLocal的
key是弱引用,那么在
threadLocal.get()的时候,发生
GC之后,
key是否是
null?
Java的四种引用类型:
强引用:我们常常new出来的对象就是强引用类型,只要强引用存在,垃圾回收器将永远不会回收被引用的对象,哪怕内存不足的时候 软引用:使用SoftReference修饰的对象被称为软引用,软引用指向的对象在内存要溢出的时候被回收 弱引用:使用WeakReference修饰的对象被称为弱引用,只要发生垃圾回收,若这个对象只被弱引用指向,那么就会被回收 虚引用:虚引用是最弱的引用,在 Java 中使用 PhantomReference 进行定义。虚引用中唯一的作用就是用队列接收对象即将死亡的通知
GC后
ThreadLocal中的数据情况:
public class ThreadLocalDemo {
public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException, InterruptedException {
Thread t = new Thread(()->test("abc",false));
t.start();
t.join();
System.out.println("--gc后--");
Thread t2 = new Thread(() -> test("def", true));
t2.start();
t2.join();
}
private static void test(String s,boolean isGC) {
try {
new ThreadLocal<>().set(s);
if (isGC) {
System.gc();
}
Thread t = Thread.currentThread();
Class<? extends Thread> clz = t.getClass();
Field field = clz.getDeclaredField("threadLocals");
field.setAccessible(true);
Object threadLocalMap = field.get(t);
Class<?> tlmClass = threadLocalMap.getClass();
Field tableField = tlmClass.getDeclaredField("table");
tableField.setAccessible(true);
Object[] arr = (Object[]) tableField.get(threadLocalMap);
for (Object o : arr) {
if (o != null) {
Class<?> entryClass = o.getClass();
Field valueField = entryClass.getDeclaredField("value");
Field referenceField = entryClass.getSuperclass().getSuperclass().getDeclaredField("referent");
valueField.setAccessible(true);
referenceField.setAccessible(true);
System.out.println(String.format("弱引用key:%s,值:%s", referenceField.get(o), valueField.get(o)));
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
结果如下:
弱引用key:java.lang.ThreadLocal@433619b6,值:abc
弱引用key:java.lang.ThreadLocal@418a15e3,值:java.lang.ref.SoftReference@bf97a12
--gc后--
弱引用key:null,值:def

ThreadLocal并没有指向任何值,也就是没有任何引用:
new ThreadLocal<>().set(s);
GC之后,
key就会被回收,我们看到上面
debug中的
referent=null, 如果改动一下代码:

null。
threadlocal.get()操作,证明其实还是有强引用存在的,所以
key并不为
null,如下图所示,
ThreadLocal的强引用仍然是存在的。

key就会被回收,也就是会出现我们
value没被回收,
key被回收,导致
value永远存在,出现内存泄漏。
ThreadLocal.set()方法源码详解

ThreadLocal中的
set方法原理如上图所示,很简单,主要是判断
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);
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
ThreadLocalMap中的,一步步往下看,后面还有更详细的剖析。
ThreadLocalMap Hash算法
Map结构,那么
ThreadLocalMap当然也要实现自己的
hash算法来解决散列表数组冲突问题。
int i = key.threadLocalHashCode & (len-1);
ThreadLocalMap中
hash算法很简单,这里
i就是当前key在散列表中对应的数组下标位置。
threadLocalHashCode值的计算,
ThreadLocal中有一个属性为
HASH_INCREMENT = 0x61c88647public class ThreadLocal<T> {
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);
}
static class ThreadLocalMap {
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
}
}
ThreadLocal对象,这个
ThreadLocal.nextHashCode这个值就会增长
0x61c88647。
hash增量为 这个数字,带来的好处就是
hash分布非常均匀。

ThreadLocalMap Hash冲突
注明: 下面所有示例图中,绿色块 Entry
代表正常数据,灰色块代表Entry
的key
值为null
,已被垃圾回收。白色块表示Entry
为null
。
ThreadLocalMap中使用了黄金分隔数来作为
hash计算因子,大大减少了
Hash冲突的概率,但是仍然会存在冲突。
HashMap中解决冲突的方法是在数组上构造一个链表结构,冲突的数据挂载到链表上,如果链表长度超过一定数量则会转化成红黑树。
ThreadLocalMap中并没有链表结构,所以这里不能适用
HashMap解决冲突的方式了。

value=27的数据,通过
hash计算后应该落入第4个槽位中,而槽位4已经有了
Entry数据。
Entry为
null的槽位才会停止查找,将当前元素放入此槽位中。当然迭代过程中还有其他的情况,比如遇到了
Entry不为
null且
key值相等的情况,还有
Entry中的
key值为
null的情况等等都会有不同的处理,后面会一一详细讲解。
Entry中的
key为
null的数据(Entry=2的灰色块数据),因为
key值是弱引用类型,所以会有这种数据存在。在
set过程中,如果遇到了
key过期的
Entry数据,实际上是会进行一轮探测式清理操作的,具体操作方式后面会讲到。
ThreadLocalMap.set()详解
ThreadLocalMap.set()原理图解
ThreadLocalhash算法后,我们再来看
set是如何实现的。
ThreadLocalMap中
set数据(新增或者更新数据)分为好几种情况,针对不同的情况我们画图来说说明。
hash计算后的槽位对应的
Entry数据为空:

key值与当前
ThreadLocal通过
hash计算获取的
key值一致:

Entry为
null的槽位之前,没有遇到
key过期的
Entry:

Entry为
null的槽位,则将数据放入该槽位中,或者往后遍历过程中,遇到了key值相等的数据,直接更新即可。
Entry为
null的槽位之前,遇到
key过期的
Entry,如下图,往后遍历过程中,一到了
index=7的槽位数据
Entry的
key=null:

Entry数据
key为
null,表明此数据
key值已经被垃圾回收掉了,此时就会执行
replaceStaleEntry()方法,该方法含义是替换过期数据的逻辑,以index=7位起点开始遍历,进行探测式数据清理工作。
slotToExpunge = staleSlot = 7staleSlot开始 向前迭代查找,找其他过期的数据,然后更新过期数据起始扫描下标
slotToExpunge。
for循环迭代,直到碰到
Entry为
null结束。
Entry=null的槽位才停止迭代,如下图所示,slotToExpunge被更新为0:

index=7)向前迭代,检测是否有过期的
Entry数据,如果有则更新
slotToExpunge值。碰到
null则结束探测。以上图为例
slotToExpunge被更新为0。
slotToExpunge的值,这个值在后面会讲解,它是用来判断当前过期槽位
staleSlot之前是否还有过期元素。
staleSlot位置(index=7)向后迭代,如果找到了相同key值的Entry数据:

staleSlot向后查找
key值相等的
Entry元素,找到后更新
Entry的值并交换
staleSlot元素的位置(
staleSlot位置为过期元素),更新
Entry数据,然后开始进行过期
Entry的清理工作,如下图所示:


staleSlot向后查找
key值相等的
Entry元素,直到
Entry为
null则停止寻找。通过上图可知,此时
table中没有
key值相同的
Entry。
Entry,替换
table[stableSlot]位置:

expungeStaleEntry()和
cleanSomeSlots(),具体细节后面会讲到,请继续往后看。
ThreadLocalMap.set()源码详解
上面已经用图的方式解析了set()
实现的原理,其实已经很清晰了,我们接着再看下源码:
java.lang.ThreadLocal.ThreadLocalMap.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) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
key来计算在散列表中的对应位置,然后以当前
key对应的桶的位置向后查找,找到可以使用的桶。
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
k = key
说明是替换操作,可以使用碰到一个过期的桶,执行替换逻辑,占用过期桶 查找过程中,碰到桶中 Entry=null
的情况,直接使用
for循环遍历,向后查找,我们先看下
nextIndex()、
prevIndex()方法实现:

private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
private static int prevIndex(int i, int len) {
return ((i - 1 >= 0) ? i - 1 : len - 1);
}
for循环中的逻辑:
遍历当前 key
值对应的桶中Entry
数据为空,这说明散列数组这里没有数据冲突,跳出for
循环,直接set
数据到对应的桶中如果 key
值对应的桶中Entry
数据不为空
2.1 如果k = key
,说明当前set
操作是一个替换操作,做替换逻辑,直接返回
2.2 如果key = null
,说明当前桶位置的Entry
是过期数据,执行replaceStaleEntry()
方法(核心方法),然后返回for
循环执行完毕,继续往下执行说明向后迭代的过程中遇到了entry
为null
的情况
3.1 在Entry
为null
的桶中创建一个新的Entry
对象
3.2 执行++size
操作调用 cleanSomeSlots()
做一次启发式清理工作,清理散列数组中Entry
的key
过期的数据
4.1 如果清理工作完成后,未清理到任何数据,且size
超过了阈值(数组长度的2/3),进行rehash()
操作
4.2rehash()
中会先进行一轮探测式清理,清理过期key
,清理完成后如果size >= threshold - threshold 4,就会执行真正的扩容逻辑(扩容逻辑往后看)
replaceStaleEntry()方法,
replaceStaleEntry()方法提供替换过期数据的功能,我们可以对应上面第四种情况的原理图来再回顾下,具体代码如下:
java.lang.ThreadLocal.ThreadLocalMap.replaceStaleEntry():
private void replaceStaleEntry(ThreadLocal<?> key, Object value,
int staleSlot) {
Entry[] tab = table;
int len = tab.length;
Entry e;
int slotToExpunge = staleSlot;
for (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len))
if (e.get() == null)
slotToExpunge = i;
for (int i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
if (slotToExpunge == staleSlot)
slotToExpunge = i;
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
if (k == null && slotToExpunge == staleSlot)
slotToExpunge = i;
}
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}
slotToExpunge表示开始探测式清理过期数据的开始下标,默认从当前的
staleSlot开始。以当前的
staleSlot开始,向前迭代查找,找到没有过期的数据,
for循环一直碰到
Entry为
null才会结束。如果向前找到了过期数据,更新探测清理过期数据的开始下标为i,即
slotToExpunge=ifor (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len)){
if (e.get() == null){
slotToExpunge = i;
}
}
接着开始从staleSlot
向后查找,也是碰到Entry
为null
的桶结束。
如果迭代过程中,碰到k == key,这说明这里是替换逻辑,替换新数据并且交换当前staleSlot
位置。如果slotToExpunge == staleSlot
,这说明replaceStaleEntry()
一开始向前查找过期数据时并未找到过期的Entry
数据,接着向后查找过程中也未发现过期数据,修改开始探测式清理过期数据的下标为当前循环的index,即slotToExpunge = i
。最后调用cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
进行启发式过期数据清理。
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
if (slotToExpunge == staleSlot)
slotToExpunge = i;
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
cleanSomeSlots()和
expungeStaleEntry()方法后面都会细讲,这两个是和清理相关的方法,一个是过期
key相关
Entry的启发式清理(
Heuristically scan),另一个是过期
key相关
Entry的探测式清理。
k == null说明当前遍历的
Entry是一个过期数据,
slotToExpunge == staleSlot说明,一开始的向前查找数据并未找到过期的
Entry。如果条件成立,则更新
slotToExpunge为当前位置,这个前提是前驱节点扫描时未发现过期数据。
if (k == null && slotToExpunge == staleSlot)
slotToExpunge = i;
k == key的数据,且碰到
Entry为
null的数据,则结束当前的迭代操作。此时说明这里是一个添加的逻辑,将新的数据添加到
table[staleSlot]对应的
slot中。
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
staleSlot以外,还发现了其他过期的
slot数据,就要开启清理数据的逻辑:
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
ThreadLocalMap过期key的探测式清理流程
ThreadLocalMap的两种过期
key数据清理方式:探测式清理和启发式清理。
expungeStaleEntry方法,遍历散列数组,从开始位置向后探测清理过期数据,将过期数据的
Entry设置为
null,沿途中碰到未过期的数据则将此数据
rehash后重新在
table数组中定位,如果定位的位置已经有了数据,则会将未过期的数据放到最靠近此位置的
Entry=null的桶中,使
rehash后的
Entry数据距离正确的桶的位置更近一些。操作逻辑如下:

set(27)经过hash计算后应该落到
index=4的桶中,由于
index=4桶已经有了数据,所以往后迭代最终数据放入到
index=7的桶中,放入后一段时间后
index=5中的
Entry数据
key变为了
null
set到
map中,就会触发探测式清理操作。
index=5的数据被清理掉,继续往后迭代,到
index=7的元素时,经过
rehash后发现该元素正确的
index=4,而此位置已经已经有了数据,往后查找离
index=4最近的
Entry=null的节点(刚被探测式清理掉的数据:index=5),找到后移动
index= 7的数据到
index=5中,此时桶的位置离正确的位置
index=4更近了。
key过期的数据会被清理掉,没过期的数据经过
rehash重定位后所处的桶位置理论上更接近
i= key.hashCode & (tab.len - 1)的位置。这种优化会提高整个散列表查询性能。
expungeStaleEntry()具体流程,我们还是以先原理图后源码讲解的方式来一步步梳理:

expungeStaleEntry(3)来调用此方法,如上图所示,我们可以看到
ThreadLocalMap中
table的数据情况,接着执行清理操作:

staleSlot位置的数据,
index=3位置的
Entry变成了
null。然后接着往后探测:

slot位置,目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置

private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
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;
}
staleSlot=3来做示例说明,首先是将
tab[staleSlot]槽位的数据清空,然后设置
size--接着以
staleSlot位置往后迭代,如果遇到
k==null的过期数据,也是清空该槽位数据,然后
size--ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
}
key没有过期,重新计算当前
key的下标位置是不是当前槽位下标位置,如果不是,那么说明产生了
hash冲突,此时以新计算出来正确的槽位位置往后迭代,找到最近一个可以存放
entry的位置。
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
Hash冲突的数据,经过迭代后,有过
Hash冲突数据的
Entry位置会更靠近正确位置,这样的话,查询的时候 效率才会更高。
ThreadLocalMap扩容机制
ThreadLocalMap.set()方法的最后,如果执行完启发式清理工作后,未清理到任何数据,且当前散列数组中
Entry的数量已经达到了列表的扩容阈值
(len*2/3),就开始执行
rehash()逻辑:
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
rehash()具体实现:
private void rehash() {
expungeStaleEntries();
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);
}
}
table的起始位置往后清理,上面有分析清理的详细流程。清理完成之后,
table中可能有一些
key为
null的
Entry数据被清理掉,所以此时通过判断
size >= threshold - threshold / 4也就是
size >= threshold* 3/4来决定是否扩容。
rehash()的阈值是
size >= threshold,所以当面试官套路我们
ThreadLocalMap扩容机制的时候 我们一定要说清楚这两个步骤:

resize()方法,为了方便演示,我们以
oldTab.len=8来举例:

tab的大小为
oldLen * 2,然后遍历老的散列表,重新计算
hash位置,然后放到新的
tab数组中,如果出现
hash冲突则往后寻找最近的
entry为
null的槽位,遍历完成之后,
oldTab中所有的
entry数据都已经放入到新的
tab中了。重新计算
tab下次扩容的阈值,具体代码如下:
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
int newLen = oldLen * 2;
Entry[] newTab = new Entry[newLen];
int count = 0;
for (int j = 0; j < oldLen; ++j) {
Entry e = oldTab[j];
if (e != null) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
} 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;
}
ThreadLocalMap.get()详解
set()方法的源码,其中包括
set数据、清理数据、优化数据桶的位置等操作,接着看看
get()操作的原理。
ThreadLocalMap.get()图解
key值计算出散列表中
slot位置,然后该
slot位置中的
Entry.key和查找的
key一致,则直接返回:

slot位置中的
Entry.key和要查找的
key不一致:

get(ThreadLocal1)为例,通过
hash计算后,正确的
slot位置应该是4,而
index=4的槽位已经有了数据,且
key值不等于
ThreadLocal1,所以需要继续往后迭代查找。
index=5的数据时,此时
Entry.key=null,触发一次探测式数据回收操作,执行
expungeStaleEntry()方法,执行完后,
index 5,8的数据都会被回收,而
index 6,7的数据都会前移,此时继续往后迭代,到
index = 6的时候即找到了
key值相等的
Entry数据,如下图所示:

ThreadLocalMap.get()源码详解
java.lang.ThreadLocal.ThreadLocalMap.getEntry():
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;
while (e != null) {
ThreadLocal<?> k = e.get();
if (k == key)
return e;
if (k == null)
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
ThreadLocalMap过期key的启发式清理流程
ThreadLocalMap过期可以的两种清理方式:探测式清理(expungeStaleEntry())、启发式清理(cleanSomeSlots())
Entry往后清理,遇到值为
null则结束清理,属于线性探测清理。

private boolean cleanSomeSlots(int i, int n) {
boolean removed = false;
Entry[] tab = table;
int len = tab.length;
do {
i = nextIndex(i, len);
Entry e = tab[i];
if (e != null && e.get() == null) {
n = len;
removed = true;
i = expungeStaleEntry(i);
}
} while ( (n >>>= 1) != 0);
return removed;
}
InheritableThreadLocal
ThreadLocal的时候,在异步场景下是无法给子线程共享父线程中创建的线程副本数据的。
InheritableThreadLocal类,我们来看一个例子:
public class InheritableThreadLocalDemo {
public static void main(String[] args) {
ThreadLocal<String> threadLocal = new ThreadLocal<>();
ThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
threadLocal.set("父类数据:threadLocal");
inheritableThreadLocal.set("父类数据:inheritableThreadLocal");
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("子线程获取父类threadLocal数据:" + threadLocal.get());
System.out.println("子线程获取父类inheritableThreadLocal数据:" + inheritableThreadLocal.get());
}
}).start();
}
}
子线程获取父类threadLocal数据:null
子线程获取父类inheritableThreadLocal数据:父类数据:inheritableThreadLocal
new Thread()方法来创建子线程,
Thread#init方法在
Thread的构造方法中被调用。在
init方法中拷贝父线程数据到子线程中:
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");
}
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
this.stackSize = stackSize;
tid = nextThreadID();
}
InheritableThreadLocal仍然有缺陷,一般我们做异步化处理都是使用的线程池,而
InheritableThreadLocal是在
new Thread中的
init()方法给赋值的,而线程池是线程复用的逻辑,所以这里会存在问题。
TransmittableThreadLocal组件就可以解决这个问题,这里就不再延伸,感兴趣的可自行查阅资料。
ThreadLocal项目中使用实战
ThreadLocal使用场景
ELK+Logstash,最后在
Kibana中进行展示和检索。
traceId呢?
org.slf4j.MDC来实现此功能,内部就是通过
ThreadLocal来实现的,具体实现如下:
UUID的
traceId字符串,将此字符串放入当前线程的
ThreadLocal中,在调用服务B的时候,将
traceId写入到请求的
Header中,服务B在接收请求时会先判断请求的
Header中是否有
traceId,如果存在则写入自己线程的
ThreadLocal中。

requestId即为我们各个系统链路关联的
traceId,系统间互相调用,通过这个
requestId即可找到对应链路,这里还有会有一些其他场景:

Feign远程调用解决方案
@Component
@Slf4j
public class FeignInvokeInterceptor implements RequestInterceptor {
@Override
public void apply(RequestTemplate template) {
String requestId = MDC.get("requestId");
if (StringUtils.isNotBlank(requestId)) {
template.header("requestId", requestId);
}
}
}
@Slf4j
@Component
public class LogInterceptor extends HandlerInterceptorAdapter {
@Override
public void afterCompletion(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, Exception arg3) {
MDC.remove("requestId");
}
@Override
public void postHandle(HttpServletRequest arg0, HttpServletResponse arg1, Object arg2, ModelAndView arg3) {
}
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String requestId = request.getHeader(BaseConstant.REQUEST_ID_KEY);
if (StringUtils.isBlank(requestId)) {
requestId = UUID.randomUUID().toString().replace("-", "");
}
MDC.put("requestId", requestId);
return true;
}
}
线程池异步调用,requestId传递
MDC是基于
ThreadLocal去实现的,异步过程中,子线程并没有办法获取到父线程
ThreadLocal存储的数据,所以这里可以自定义线程池执行器,修改其中的
run()方法:
public class MyThreadPoolTaskExecutor extends ThreadPoolTaskExecutor {
@Override
public void execute(Runnable runnable) {
Map<String, String> context = MDC.getCopyOfContextMap();
super.execute(() -> run(runnable, context));
}
@Override
private void run(Runnable runnable, Map<String, String> context) {
if (context != null) {
MDC.setContextMap(context);
}
try {
runnable.run();
} finally {
MDC.remove();
}
}
}
使用MQ发送消息给第三方系统
requestId,接收方消费消息后,自己解析
requestId使用即可。
END
《Java工程师面试突击第三季》加餐部分大纲:(注:1-66讲的大纲请扫描文末二维码,在课程详情页获取)



详细的课程内容,大家可以扫描下方二维码了解:





