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

前情回顾

前文,介绍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,继续探测下一个位置,直到找到一个空闲的位置为止,该位置就是最终存储元素的位置,如图示:

image

回到JDK作者解决内存泄露的思路,我们来设想这样一个场景:

假设一名古代强盗,其目的是强劫金银财宝,见人就抢风险大收益低,大部分是贫困百姓,抢了也没几个钱,还冒着暴露的风险;直接上达官贵族家里抢又找不着门路,或许可能更危险,那怎么办呢?

强盗们也不笨:此山是我开,此路是我栽,若要从此过,留下买路财,选择直接在通往城镇的主干道上蹲点,见到衣着华贵带有大批货物,携带的保镖兵团也不强的商人,这大概率就是要下手的目标人群。这里的核心逻辑在于:商人们无论进、出城贸易,都需要经过城镇的主干大道,因此在主干道上蹲点能够【集中兵力】实现效益的最大化

JDK的作者们也是采用了类似的思路:在经常被调用的方法(主干道)上去寻找那些已经不使用的脏数据并清理掉。这种方式能够实现效益的最大化:使用了最低的成本(仅在少数方法内部去做这件事)解决了最大的问题(内存泄露),这也是2\8原则的一种体现

因此,对于ThreadLocal而言,需要识别出哪些方法被经常调用的,然后在这些方法上"动手脚"。如下图示,应该很轻易看出:get、set、remove是最常用的

image

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(脏数据)回收清理掉。现在来看看哪些方法调用了它:

image

我们只看到了一个remove方法,与上面说的set\get\remove好像不太对应?其实只是由于方法分层,没有直接在set\get里调用,没关系,由于调用链路比较深,笔者使用一张简单来表示,有兴趣的看官们可以拿着手中源码一起对照着看

image

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

推荐阅读更多精彩内容