threadlocal
1 基础
现象：threadlocal作为一个全局变量，在不同的线程去get的时候能够获取不同的值。
应用场景：
- SimpleDateFormat线程不安全，每个线程都要用，new太多，放到threadlocal中线程池可反复使用。
- 一个请求链路很长，经过数个服务，每次都要放到参数带着。改为直接放到threadlocal作为上下文。（每个线程独立的上下文）
原理：ThreadLocal对象本身其实不存储内容，而是Thread对象有个ThreadLocalMap来进行存储，ThreadLocal作为这个map的key，运行get方法，实际是map.get(threadlocal)
2 使用习惯
线程池与ThreadLocal配合使用的时候，一定注意线程是回收的，Thread对象还在，因而ThreadLocalMap还在，因而里面的key-value都没有被销毁。这样轻则是引起内存泄漏，一直没有清理这部分内容。严重的则会因为再次get到线程上一世的内容，导致错误。
所以如果threadlocal不再使用了，一定记得及时remove掉，防止不必要的麻烦。
上面场景1其实是利用了不被清理这一点进行了复用。
下面基于jdk1.8
3 弱引用
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
entry弱引用了key,也就是说key如果没有被其他对象强引的话，下次gc就被删掉了。这个有啥用呢？
参考20.09中ThreadLocal的讲解吧，这里之前写错了。
4 内存结构
ThreadLocalMap是采用了数组的存储结构，每个元素就是entry本身，而不是链表红黑树。
虽然上述情况很少出现，但是array却很好的避免了这一点。
数组会出现冲突，是怎么解决的？
如果冲突就往后一位，如果后面一位不为空，就继续往后，直到找到空位子。
可能会出现hash为3,4,3的元素abc分别存储最后存入的样子是abc（ac的hash都是3却不相邻），这也是为啥get的时候需要一直找到null为止。
5 get set remove清理key为null的entry
先说get的时候，直接找arr[hash(key)]，如果就是key所在的entry那就返回：
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);
}
如果没找到就数组往下找,一直找到null元素，都没找到的话就返回null：
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;
}
！！ 注意，get过程中找到k==null的需要进行expungeStaleEntry(清除陈旧的entry),将k=null的当前这条entry的value和entry本身清理掉。然后还需要从当前位置向后一直到null的所有元素都进行重排。重排可以定义为：
元素尽量往他本来应该在的hash(element)这个位置移动的过程叫做重排
先删除k=null的这个元素，然后后面的重排的过程叫删除并重排
例如hash为4、3的bc分别在4和5位置，这是有可能的因为3位置可能之前有元素，后来key成了null如下：
数组:
xxx|xxx|xxx|null-v|b-v|c-v|null|....
get(某个hash为3的元素)触发了重排:
xxx|xxx|xxx|c-v|b-v|null|....
上面重排过程c-v移动到了b-v前面，因为b的hash本就是4所以保持不动，c的hash是3，尽量前移发现3位置是null就直接到3了。
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
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 {
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.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
}
remove和get一样，还少了初始化的步骤。
set
set是最复杂的，假设hash(key)=x，同样去找table[x]。
- 如果找到null，就直接令
table[x]=<key,value>。 - 如果找到e，且e.k==key，则直接更新e.v=value。
- 如果找到e，且e.k!=key，则x++。
如果上述过程中找到了e.k==null，这里和get不一样，假设这个位置下标是y（y>=x）。set的时候是先去找一数z。括号里先不看，方便理解（先向左，找到null为止，找下标最小的一个e.k==null的元素，这个下标就是z。如果没有找到，则）向后找找到第一个e.k==null的元素的下标就是z了。
也就是找到k=null的再往后找下一个k=null的。
在向后找的过程中，需要一边判断e.k是不是刚好就是key。如果是的话，循环就可以退出了，将y位置直接设置为[key,value]，将找到的这个位置清除，令z=当前这个位置。然后在z往后运行log(size)次【删除并重排】。
set的清理不是一轮而是log2(table.length)-1轮，清理范围更大； set的key本身找到的话会被跳到尽可能最靠前的地方（y位置）。
下面所有的k的hash都是x，思考k4.set(vv4)过程。
x x+1 x+2 x+3
|null-v1|k2-v2|k3-v3|k4-v4|..
️
|k4-vv4 |k2-v2|k3-v3|null |..
如果按照get的流程，则应该是k2，3，4各自前移一步，此处set策略不同，仔细体会下。
set清理比get要多，但都不是完全清理掉k=null的。
为啥要清理k=null的，因为用不到了，get不到了，所以没有存在的意义，不清理也是内存垃圾。