threadlocal的过期数据_ThreadLocal原理以及内存泄漏的问题
ThreadLocal的整体的结构
ThreadLocal的整体的结构
可以通过上图看到，ThreadLocal内部是基于一个ThreadLocalMap来实现，而ThreadLocalMap内部又是一个Entry的数据结构。这个Entry的数据结构最终是基于弱引用来使用。我们看源码的定义。
static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal> k, Object v) {
super(k);
value = v;
}
}
内部数据结构之间的通信
从图一，我们知道了ThreadLocal的数据结构与内部组件。下面，我们来看看他的这些内部组件是怎么进行一个沟通访问的。
我们通过看源码中的get()操作看看大致是一个怎么的过程。
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
我们想一下，Thread都说是线程之间相互隔离的，那么相互隔离的话，这个内部维护的数据就应该是每个线程他自己所持有的。我们可以看到getMap(t);的实现证明了我们这个想法:
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
而Thread的内部也刚好维护了ThreadLocalMap。
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
所以，我们可以理解成一个Thread就有个自己的ThreadMap.而自己维护自己的数据相互独立。但是，这里要注意一点，如果在线程中，在创建一个线程，这个时候，就不能通过ThreadLocal进行get数据了，这个时候已经做了线程之间的切换了，如果想要获子线程能够访问到父线程的数据，这个时候就要使用InheritableThreadLocal这个继承的ThreadLocal来操作了。
OK，我们通过ThreadLocal的get操作大致明白了他的一个内部数据之间是怎么一个联系。那么我们再来看看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);
}
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();
}
set方法的前两步没问题，通过当前Thread获得自己的ThreadLocalMap。如果ThreadLocalMap为空就进行一个创建，非空就是一个填值。而create的时候就是简单的new ThreadLocalMap(), 并且这个时候是绑定当前线程的value为一个null，然后赋值给当前ThreadLocal。
/**
* The initial capacity -- MUST be a power of two.
*/
private static final int INITIAL_CAPACITY = 16;
/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
/**
* The number of entries in the table.
*/
private int size = 0;
/**
* The next size value at which to resize.
*/
private int threshold; // Default to 0
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);
}
ThreadLocalMap并不像我们平常使用的HashMap那样维护一个链表，而是单纯的一个数组。而他的hashCode是从0x61c88647开始，没使用一次，进行一个加1. 将我们的key 和value维护到了Entry中，然后在放入我们的Entry数组中。并记录ThreadLocalMap的扩容阈值。由于他是使用了一个AtomicInteger的getAndAdd方法来获取hashCode，所以，我们想的hash冲突就迎刃而解了。
那么我们重点来关注他下面的set方法。
这个过程中。通过hash值算出在ThreadLocalMap中的table中的具体下标索引。
这里的大致过程就是通过key去寻找对应的Entry是否存在。这里为什么要这么做？因为Entry使用的是一个弱引用，弱引用在获取值的时候，可能已经被上一次GC所回收了值，这个时候，我们就要进行一个重新赋值。
而这个地方最有意思的就是在最下面的扩容了，因为前面的赋值只是一些常规的操作“有，覆盖；无，创建”，并且使用的是一个弱引用而已，可扩容的地方就要再看一看了。
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
cleanSomeSlots这个地方就是我们前面说的，由于是弱引用，所以这个地方，他在进行一个填充值的时候，进行了一个额外的删除已经被GC的Key对应的Value(至于为什么要说是已经被GC的Key对应的Value我们下面再说。)，这个动作相当于是一个懒式的操作。
下面我们跟进rehash():
private void rehash() {
expungeStaleEntries();
// Use lower threshold for doubling to avoid hysteresis
if (size >= threshold - threshold / 4)
resize();
}
expungeStaleEntries这个其实就是cleanSomeSlots的内部实现，用法不解释了。而当容量大于阈值的3/4的时候，就需要resize了。
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; // Help the GC
} 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;
}
从这里可以看到，他的扩容是两倍两倍的进行扩容，然后将老的数据从老的table中拿出，然后重新hash得到一个新的index，然后填充到新的table中。这就是一个简单的两个数组的拷贝，然后重新设置了一下阈值。好吧，原来就是这么简单。。。。
再谈内存泄漏的问题
从第一张图中，我们知道了ThreadLocalMap中的内部是一个Entry的数据结构，而Entry的数据结构又是一个弱引用WeakReference>.这里要注意了, 弱引用里面的泛型是ThreadLocal,而这个从之前的代码里面可以发现，传递到这里的ThreadLocal就是this，再结合一下弱引用的特性想一下，如果ThreadLocal这个对象被回收了，但是我当前的线程还是在继续运行，注意哦，我们的ThreadLocalMap是在线程Thread里面的哦，所以ThreadLocal在弱引用的时候被GC，我们的线程还在继续运行，ThreadLocalMap也是还会继续存活的，但是，这个时候，TheadLocalMap的key已经不存在了, 但是，我们的value可不是WeakReference弱引用，并没有被GC。这样，这个value只要线程还在继续运行，就永远不会被GC掉。
static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal> k, Object v) {
super(k);
value = v;
}
}
所以，这就出现了内存泄漏的现象。避免出现这种现象的方法一般都是在ThreadLocal使用完了之后，进行一个TreadLocal.remove()方法操作。
总结
ThreadLocal在面试的过程中也经常被问到，这里主要要关注的就是他的内部是一个怎样的结构，resize的过程，内存泄漏是怎么发生(主要结合弱引用的特性)。