ThreadLocal分析--部分源码

今年的个人文章到今天还没有更新，主要前一段时间一直在感冒中，精神状态太差，对着屏幕都提不起精神，浑浑噩噩的。到今天才有所好转
对于ThreadLocal来说，个人感觉，在平时的业务代码中，ThreadLocal使用的真是太少了。但是去读过Spring的事务那一块源码的朋友一定记得很深，它的holder就是使用了ThreadLocal来绑定当前线程使用的事务信息。
参考博客
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.1Entrystatic 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;

4000
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 removeprivate 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;
}
}
}以上是大致方法的分析，源码部分虽然贴出关键的部分，但是在写本篇文章的时候我还没读懂里面一些具体的场景和操作，以及领悟一些正确的知识，留待后续补充