开篇介绍：凡是使用过ThreadLocal的小伙伴，必须注意的的问题就是ThreadLocal的内存泄漏，这也是在面试中经常出现的一道题。下面就让我们来分析一下ThreadLocal的内存泄漏问题。
在上一篇博客由ThreadLocal引发的惨案中我们分析了ThreadLocal的时候，我们知道对ThreadLocal的操作实际上是围绕ThreadLocalMap展开的。ThreadLocalMap的源码相对比较复杂, 我们从以下三个方面进行讨论。
其实， ThreadLocalMap是ThreadLocal的内部类，没有实现Map接口，用独立的方式实现了Map的功能，其内部的Entry也是独立实现。E-R图如下：
下面咱们来看一下ThreadLocalMap的一部分源码：
static class ThreadLocalMap {
/**
* 此哈希映射中的条目使用其主引用字段作为键（始终是ThreadLocal对象）扩展了WeakReference。 请注意，空键（即entry.get（）== null）意味着不再引用该键，因此可以从表中删除该条目。 在下面的代码中，此类条目称为“陈旧条目”。
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** 与此ThreadLocal关联的值 */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
/**
* 初始容量-必须是2的幂。
*/
private static final int INITIAL_CAPACITY = 16;
/**
* 该表，根据需要调整大小。table.length必须始终为2的幂。
*/
private Entry[] table;
/**
* 数组里面entrys的个数，可以用于判断table当前使用量是否超过阈值。
*/
private int size = 0;
/**
* The next size value at which to resize. (扩容时 下次要调整大小的值)
* 进行扩容的阈值，表使用量大于它的时候进行扩容
*/
private int threshold; // Default to 0
/**
* Set the resize threshold to maintain at worst a 2/3 load factor.
* 设置调整大小阈值以保持最坏的2/3负载系数。
*/
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. 递减i模len。
*/
private static int prevIndex(int i, int len) {
return ((i - 1 >= 0) ? i - 1 : len - 1);
}
/**
* 构造一个最初包含（firstKey，firstValue）的map。
* ThreadLocalMaps是延迟构造的，因此只有在至少有一个条目要放置时才创建一个。
*/
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);
}
/**
* Construct a new map including all Inheritable ThreadLocals
* from given parent map. Called only by createInheritedMap.
* 翻译：从给定的ParentMap构造一个包含所有可继承ThreadLocals的新映射。仅由createInheritedMap调用。
* @param parentMap the map associated with parent thread.
* 翻译： parentMap与父线程关联的Map
*/
private ThreadLocalMap(ThreadLocalMap parentMap) {
Entry[] parentTable = parentMap.table;
int len = parentTable.length;
setThreshold(len);
table = new Entry[len];
for (int j = 0; j < len; j++) {
Entry e = parentTable[j];
if (e != null) {
@SuppressWarnings("unchecked")
ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
if (key != null) {
Object value = key.childValue(e.value);
Entry c = new Entry(key, value);
int h = key.threadLocalHashCode & (len - 1);
while (table[h] != null)
h = nextIndex(h, len);
table[h] = c;
size++;
}
}
}
}
/**
* Get the entry associated with key. This method
* itself handles only the fast path: a direct hit of existing
* key. It otherwise relays to getEntryAfterMiss. This is
* designed to maximize performance for direct hits, in part
* by making this method readily inlinable.
* 翻译：获取与键关联的条目。该方法本身仅处理快速路径：直接命中现有密钥。否则，它将中继到getEntryAfterMiss。这样做的目的是最大程度地提高直接打击的性能，部分原因是使此方法易于操作。
* @param key the thread local object key线程本地对象
* @return the entry associated with key, or null if no such 返回一个Entry，没有则返回null
*/
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);
}
/**
* Version of getEntry method for use when key is not found in
* its direct hash slot.
* 翻译：在哈希槽中找不到密钥时使用getEntry方法的版本。
* @param key the thread local object 当前线程的本地对象
* @param i the table index for key's hash code hashcode值
* @param e the entry at table[i]
* @return the entry associated with key, or null if no such
*/
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;
}
/**
* Set the value associated with key.
*
* @param key the thread local object
* @param value the value to be set
*/
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.
//翻译：我们不像get（）那样使用快速路径，因为使用set（）创建新条目与替换现有条目至少一样普遍，在这种情况下，快速路径经常会失败。
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();
}
/**
* Remove the entry for key.
* 翻译：删除方法
*/
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) {
e.clear();
expungeStaleEntry(i);
return;
}
}
}
/**
* Replace a stale entry encountered during a set operation
* with an entry for the specified key. The value passed in
* the value parameter is stored in the entry, whether or not
* an entry already exists for the specified key.
* 翻译：将设置操作期间遇到的陈旧条目替换为指定键的条目。无论是否已存在指定键的条目，在value参数中传递的值都存储在该条目中。
* As a side effect, this method expunges all stale entries in the
* "run" containing the stale entry. (A run is a sequence of entries
* between two null slots.)
* 翻译： 副作用是，此方法删除了包含过时条目的“运行”中的所有过时条目。 （运行是两个空槽之间的一系列输入。）
* @param key the key
* @param value the value to be associated with key 与key关联的值
* @param staleSlot index of the first stale entry encountered while
* searching for key. 搜索密钥时遇到的第一个陈旧条目的索引。
*
*/
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;
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
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) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
// Start expunge at preceding stale entry if it exists
if (slotToExpunge == staleSlot)
slotToExpunge = i;
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.
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
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}
/**
* Expunge a stale entry by rehashing any possibly colliding entries
* lying between staleSlot and the next null slot. This also expunges
* any other stale entries encountered before the trailing null. See
* Knuth, Section 6.4
*
* @param staleSlot index of slot known to have null key
* @return the index of the next null slot after staleSlot
* (all between staleSlot and this slot will have been checked
* for expunging).
*/
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;
}
/**
* Heuristically scan some cells looking for stale entries.
* This is invoked when either a new element is added, or
* another stale one has been expunged. It performs a
* logarithmic number of scans, as a balance between no
* scanning (fast but retains garbage) and a number of scans
* proportional to number of elements, that would find all
* garbage but would cause some insertions to take O(n) time.
*
* @param i a position known NOT to hold a stale entry. The
* scan starts at the element after i.
*
* @param n scan control: {@code log2(n)} cells are scanned,
* unless a stale entry is found, in which case
* {@code log2(table.length)-1} additional cells are scanned.
* When called from insertions, this parameter is the number
* of elements, but when from replaceStaleEntry, it is the
* table length. (Note: all this could be changed to be either
* more or less aggressive by weighting n instead of just
* using straight log n. But this version is simple, fast, and
* seems to work well.)
*
* @return true if any stale entries have been removed.
*/
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;
}
/**
* Re-pack and/or re-size the table. First scan the entire
* table removing stale entries. If this doesn't sufficiently
* shrink the size of the table, double the table size.
*/
private void rehash() {
expungeStaleEntries();
// Use lower threshold for doubling to avoid hysteresis
if (size >= threshold - threshold / 4)
resize();
}
/**
* Double the capacity of the table.
*/
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;
}
/**
* Expunge all stale entries in the table.
*/
private void expungeStaleEntries() {
Entry[] tab = table;
int len = tab.length;
for (int j = 0; j < len; j++) {
Entry e = tab[j];
if (e != null && e.get() == null)
expungeStaleEntry(j);
}
}
}
}通过上面的源码我们可以看出：ThreadLocalMap的结构设计和HashMap类似，INITIAL_CAPACITY代表这个Map的初始容量；table 是一个Entry 类型的数组，用于存储数据；size 代表表中的存储数目； threshold 代表需要扩容时对应 size 的阈值。【在这里需要说明一下：阈 这个字读 yu，而非读 fa， 阀 字门中是 伐，阈 字 门中是 或】
而且在ThreadLocalMap中，也是用Entry来保存K-V结构数据的。不过Entry中的key只能是ThreadLocal对象，这点在构造方法中已经限定死了。另外，Entry继承WeakReference，也就是key（ThreadLocal）是弱引用，其目的是将ThreadLocal对象的生命周期和线程生命周期解绑。
这里要着重说的就是这个弱引用，有时候在使用ThreadLocal的过程中有内存泄漏的情况发生，就猜测这个内存泄漏跟Entry中使用了弱引用的key有关系。这个理解其实是不全对的。下面就让我们来分析一下。
都知道在Java中有四种引用：强，软，弱，虚；这里我们就先简单回顾强，弱两种；如果有人不知道这四种引用的可以去百度一下
强引用：如果一个对象具有强引用，它就不会被垃圾回收器回收。即使当前内存空间不足，JVM也不会回收它，而是抛出 OutOfMemoryError 错误，使程序异常终止。如果想中断强引用和某个对象之间的关联，可以显式地将引用赋值为null，这样一来的话，JVM在合适的时间就会回收该对象。
String str = "hello"; // 强引用 str = null; // 取消强引用弱引用：具有弱引用的对象拥有的生命周期更短暂。因为当 JVM 进行垃圾回收，一旦发现弱引用对象，无论当前内存空间是否充足，都会将弱引用回收。不过由于垃圾回收器是一个优先级较低的线程，所以并不一定能迅速发现弱引用对象。
WeakReference<String> weakName = new WeakReference<String>("hello");
相关知识点：
Memory overflow: 内存溢出，没有足够的内存提供申请者使用。
Memory leak: 内存泄漏是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。内存泄漏的堆积终将导致内存溢出。
回顾完上面的概念，下面我们就详细的介绍一下ThreadLocal中存在的内存泄漏的问题吧。我们可以使用比较的方式去分析，这个比较呢其实就是强，软引用的比较
假设1：假设ThreadLocalMap 中的Entry使用强引用
问题：ThreadLocalMap中的key使用了强引用，那么会出现内存泄漏吗？
此时ThreadLocal的内存图（实线表示强引用）如下：
分析：
在此，我们假设在业务代码中已经使用完了ThreadLocal ，threadLocal Ref被回收了。
但是因为threadLocalMap的Entry强引用了threadLocal，造成threadLocal无法被回收。
在没有手动删除这个Entry以及CurrentThread依然运行的前提下，始终有强引用链 CurrentThread Ref —> CurrentThread —> ThreadLocalMap —> Entry，Entry就不会被回收（Entry中包括了ThreadLocal实例和value），导致Entry内存泄漏。
也就是说，ThreadLocalMap中的key使用了强引用， 是无法完全避免内存泄漏的。
实际上 ThreadLocalMap中Entry是弱引用，我们就分析一下弱引用时，会不会发生内存泄漏。
问题：ThreadLocalMap中的key使用了弱引用，会出现内存泄漏吗？
此时ThreadLocal的内存图（实线表示强引用，虚线表示弱引用）如下：
分析：
同样假设我们在业务代码中使用完了ThreadLocal ，ThreadLocal Ref被回收了。
由于ThreadLocalMap只持有ThreadLocal的弱引用，没有任何强引用指向Threadlocal实例, 所以Threadlocal就可以顺利被GC回收，此时Entry中的key=null。
但是在没有手动删除这个Entry以及CurrentThread依然运行的前提下，也存在有强引用链 CurrentThread Ref —> CurrentThread —> ThreadLocalMap —> Entry —> value ，value不会被回收， 而这value永远不会被访问到了，导致value内存泄漏。也就是说，ThreadLocalMap中的key使用了弱引用， 也有可能内存泄漏。
问题：那么出现内存泄漏的真实原因是什么呢？
通过上面两种情况的比较，内存泄漏的发生跟ThreadLocalMap中的key是否使用弱引用是没有关系的。强弱引用的不同只是发生内存泄漏的点不同，那么内存泄漏的的真正原因是什么呢？
其实不难发现只要使用完ThreadLocal，如果不删除Entry或者不终止当前线程CurrentThread的运行就会发生内存泄漏，显而易见造成内存泄漏的的真正原因有两点：
- 没有手动删除这个Entry
- CurrentThread依然运行
第一点很好理解，只要在使用完ThreadLocal，调用其remove方法删除对应的Entry，就能避免内存泄漏。
第二点稍微复杂一点， 由于ThreadLocalMap是Thread的一个属性，被当前线程所引用，所以它的生命周期跟Thread一样长。那么在使用完ThreadLocal之后，如果当前Thread也随之执行结束，ThreadLocalMap自然也会被gc回收，从根源上避免了内存泄漏。
总结：重点来了，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏。
问题：那么Entry中为什么使用弱引用，使用弱引用有什么好处吗？
根据刚才的分析, 我们知道了： 无论ThreadLocalMap中的key使用哪种类型引用都无法完全避免内存泄漏，跟使用弱引用没有关系。
避免内存泄漏两种方式：
- 使用完ThreadLocal，调用其remove方法删除对应的Entry
- 使用完ThreadLocal，当前Thread也随之运行结束
分析：相对第1种方式，第2种方式显然更不好控制，特别是使用线程池的时候，线程结束是不会销毁的。也就是说，只要记得在使用完ThreadLocal及时的调用remove，无论key是强引用还是弱引用都不会有问题。
那么为什么key要用弱引用呢？
事实上，在ThreadLocalMap中的set/getEntry方法中，会对key为null（也即是ThreadLocal为null）进行判断，如果为null的话，那么是会对value置为null的。
这说明只要使用完ThreadLocal，CurrentThread依然运行的前提下，就算忘记调用remove方法，弱引用比强引用可以多一层保障：弱引用的ThreadLocal会被回收，对应的value在下一次ThreadLocalMap调用set()，get()，remove() 中的任一方法的时候会被清除，从而避免内存泄漏。
329
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
