今年的个人文章到今天还没有更新,主要前一段时间一直在感冒中,精神状态太差,对着屏幕都提不起精神,浑浑噩噩的。到今天才有所好转
对于ThreadLocal来说,个人感觉,在平时的业务代码中,ThreadLocal使用的真是太少了。但是去读过Spring的事务那一块源码的朋友一定记得很深,它的holder就是使用了ThreadLocal来绑定当前线程使用的事务信息。
参考博客
1. ThreadLocal是什么?
1. 首先ThreadLocal和线程同步机制应该说没有任何关系,它不能解决线程同步下的问题,因为之所以存在线程同步,就是要解决共享变量的问题,但是ThreadLocal解决方案是为每一个线程提供一个变量副本,互相不影响,可以说是一种解决思路。
2. API中的定义:
该类提供了线程局部 (thread-local) 变量。这些变量不同于它们的普通对应物,因为访问某个变量(通过其 get 或 set 方法)的每个线程都有自己的局部变量,它独立于变量的初始化副本。ThreadLocal 实例通常是类中的 private static 字段,它们希望将状态与某一个线程(例如,用户 ID 或事务 ID)相关联。
2. ThreadLocal和Thread的关系:
1. ThreadLocal负责管理ThreadLocalMap,主要是插入删除等等,key就是它自己,同时ThreadLocalMap存储的地方实际上是在线程Thread中。
public class Thread implements Runnable {
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
/*
* InheritableThreadLocal values pertaining to this thread. This map is
* maintained by the InheritableThreadLocal class.
*/
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
}
2.假设现在存在线程A,线程B,线程A里面存在TLA,TLB 两个ThreadLocal对象,存入的值分别是VA,VB。线程B里面存在TLC,TLD两个对象。存入的值是VC,VD。
那么最终存储的状态如下:
线程A-->ThreadLocalMap存储<TLA-VA>,<TLB-VB>。
线程B-->ThreadLocalMap存储<TLC,VC>,<TLD,VD>。
3.具体可以形成图形如下:
3.总结一下:
1.每个Thread维护一个ThreadlocalMap的映射表,这个映射表的key就是ThreadLocal实例本身,而value是真正存储的object。
2.同时图中标注的虚线的地方,ThreadlocalMap中的key是使用ThreadLocal弱引用作为key,在GC时会回收掉。
3.ThreadLocalMap的源码解读
不读ThreadLocalMap的源码等于没看过ThreadLocal了。
3.1Entry
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
Entry也就是存储的键值对的model,和hashmap里面的概念类似,这个结构不难,至于WeakReference,弱引用,这个需要重点分析,这边就先不分析了。
3.2字段
/**
* 初始容量,必须为2的幂
* The initial capacity -- MUST be a power of two.
*/
private static final int INITIAL_CAPACITY = 16;
/**
* Entry表,大小也必须为2的幂
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private ThreadLocal.ThreadLocalMap.Entry[] table;
/**
* Entry的大小
* The number of entries in the table.
*/
private int size = 0;
/**
* 重新分配表大小的阈值,默认为0
* The next size value at which to resize.
*/
private int threshold; // Default to 0
/**
* 设置resize阈值以维持最坏2/3的装载因子
* Set the resize threshold to maintain at worst a 2/3 load factor.
*/
private void setThreshold(int len) {
threshold = len * 2 / 3;
}
/**
* 环形意义的下一个索引
* 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);
}
以上都是一些基本字段,通过nextIndex和prevIndex两个方法可以看出,它其实是一个环型的数据结构。这种情况是因为它采用的是线性地址探测法来解决hash冲突,知道hashmap的人应该知道它采用的链表法解决的冲突。
这边盗图一张如下:
3.3构造函数
/**
* Construct a new map initially containing (firstKey, firstValue).
* ThreadLocalMaps are constructed lazily, so we only create
* one when we have at least one entry to put in it.
*/
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
//初始化table数组
table = new ThreadLocal.ThreadLocalMap.Entry[INITIAL_CAPACITY];
//得到hash值,这个跟hashmap一样
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
//初始化该节点
table[i] = new ThreadLocal.ThreadLocalMap.Entry(firstKey, firstValue);
//数目为1
size = 1;
//扩容至阈值
setThreshold(INITIAL_CAPACITY);
}
3.3.1哈希函数
//类似于hashmap的&操作
firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
private final int threadLocalHashCode = nextHashCode();
private static AtomicInteger nextHashCode =
new AtomicInteger();
//这个魔数的选取与斐波那契散列有关,0x61c88647对应的十进制为1640531527。
//斐波那契散列的乘数可以用(long) ((1L << 31) * (Math.sqrt(5) - 1))可以得到2654435769,
//如果把这个值给转为带符号的int,则会得到-1640531527。换句话说
//(1L << 32) - (long) ((1L << 31) * (Math.sqrt(5) - 1))得到的结果就是1640531527也就是0x61c88647。
//通过理论与实践,当我们用0x61c88647作为魔数累加为每个ThreadLocal分配各自的ID也就是threadLocalHashCode再与2的幂取模,得到的结果分布很均匀。
private static final int HASH_INCREMENT = 0x61c88647;
//在上一个被构造出的ThreadLocal的hashCode的基础上加上一个魔数HASH_INCREMENT
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
关于hash函数这边是参考的别人的博客,自己也没什么新的理解到位的地方。
3.4 getEntry方法
//获取某一个Entry数据
private Entry getEntry(ThreadLocal key) {
//得到hash值
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为空
while (e != null) {
ThreadLocal k = e.get();
if (k == key)
return e;
if (k == null)
//该entry对应的ThreadLocal已经被回收,调用expungeStaleEntry来清理无效的entry
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
/**
* 这个函数是ThreadLocal中清理函数
* 从staleSlot处开始遍历,将无效Entry进行清理,直到扫到空的entry
* 另外,在过程中还会对非空的entry作rehash。至于为什么要进行rehash,我暂时没想明白
*/
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
//清除,便于GC回收
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
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 {
//总的来说,这边是对非空节点在进行rehash的过程
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
//这边的注释标注的是采用的计算机程序设计艺术6.4章节的散列理念,但是我没有读懂^_^
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
3.5 setEntry
private void set(ThreadLocal key, Object value) {
// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
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();
}
private void replaceStaleEntry(ThreadLocal key, Object value,
int staleSlot) {
Entry[] tab = table;
int len = tab.length;
Entry e;
// Back up to check for prior stale entry in current run.
// We clean out whole runs at a time to avoid continual
// incremental rehashing due to garbage collector freeing
// up refs in bunches (i.e., whenever the collector runs).
int slotToExpunge = staleSlot;
//向前扫描,查找最前的一个无效slot
for (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len))
if (e.get() == null)
slotToExpunge = i;
// Find either the key or trailing null slot of run, whichever
// occurs first
// 向后遍历table
for (int i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal k = e.get();
// If we find key, then we need to swap it
// with the stale entry to maintain hash table order.
// The newly stale slot, or any other stale slot
// encountered above it, can then be sent to expungeStaleEntry
// to remove or rehash all of the other entries in run.
if (k == key) {
// 更新对应slot的value值
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
// Start expunge at preceding stale entry if it exists
//规定扫描的位置起点
//如果向前扫描时,没有发现无效Entry,那么就以当前位置作为起点
if (slotToExpunge == staleSlot)
slotToExpunge = i;
// 从slotToExpunge开始做一次连续段的清理,
// 再做一次启发式清理
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
// If we didn't find stale entry on backward scan, the
// first stale entry seen while scanning for key is the
// first still present in the run.
// 如果当前的slot已经无效,并且向前扫描过程中没有无效slot,则更新slotToExpunge为当前位置
if (k == null && slotToExpunge == staleSlot)
slotToExpunge = i;
}
// If key not found, put new entry in stale slot
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
// If there are any other stale entries in run, expunge them
//在探测过程中如果发现任何无效slot,则做一次清理(连续段清理+启发式清理)
//这是由于前面做过向前探测
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}
/**
* 启发式地清理slot,
* i对应entry是非无效(指向的ThreadLocal没被回收,或者entry本身为空)
* n是用于控制控制扫描次数的
* 正常情况下如果log n次扫描没有发现无效slot,函数就结束了
* 但是如果发现了无效的slot,将n置为table的长度len,做一次连续段的清理
* 再从下一个空的slot开始继续扫描
*
* 这个函数有两处地方会被调用,一处是插入的时候可能会被调用,另外个是在替换无效slot的时候可能会被调用,
* 区别是前者传入的n为元素个数,后者为table的容量
*/
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;
}
我们来回顾一下ThreadLocal的set方法可能会有的情况:
探测过程中slot都不无效,并且顺利找到key所在的slot,直接替换即可
探测过程中发现有无效slot,调用replaceStaleEntry,效果是最终一定会把key和value放在这个slot,并且会尽可能清理无效slot
在replaceStaleEntry过程中,如果找到了key,则做一个swap把它放到那个无效slot中,value置为新值
在replaceStaleEntry过程中,没有找到key,直接在无效slot原地放entry
探测没有发现key,则在连续段末尾的后一个空位置放上entry,这也是线性探测法的一部分。
放完后,做一次启发式清理,如果没清理出去key,并且当前table大小已经超过阈值了,
则做一次rehash,rehash函数会调用一次全量清理slot方法也即expungeStaleEntries,如果完了之后table大小超过了threshold - threshold / 4,则进行扩容2倍(此处是直接复制粘贴,以免将来忘记)
3.6 remove
private void remove(ThreadLocal key) {
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)]) {
if (e.get() == key) {
//clear加清理
e.clear();
expungeStaleEntry(i);
return;
}
}
}
以上是大致方法的分析,源码部分虽然贴出关键的部分,但是在写本篇文章的时候我还没读懂里面一些具体的场景和操作,以及领悟一些正确的知识,留待后续补充