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的过程，内存泄漏是怎么发生(主要结合弱引用的特性)。