ThreadLocal系列之——JDK为内存泄露做的努力(三)

最新推荐文章于 2023-03-27 22:17:17 发布

置顶神的力量

最新推荐文章于 2023-03-27 22:17:17 发布

阅读量401

点赞数 2

分类专栏： java 文章标签： java

本文链接：https://blog.csdn.net/qq271859852/article/details/108423626

版权

java 专栏收录该内容

24 篇文章 6 订阅

订阅专栏

前情回顾

前文，介绍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到作者的思想，可能是看了个寂寞。并非细节不重要，而是相比于具体怎么实现的细节，思想上的收获可能来的更有用一些：一旦掌握思想，你也大概率能写出来类似功能的代码，区别仅在于好与坏；如果连思想都未曾学到，区别就是有与无了！