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
之后,key
就会被回收。其实是不对的,因为题目说的是在做 ThreadLocal.get()
操作,证明其实还是有强引用存在的,所以 key
并不为 null
,如下图所示,ThreadLocal
的强引用仍然是存在的。
如果我们的强引用不存在的话,那么 key
就会被回收,也就是会出现我们 value
没被回收,key
被回收,导致 value
永远存在,出现内存泄漏。
ThreadLocal.set() 方法源码
ThreadLocal
中的set
方法原理如上图所示,很简单,主要是判断ThreadLocalMap
是否存在,然后使用ThreadLocal
中的set
方法进行数据处理。
1 | public void set(T value) { |
ThreadLocalMap Hash算法
既然是Map
结构,那么ThreadLocalMap
当然也要实现自己的hash
算法来解决散列表数组冲突问题。
1 | int i = key.threadLocalHashCode & (len - 1); |
ThreadLocalMap
中hash
算法很简单,这里i
就是当前 key 在散列表中对应的数组下标位置。
这里最关键的就是threadLocalHashCode
值的计算,ThreadLocal
中有一个属性为HASH_INCREMENT = 0x61c88647
每当创建一个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
数据(新增或者更新数据)分为好几种情况,针对不同的情况我们画图来说说明。
通过
hash
计算后的槽位对应的Entry
数据为空:这里直接将数据放到该槽位即可。
槽位数据不为空,
key
值与当前ThreadLocal
通过hash
计算获取的key
值一致:这里直接更新该槽位的数据。
槽位数据不为空,往后遍历过程中,在找到
Entry
为null
的槽位之前,没有遇到key
过期的Entry
:遍历散列数组,线性往后查找,如果找到
Entry
为null
的槽位,则将数据放入该槽位中,或者往后遍历过程中,遇到了key 值相等的数据,直接更新即可槽位数据不为空,往后遍历过程中,在找到
Entry
为null
的槽位之前,遇到key
过期的Entry
,如下图,往后遍历过程中,一到了index=7
的槽位数据Entry
的key=null
:
散列数组下标为 7 位置对应的Entry
数据key
为null
,表明此数据key
值已经被垃圾回收掉了,此时就会执行replaceStaleEntry()
方法,该方法含义是替换过期数据的逻辑,以index=7位起点开始遍历,进行探测式数据清理工作。
初始化探测式清理过期数据扫描的开始位置:slotToExpunge = staleSlot = 7
以当前staleSlot
开始 向前迭代查找,找其他过期的数据,然后更新过期数据起始扫描下标slotToExpunge
。for
循环迭代,直到碰到Entry
为null
结束。
上面向前迭代的操作是为了更新探测清理过期数据的起始下标slotToExpunge
的值,这个值在后面会讲解,它是用来判断当前过期槽位staleSlot
之前是否还有过期元素。
接着开始以staleSlot
位置(index=7)向后迭代,如果找到了相同 key 值的 Entry 数据:
从当前节点staleSlot
向后查找key
值相等的Entry
元素,找到后更新Entry
的值并交换staleSlot
元素的位置(staleSlot
位置为过期元素),更新Entry
数据,然后开始进行过期Entry
的清理工作,如下图所示:
向后遍历过程中,如果没有找到相同 key 值的 Entry 数据:
从当前节点staleSlot
向后查找key
值相等的Entry
元素,直到Entry
为null
则停止寻找。通过上图可知,此时table
中没有key
值相同的Entry
。
创建新的Entry
,替换table[stableSlot]
位置:
替换完成后也是进行过期元素清理工作,清理工作主要是有两个方法:expungeStaleEntry()
和cleanSomeSlots()
,具体细节后面会讲到,请继续往后看。
1 | private void set(ThreadLocal<?> key, Object value) { |
这里会通过key
来计算在散列表中的对应位置,然后以当前key
对应的桶的位置向后查找,找到可以使用的桶。
什么情况下桶才是可以使用的呢?
k = key
说明是替换操作,可以使用- 碰到一个过期的桶,执行替换逻辑,占用过期桶
- 查找过程中,碰到桶中
Entry=null
的情况,直接使用
接着就是执行for
循环遍历,向后查找,我们先看下nextIndex()
、prevIndex()
方法实现:
1 | private static int nextIndex(int i, int len) { |
- 遍历当前
key
值对应的桶中Entry
数据为空,这说明散列数组这里没有数据冲突,跳出for
循环,直接set
数据到对应的桶中 - 如果
key
值对应的桶中Entry
数据不为空- 如果
k = key
,说明当前set
操作是一个替换操作,做替换逻辑,直接返回 - 如果
key = null
,说明当前桶位置的Entry
是过期数据,执行replaceStaleEntry()
方法(核心方法),然后返回
- 如果
for
循环执行完毕,继续往下执行说明向后迭代的过程中遇到了entry
为null
的情况 -- 在
Entry
为null
的桶中创建一个新的Entry
对象 - 执行
++size
操作
- 在
- 调用
cleanSomeSlots()
做一次启发式清理工作,清理散列数组中Entry
的key
过期的数据- 如果清理工作完成后,未清理到任何数据,且
size
超过了阈值(数组长度的 2/3),进行rehash()
操作 - rehash()
中会先进行一轮探测式清理,清理过期
key`,清理完成后如果size >= threshold - threshold / 4,就会执行真正的扩容逻辑(扩容逻辑往后看)
- 如果清理工作完成后,未清理到任何数据,且
接着重点看下replaceStaleEntry()
方法,replaceStaleEntry()
方法提供替换过期数据的功能,我们可以对应上面第四种情况的原理图来再回顾下,具体代码如下:
1 | private void replaceStaleEntry(ThreadLocal<?> key, Object value, |
slotToExpunge表示开始探测式清理过期数据的开始下标,默认从当前的
staleSlot开始。以当前的
staleSlot开始,向前迭代查找,找到没有过期的数据,
for循环一直碰到
Entry为
null才会结束。如果向前找到了过期数据,更新探测清理过期数据的开始下标为 i,即
slotToExpunge=i
1 | for (int i = prevIndex(staleSlot, len); |
接着开始从staleSlot
向后查找,也是碰到Entry
为null
的桶结束。 如果迭代过程中,碰到 k == key,这说明这里是替换逻辑,替换新数据并且交换当前staleSlot
位置。如果slotToExpunge == staleSlot
,这说明replaceStaleEntry()
一开始向前查找过期数据时并未找到过期的Entry
数据,接着向后查找过程中也未发现过期数据,修改开始探测式清理过期数据的下标为当前循环的 index,即slotToExpunge = i
。最后调用cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
进行启发式过期数据清理。
1 | if (k == key) { |
cleanSomeSlots()
和expungeStaleEntry()
方法后面都会细讲,这两个是和清理相关的方法,一个是过期key
相关Entry
的启发式清理(Heuristically scan
),另一个是过期key
相关Entry
的探测式清理。
如果 k != key则会接着往下走,k == null
说明当前遍历的Entry
是一个过期数据,slotToExpunge == staleSlot
说明,一开始的向前查找数据并未找到过期的Entry
。如果条件成立,则更新slotToExpunge
为当前位置,这个前提是前驱节点扫描时未发现过期数据。
1 | if (k == null && slotToExpunge == staleSlot) |
往后迭代的过程中如果没有找到k == key
的数据,且碰到Entry
为null
的数据,则结束当前的迭代操作。此时说明这里是一个添加的逻辑,将新的数据添加到table[staleSlot]
对应的slot
中。
1 | tab[staleSlot].value = null; |
最后判断除了staleSlot
以外,还发现了其他过期的slot
数据,就要开启清理数据的逻辑:
1 | if (slotToExpunge != staleSlot) |
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
。然后接着往后探测:
执行完第二步后,index=4 的元素挪到 index=3 的槽位中。
继续往后迭代检查,碰到正常数据,计算该数据位置是否偏移,如果被偏移,则重新计算slot
位置,目的是让正常数据尽可能存放在正确位置或离正确位置更近的位置
在往后迭代的过程中碰到空的槽位,终止探测,这样一轮探测式清理工作就完成了,接着我们继续看看具体实现源代码:
1 | private int expungeStaleEntry(int staleSlot) { |
这里我们还是以staleSlot=3
来做示例说明,首先是将tab[staleSlot]
槽位的数据清空,然后设置size--
接着以staleSlot
位置往后迭代,如果遇到k==null
的过期数据,也是清空该槽位数据,然后size--
1 | ThreadLocal<?> k = e.get(); |
如果key
没有过期,重新计算当前key
的下标位置是不是当前槽位下标位置,如果不是,那么说明产生了hash
冲突,此时以新计算出来正确的槽位位置往后迭代,找到最近一个可以存放entry
的位置。
1 | int h = k.threadLocalHashCode & (len - 1); |
这里是处理正常的产生Hash
冲突的数据,经过迭代后,有过Hash
冲突数据的Entry
位置会更靠近正确位置,这样的话,查询的时候 效率才会更高。
ThreadLocalMap
扩容机制
在ThreadLocalMap.set()
方法的最后,如果执行完启发式清理工作后,未清理到任何数据,且当前散列数组中Entry
的数量已经达到了列表的扩容阈值(len*2/3)
,就开始执行rehash()
逻辑:
1 | if (!cleanSomeSlots(i, sz) && sz >= threshold) |
接着看下rehash()
具体实现:
1 | private void rehash() { |
这里首先是会进行探测式清理工作,从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
下次扩容的阈值,具体代码如下:
1 | private void resize() { |
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()
源码详解
1 | private Entry getEntry(ThreadLocal<?> key) { |
ThreadLocalMap
过期 key 的启发式清理流程
上面多次提及到ThreadLocalMap
过期可以的两种清理方式:探测式清理(expungeStaleEntry())\、启发式清理(cleanSomeSlots())
探测式清理是以当前Entry
往后清理,遇到值为null
则结束清理,属于线性探测清理。
而启发式清理被作者定义为:Heuristically scan some cells looking for stale entries.
具体代码如下:
1 | private boolean cleanSomeSlots(int i, int n) { |