因为是在%20replaceStaleEntry%20方法中调用的此方法，传进来的值是%20staleSlot%20，继续上图，经过%20replaceStaleEntry%20之后，它的数据结构是这样：此时传进来的%20staleSlot%20值为%206%20，因为此时的%20key%20为%20null%20，所以接下来会走%20e.value%20=%20null%20，这一步结束之后，就成了：接下来%20i%20为%207%20，此时的%20key%20不为%20null%20，那么就会重新%20hash%20:%20int%20h%20=%20k.threadLocalHashCode%20&%20(len%20-%201);%20，得到的%20h%20应该是%205%20，但是实际上%20i%20为%207%20，说明出现了%20hash%20冲突，就会继续向下走，最终的结果是这样：可以看到，原来的 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 方法也有，看下面的源码：

ThreadLocal.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 一下，加快垃圾回收，就完美的避免了内存溢出。