阿粉昨天说我动不动就内存泄漏，我好委屈...
https://mp.weixin.qq.com/s/DkgYoM1UK2vAOFQHIihRKA html
天天早上七点三十，准时推送干货你们好，我是 ThreadLocal ，昨天阿粉说我动不动就内存泄漏，我蛮委屈的，我才没有冤枉他嘞，证据在这里： ThreadLocal 你怎么动不动就内存泄漏？数组
由于人家明明也考虑到了不少状况，作了不少事情，保证了若是没有 remove ，也有对 key 值为 null 时进行回收的处理操做数据结构
啥？你居然不信？我 ThreadLocal 难道会骗你么app
今天为了证实一下本身，我打算从组成的源码开始讲起，在 get ， set 方法中都有对 key 值为 null 时进行回收的处理操做，先来看 set 方法是怎么作的ide
set
下面是 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.
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
// 若是 e 不为空,说明 hash 冲突,须要向后查找
e != null;
// 从这里能够看出, ThreadLocalMap 采用的是开放地址法解决的 hash 冲突
// 是最经典的 线性探测法 --> 我以为之因此选择这种方法解决冲突时由于数据量不大
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
// 要查找的 ThreadLocal 对象找到了,直接设置须要设置的值,而后 return
if (k == key) {
e.value = value;
return;
}
// 若是 k 为 null ,说明有 value 没有及时回收,此时经过 replaceStaleEntry 进行处理
// replaceStaleEntry 具体内容等下分析
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
// 若是 tab[i] == null ,则直接建立新的 entry 便可
tab[i] = new Entry(key, value);
int sz = ++size;
// 在建立以后调用 cleanSomeSlots 方法检查是否有 value 值没有及时回收
// 若是 sz >= threshold ,则须要扩容,从新 hash 即, rehash();
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
经过源码能够看到，在 set 方法中，主要是经过 replaceStaleEntry 方法和 cleanSomeSlots 方法去作的检测和处理ui
接下来瞅瞅 replaceStaleEntry 都干了点儿啥url
replaceStaleEntry
private void replaceStaleEntry(ThreadLocal<?> key, Object value,
int staleSlot) {
Entry[] tab = table;
int len = tab.length;
Entry e;
// 从当前 staleSlot 位置开始向前遍历
int slotToExpunge = staleSlot;
for (int i = prevIndex(staleSlot, len);
(e = tab[i]) != null;
i = prevIndex(i, len))
if (e.get() == null)
// 当 e.get() == null 时, slotToExpunge 记录下此时的 i 值
// 即 slotToExpunge 记录的是 staleSlot 左手边第一个空的 Entry
slotToExpunge = i;
// 接下来从当前 staleSlot 位置向后遍历
// 这两个遍历是为了清理在左边遇到的第一个空的 entry 到右边的第一个空的 entry 之间全部过时的对象
// 可是若是在向后遍历过程当中,找到了须要设置值的 key ,就开始清理,不会再继续向下遍历
for (int i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
// 若是 k == key 说明在插入以前就已经有相同的 key 值存在,因此须要替换旧的值
// 同时和前面过时的对象进行交换位置
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
// 若是 slotToExpunge == staleSlot 说明向前遍历时没有找到过时的
if (slotToExpunge == staleSlot)
slotToExpunge = i;
// 进行清理过时数据
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
// 若是在向后遍历时,没有找到 value 被回收的 Entry 对象
// 且刚开始 staleSlot 的 key 为空,那么它自己就是须要设置 value 的 Entry 对象
// 此时不涉及到清理
if (k == null && slotToExpunge == staleSlot)
slotToExpunge = i;
}
// 若是 key 在数组中找不到,那就好说了,直接建立一个新的就能够了
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
// 若是 slotToExpunge != staleSlot 说明存在过时的对象,就须要进行清理
if (slotToExpunge != staleSlot)
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}
在 replaceStaleEntry 方法中,须要注意一下刚开始的两个 for 循环中内容（在这里再贴一下）：spa
if (e.get() == null)
// 当 e.get() == null 时, slotToExpunge 记录下此时的 i 值
// 即 slotToExpunge 记录的是 staleSlot 左手边第一个空的 Entry
slotToExpunge = i;
if (k == key) {
e.value = value;
tab[i] = tab[staleSlot];
tab[staleSlot] = e;
// 若是 slotToExpunge == staleSlot 说明向前遍历时没有找到过时的
if (slotToExpunge == staleSlot)
slotToExpunge = i;
// 进行清理过时数据
cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
return;
}
这两个 for 循环中的 if 究竟是在作什么？3d
看第一个 if ，当 e.get() == null 时，此时将 i 的值给 slotToExpunge
第二个 if ，当 k ==key 时，此时将 i 给了 staleSlot 来进行交换
为何要对 staleSlot 进行交换呢？画图说明一下
以下图，假设此时表长为 10 ，其中下标为 3 和 5 的 key 已经被回收（ key 被回收掉的就是 null ），由于采用的开放地址法，因此 15 mod 10 应该是 5 ，可是由于位置被占，因此在 6 的位置，一样 25 mod 10 也应该是 5 ，可是由于位置被占，下个位置也被占，因此就在第 7 号的位置上了
按照上面的分析，此时 slotToExpunge 值为 3 ， staleSlot值为 5 ， i 为 6
假设，假设这个时候若是不进行交换，而是直接回收的话，此时位置为 5 的数据就被回收掉，而后接下来要插入一个 key 为 15 的数据，此时 15 mod 10 算出来是 5 ，正好这个时候位置为 5 的被回收完毕，这个位置就被空出来了，那么此时就会这样：
一样的 key 值居然出现了两次？！
这确定是不但愿看到的结果，因此必定要进行数据交换
在上面代码中有一行代码 cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); ，说明接下来的处理是交给了 expungeStaleEntry ，接下来去分析一下 expungeStaleEntry
expungeStaleEntry
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();
// 若是 k == null ,说明 value 就应该被回收掉
if (k == null) {
// 此时直接将 e.value 置为 null
// 这样就将 thread -> threadLocalMap -> value 这条引用链给打破
// 方便了 GC
e.value = null;
tab[i] = null;
size--;
} else {
// 这个时候要从新 hash ,由于采用的是开放地址法,因此能够理解为就是将后面的元素向前移动
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;
}
由于是在 replaceStaleEntry 方法中调用的此方法，传进来的值是 staleSlot ，继续上图，通过 replaceStaleEntry 以后，它的数据结构是这样：
此时传进来的 staleSlot 值为 6 ，由于此时的 key 为 null ，因此接下来会走 e.value = null ，这一步结束以后，就成了：
接下来 i 为 7 ，此时的 key 不为 null ，那么就会从新 hash : int h = k.threadLocalHashCode & (len - 1); ，获得的 h 应该是 5 ，可是实际上 i 为 7 ，说明出现了 hash 冲突，就会继续向下走，最终的结果是这样：
能够看到，原来的 key 为 null ，值为 V5 的已经被回收掉了。我认为之因此回收掉以后，还要再次进行从新 hash ，就是为了防止 key 值重复插入状况的发生
假设 key 为 25 的并无进行向前移动，也就是它还在位置 7 ，位置 6 是空的，再插入一个 key 为 25 ，通过 hash 应该在位置 5 ，可是有数据了，那就向下走，到了位置 6 ，诶，居然是空的，赶忙插进去，这不就又形成了上面说到的问题，一样的一个 key 居然出现了两次？！
并且通过 expungeStaleEntry 以后，将 key 为 null 的值，也设置为了 null ，这样就方便 GC
分析到这里应该就比较明确了，在 expungeStaleEntry 中，有些地方是帮助 GC 的，而经过源码可以发现， set 方法调用了该方法进行了 GC 处理， get 方法也有，不信你瞅瞅：
get
private Entry getEntry(ThreadLocal<?> key) {
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
// 若是可以找到寻找的值,直接 return 便可
if (e != null && e.get() == key)
return e;
else
// 若是找不到,则调用 getEntryAfterMiss 方法去处理
return getEntryAfterMiss(key, i, e);
}
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)
// 若是 k == null 说明有 value 没有及时回收
// 调用 expungeStaleEntry 方法去处理,帮助 GC
expungeStaleEntry(i);
else
i = nextIndex(i, len);
e = tab[i];
}
return null;
}
get 和 set 方法都有进行帮助 GC ，因此正常状况下是不会有内存溢出的，可是若是建立了以后一直没有调用 get 或者 set 方法，仍是有可能会内存溢出
因此最保险的方法就是，使用完以后就及时 remove 一下，加快垃圾回收，就完美的避免了垃圾回收
我 ThreadLocal 虽然没办法作到 100% 的解决内存泄漏问题，可是我能作到 80% 不也应该夸夸我嘛
Java极客技术 发起了一个读者讨论欢迎留言吐槽精选讨论内容参与讨论
poker
上面set函数里面的for循环注释写的不对，实际上是由于用了开放定址法解决冲突，因此在set的时候，以第一个非空的entry做为起始条件，以entry为空做为终止条件，而后逐个比较key是否和参数对应
< END >