前情回顾
前文，介绍ThreadLocal不恰当使用姿势造成的内存泄露问题，提醒大家使用完ThreadLocal须记得调用remove方法及时回收，避免内存泄露
诚然，不恰当的使用姿势确实有内存泄露的问题，但JDK作者们为了降低内存泄露对应用程序造成的影响绞尽脑汁，想尽了办法，做了各种各样的努力和尝试，本文就来看看作者们做了什么额外的补救措施
这是任何一款成熟的商业产品该具有的模样：核心业务代码占比应是少部分，而围绕在核心代码之外的大部分代码都是为了产品体验更友好，考虑的更周全，能应付各种恶劣的场景)
正文
先回忆一下，内存泄露产生的原因：使用了ThreadLocal，但使用完毕之后未调用remove方法进行清除
那么本质上，本文要探索的问题是：如果确实在未主动调用remove的情况下造成了内存泄露，JDK做了什么努力来降低这种影响
基本事实
此处先了解一个基本事实：ThreadLocalMap是一个自定义的 hash map，它与java.util.HashMap在解决hash冲突时所采取的策略不同：ThreadLocalMap使用的是线性探测法来解决冲突，而java.util.HashMap使用的是链地址法解决冲突
此处简单介绍一下线性探测法的原理。假设一个数组长度为n，通过对待放入的Key的hash值对n求余得到要存储的位置index[index = hash(key)%n]，如果该位置已经被占用，则令index = index + 1，继续探测下一个位置，直到找到一个空闲的位置为止，该位置就是最终存储元素的位置，如图示：
回到JDK作者解决内存泄露的思路，我们来设想这样一个场景：
假设一名古代强盗，其目的是强劫金银财宝，见人就抢风险大收益低，大部分是贫困百姓，抢了也没几个钱，还冒着暴露的风险；直接上达官贵族家里抢又找不着门路，或许可能更危险，那怎么办呢？
强盗们也不笨：此山是我开，此路是我栽，若要从此过，留下买路财，选择直接在通往城镇的主干道上蹲点，见到衣着华贵带有大批货物，携带的保镖兵团也不强的商人，这大概率就是要下手的目标人群。这里的核心逻辑在于：商人们无论进、出城贸易，都需要经过城镇的主干大道，因此在主干道上蹲点能够【集中兵力】实现效益的最大化
JDK的作者们也是采用了类似的思路：在经常被调用的方法(主干道)上去寻找那些已经不使用的脏数据并清理掉。这种方式能够实现效益的最大化：使用了最低的成本(仅在少数方法内部去做这件事)解决了最大的问题(内存泄露)，这也是2\8原则的一种体现
因此，对于ThreadLocal而言，需要识别出哪些方法被经常调用的，然后在这些方法上"动手脚"。如下图示，应该很轻易看出：get、set、remove是最常用的
ThreadLocal中清理脏数据的方法是java.lang.ThreadLocal.ThreadLocalMap#expungeStaleEntry，如下示：
// java.lang.ThreadLocal.ThreadLocalMap#expungeStaleEntry
// staleSlot: 待清理的slot，该slot指向的entry一定是stale(旧的)，即key一定是null[ThreadLocal.get()为null]
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// ...(省略)
return i;
}
入参：staleSlot，待清理的slot，该slot指向的entry一定stale(旧的)，即key一定是null[ThreadLocal.get()为null]
画外音：该方法只专注于理清Entry这件事，而不管Entry的内容实际上是否旧的，因此需要由调用方来保证staleSlot指向的entry一定stale
代码逻辑：
将entry里值的强引用置为null，即断掉指向值对象的强引用(这样值对象就对被GC回收)
将entry对应引用置为null，即断掉指向Entry对象的强引用(这样Entry就能被GC回收)
因此，只要调用expungeStaleEntry方法，就能将无用entry(脏数据)回收清理掉。现在来看看哪些方法调用了它：
我们只看到了一个remove方法，与上面说的set\get\remove好像不太对应？其实只是由于方法分层，没有直接在set\get里调用，没关系，由于调用链路比较深，笔者使用一张简单来表示，有兴趣的看官们可以拿着手中源码一起对照着看
从上图中可以看出，每次调用set\get\remove，确实最终会调用到expungeStaleEntry方法并将无用entry(脏数据)回收清理掉
方法众多，笔者挑一个相对有意思的cleanSomeSlots进行分析
方法签名为private boolean cleanSomeSlots(int i, int n)，从方法名称上看，"清理一些slots" 意味着它会清理slot，但很有可能只会清理一些而不是清理所有，因此"一些"是作者刻意为之，巧妙地设计成对数次的扫描清理，这是设计上的一个Trade Off :
如果不清理，方法诚然很快就能完成并返回，但是这就意味着内存泄露，意味着脏垃圾
如果全清理，每次插入都伴随着entry数组的全扫描，随着数组的扩容，put方法性能会持续恶化
因此，需要找到完全不扫描与slot数量成正比的扫描次数之间的平衡，即O(1)与O(n)之间的平衡，学过数据结构的同学应该很轻易联想到O(log2[n])，不会随着数组的扩容而导致扫描效率变低。实现细节如下：
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); // 右移1位，相当于除以2
return removed;
}
至此，看官们是否有一种似曾相识的感觉，脑瓜中隐隐约约回忆起某个组件有过类似场景的处理：Redis的过期淘汰策略
对于Redis过期的Key，采用的是定期删除 + 惰性删除 机制
定期删除： Redis每隔一定的时间，就抽取"一批"而不是“所有”过期的Key进行删除，通过控制删除Key的数量、执行间隔来减少CPU的消耗
惰性删除： Redis在获取某个Key时，检查一下是否过期，如果已过期就执行删除操作并返回空
其中的定期删除所采用的思想与cleanSomeSlots如出一辙：都是选取一批而不是全部的Key来进行删除，以此来权衡内存占用与CPU占用之间的关系
你瞧，大牛们思想是一致的，技术的本质都是相通的！
总结
本文主要是表达了一个观点：ThreadLocal不恰当使用姿势尽管容易造成内存泄露，但是做为一个成熟的产品，作者有努力去解决这个问题，已经尽可能地把问题造成的影响最小化。在这个过程中，我们还发现了一个设计上的Trade Off，并且思想上与Redis的过期淘汰策略一致(知识的迁移)，如果大家能从中获得一些启发，将会是看官们阅读本文最大的收获，至少笔者本人是这样
画外音
常常会看到这样的简历：阅读过XXX源码。嗯，是的，阅读过，然后呢？有没有得到一些启发呢，思想上有没有更进步呢？大家都阅读同一份源码，为什么有人就能从中获得巨大的知识，而自己却云里雾里？笔者认为，阅读一款优秀的开源框架代码，如果深陷代码细节泥淖中而未曾GET到作者的思想，可能是看了个寂寞。并非细节不重要，而是相比于具体怎么实现的细节，思想上的收获可能来的更有用一些：一旦掌握思想，你也大概率能写出来类似功能的代码，区别仅在于好与坏；如果连思想都未曾学到，区别就是有与无了！
