侧边栏壁纸
博主头像
why

一个主要敲代码,经常怼文章,偶尔拍视频的成都人。

  • 累计撰写 197 篇文章
  • 累计创建 11 个标签
  • 累计收到 101 条评论

JDK的BUG导致的内存溢出!反正我是没想到还能有续集。

why
why
2020-07-19 / 0 评论 / 0 点赞 / 205 阅读 / 5,837 字
温馨提示:
关注公众号why技术,第一时间接收最新文章。

BUG到底是怎么修复的?

上周《我的程序跑了60多小时,就是为了让你看一眼JDK的BUG导致的内存泄漏》这篇文章发布后。

有好几个同学都来问了我一些相关的问题。

比如这样的:

写上篇文章的时候,我的侧重点主要在 ConcurrentLinkedQueue(下文统一缩写 CLQ)存在过一个可能会导致内存泄漏的 BUG ,这个 BUG 的来龙去脉是怎样的,以及怎么通过可视化工具让我们感受到这个 BUG 的存在。

其实对于 BUG 在源码里面具体是怎样体现的,以及修改之后为什么就不会内存泄漏了并没有进行详细的解读。

开始的想法是,告诉大家有这个事情,如果有兴趣的可以直接去调试分析一下。

但是有的同学反映调试也看不明白啊。一个方法,在断点处一脸懵逼的进来,又一脸懵逼的出去。

苦思冥想没搞清楚,然后就来问我。

我发现一两句话也说不太清楚,于是把 Debug 的关键截图放到文档里面配以文字说明,才勉强能说的比较清楚一点,也不知道这位同学看明白了没。

但就拿这个文档来说:真的是暖男石锤了。

所以,文本主要是分享一个我自己调试的奇淫技巧,最后再做个 remove 方法的解读。

但是如果要深刻理解 CLQ 这个十分优秀、十分有想法的基于非阻塞方法实现的线程安全的队列,大家需要去看的是 offer、poll 方法。然后一个情况一个情况的去分析,自己拿着草稿本在上面写写画画。

我也妄想过通过这篇文章给你们把它讲的明明白白的,后来我发现这对我而言难度有点大。

最后再说一下如果你用 IDEA 调试时,大概率会碰到的一个巨坑。

好了,先把之前的这个坑给填上。

修复之后的 JDK8 到底怎么就避免了内存泄漏的问题了?

自定义CLQ

我们先看一下 CLQ 的数据结构。

CLQ 的 Node 里面有一个 item(放的是存储的对象),还有一个 next 节点(指向的是当前 Node 的下一个节点)。

从数据结构来看,也知道这是一个单向链表了。

Java 程序员,就靠日志活着的。

所以我想通过日志的方式直接输出链表结构,这应该是最简单的演示方式了。

为了通过日志体现出数据变化的过程,我们先来一个自定义的 CLQ。

方法很简单,直接把 JDK 8 的 CLQ 复制出来一份,然后修改名称就可以,我们这里的名称是 whyConcurrentLinkedQueue(下文简写为 WhyCLQ):

搞一个测试用例跑一下:

然后你会发现报错了:

这个错误是关于 Unsafe 操作的,在代码的第 931 行:

getUnsafe 方法的源码是这样的:

而这个方法里面就是判断当前类的类加载器是不是为 null:

这里抛出异常了,说明不是 null。也就会说当前类的加载器不是启动类加载器 BootstrapClassLoader。

我们知道,rt.jar 包下的类是需要 bootstrap 类加载器加载的。

诶,巧了。这个类就位于 rt.jar 包里面:

来,再复习一下双亲委派机制:

如果我们自定义了一个 CLQ ,那么这个类的类加载器是什么类加载器呢?

我们验证一下:

从 Debug 的截图可以看出当前类 WhyCLQ 的类加载器是 AppClassLoader。其父类加载器(parent)是 ExtClassLoader 类加载器。

不是 BootstrapClassLoader ,所以我们这里抛出了异常。

在介绍怎么解决这个异常之前,先简单的说一下 Unsafe。

这个类名称一听就是非常牛逼的。Unsafe,不安全。

感觉像是在钓鱼执法,表面上疯狂的在那给你摆手,说:别靠近我,别使用我,我很不安全。

实际上内心是这样的:

作为一个正常的男人,看到这个东西谁不想去调用一下,看看到底是怎么不安全的呢?

我们看一下《美团点评 2019 技术年货》里面是怎么描述的:

同时,看一下它相关的 API:

由于 Unsafe 不是文本重点,我就不展开说明了。如果你对 Unsafe 这个类掌握的还不深刻,建议你好好了解一下。如果你清楚的知道这个类的威力,在某些场景下可以达到意想不到的效果,它就是一枚银弹般的存在。

在《美团点评 2019 技术年货》里面有一小节是专门分享这个类的,有兴趣的朋友可以查看文末获取方式。

好了,知道抛出问题的原因了,我们自定义的 CLQ 就不能用了吗?

当然不是,别忘了,我们还有极其“流氓”的反射方法可以使用:

这样,我们自定义的 CLQ 就可以使用了。免费附赠你一个 Unsafe 的知识,不用谢。

接下来我们就可以在不修改源码逻辑的情况下,加入输出语句以方便调试。

比如我们需要这样清晰的输出日志:

所以在我们自定义的 CLQ 里面加一个打印链表结构的方法:

然后给我们的 remove 方法增加一个循环次数的入参,并在操作队列之前和之后调用我们打印链表结构的方法,就像下面这样式儿的:

其中的 printWhyCLQ 方法如下:

有的朋友肯定注意到了,我这个方法名称是 removeJDK8 。这个方法里面的逻辑就是 JDK8 的 CLQ 的 remove 方法。

你可以这么理解:我就是把 JDK8 的 CLQ 的 remove 方法的名称变成了 removeJDK8 。

为什么这样命名呢?

因为我要把 JDK7 对应的 remove 方法直接拿过来,放在同一个类里面方便调用,操作和上面的 JDK8 方法一致:

这样,我们就有一个自定义的 CLQ,里面包含 JDK7 和 JDK8 对应的 CLQ 的 remove 方法。

万事俱备,就差个 Demo 跑起来了:

在下面一小节中,我们对比一下修复前(JDK7)和修复后(JDK8)的输出日志,一切就会非常的明了。

修复前 vs 修复后

我们把 Demo 跑起来,看输出结果,进行对比:

你仔细品这个输出结果,还需要我给你分析个啥玩意?

和 JDK8 的方法比起来,上面 JDK7 的方法执行完成后链表长度都长了一些。

JDK8 的方法执行完成后,链表长度最长也没有超过 3 个。

我们再看 JDK7,我拿一次循环出来分析:

这就是我上篇文章中说到的:一个节点中的 item 对象被置为 null 了,但是该节点,由于代码问题,并没有从链表中取下来,导致不能被回收。

而上篇文章中提到的“越来越慢”,由于可以直接的看到链表结构了,所以也很好解释了:

比如,我把 Demo 中 for 循环的次数修改为 100,运行之后,我们看最后一次循环的结果为:

remove 方法是从链表的头结点开始遍历链表,而我们每次需要移除的其实是最后一个节点,由于链表越来越长,所以遍历链表的时间越来越长。

所以导致我们上一篇的案例中每循环 10000 次,时间都会增加。

源码导读

接下来我们看一下 JDK8 的源码中的 remove(obj) 方法到底是怎么样工作的。

这个方法的目的就是从头结点开始遍历链表,然后判断每个 Node 里面的 item 是不是需要被删除的这个,如果是则删除,如果不是则继续遍历。

我想了很久这个地方怎么能把代码的执行流程说清楚呢?

除了 Debug 之外,因为 Debug 需要截非常多的图才可能说的清楚。

只有疯狂的输出日志了。

我们先看简单的分析一下 JDK8 对应的源码:

490 行是在对象被移除之前,我们可以在这里加一行输出语句打印当前的链表结构。

505 行是在对象被移除之后,我们可以在这里加一行输出语句打印删除操作完成之后的链表结构。

纵观整个方法,只有我标注的两个地方会去修改链表结构。所以,我们分别在这两处地方的前后输出相关日志,然后分析日志,就可以知道这个方法的工作流程了。

知道它的工作流程了,再返回去看代码,那还不是易如反掌的事儿?

这就是传说中的蛇皮走位,反向操作。

所以,按照我们上面的分析,在自定义的 CLQ 里面加入输出语句如下:

其中的 sortName 方法是为了把 java.lang.Object@xxx 截取为 @xxx,精简输出:

上面的 removeJDK8 方法除了输出语句之外,其他的代码逻辑和 JDK8 的对应方法一模一样。

我们还是用这个示例代码:

跑起来分析日志:

日志很多,但是细细分析下来流程非常的清晰,你可以在草稿本上画一画。

我带着大家分析前两个循环,一共 10 行日志,我们一行行的分析,注意我们下面画的图仅体现了 node 里面的 item 元素:

第【0】次循环,【移除之前】,链表item对象指向 = @723279cf->@10f87f48->

从测试代码中可以知道,被删除之前我们确实是有两个节点:

所以根据日志画图如下:

第【0】次循环,【修改节点item为null】被修改的p节点的item为(@10f87f48),即需要被删除的节点

第【0】次循环,【修改节点item为null之后】,链表item对象指向 = @723279cf->null->

第【0】次循环,【移除之后】,链表item对象指向 = @723279cf->null->

其实移除之后,就是把节点的 item 修改为 null 之后,所以结构和上面还是一样的:

第【0】次循环就分析完了。可以看到现在的链表里面有一个 item 为 null 的元素,它还在链上,所以不会被回收。

接下来,我们分析一下第【1】次循环。

第【1】次循环,【移除之前】,链表item对象指向 = @723279cf->null->@10f87f48->

由于进入下次循环,所以会先执行 add 方法,所以现在的链表结构变成了这样:

第【1】次循环,【处理null节点】把item为(@723279cf)的pred节点的next节点,从item为(null)的p节点修改为item为(@10f87f48)的next节点

pred 节点里面的 item 就是 @723297cf。

p 节点里面的 item 就是 null。

next 节点里面的 item 就是 @10f87f48。

第【1】次循环,【处理null节点之后】,链表item对象指向 = @723279cf->@10f87f48->

第【1】次循环,【修改节点item为null】被修改的p节点的item为(@10f87f48),即需要被删除的节点

第【1】次循环,【修改节点item为null之后】,链表item对象指向 = @723279cf->null->

第【1】次循环,【移除之后】,链表item对象指向 = @723279cf->null->

第【1】次循环完成后又回到了第【0】次循环完后的样子。

中间的那个 item 为 null 的节点去哪了呢?

因为这是个单向链表,从头节点已经不能遍历到这个节点了。所以等待它的命运将是被回收,所以也就不会内存溢出了。

到这里,我觉得这个问题算是回答清楚了吧?

关于 remove(obj) 我就分享到这里。

实话实话,这个方法对于 CLQ 并不是非常的重要,我们一般使用场景也比较少。

我写这节主要是两个目的。

一是回答读者的提问,因为毕竟是看了我的文章引发出来的问题,我有义务回答。

二是分享一下这种自己 copy 一个类出来,然后只加入输出语句的调试方式。这个调试方法老读者肯定知道了,我在写 ArrayList 的时候也用过,写 Dubbo 负载均衡算法的时候也用过。当你被一步步 debug 带晕的时候,你可以试一试这种方式,先整体再局部。比如本文的 CLQ,多线程调试 CLQ 的情况下,我觉得日志的输出对于你理解它的精髓非常的有帮助。

还是之前说过的,如果要深刻理解 CLQ 这个十分优秀、十分有想法的基于非阻塞方法实现的线程安全的队列,大家需要去看的是 offer、poll 方法。然后一个情况一个情况的去分析,看看它是怎么避免频繁 CAS 的,自己拿着草稿本在上面写写画画。

我也妄想过通过这篇文章给你们把它讲的明明白白的,后来我发现这对我而言难度有点大。

我在这里给大家指个路,看哪几种情况:

  • 单线程下的 offer。
  • 单线程下的 poll。
  • 多线程下的一个线程 offer ,一个线程 poll。offer 比 poll 快。
  • 多线程下的一个线程 offer ,一个线程 poll。offer 比 poll 慢。

就这四种情况,玩去吧。

一种非常优秀的思想,非常牛逼的实现,我希望你能静下心来坚持过半小时。

IDEA DEBUG 模式的巨坑

看了我上面的介绍,准备静下心来看第一种情况:单线程下的 offer。

如果你用 IDEA 的 Debug 调试 CLQ 的 offer 方法,半个小时后你心态应该就会炸裂:

你有可能会碰到的一个巨坑,比如我们的测试代码是这样的:

非常简单,在队列里面添加一个元素。

由于初始化的情况下 head=tail=new Node(null):

所以在 add 方法被调用之后的链表结构里面的 item 指向应该是这样的:

我们在 offer 方法里面加入几个输出语句:

执行之后的日志是这样的:

为什么最后一行输出,【offer之后】输出的日志不是 null->@723279cf 呢?

因为这个方法里面会调用 first 方法,获取真正的头节点,即 item 不为 null 的节点:

到这里都一切正常。但是,当你用 debug 模式操作的时候就不太一样了:

头节点的 item 不为 null 了!而头节点的下一个节点为 null,所以抛出空指针异常。

单线程的情况下代码直接运行的结果和 Debug 运行的结果不一致!这不是遇到鬼了吗。

我在网上查了一圈,发现遇到鬼的网友还不少。

最终找到了这个地方:

https://stackoverflow.com/questions/55889152/why-my-object-has-been-changed-by-intellij-ideas-debugger-soundlessly

这个哥们遇到的问题和我们一模一样:

这个问题下面只有一个回答:

你知道回答这个问题的哥们是谁吗?

IDEA 的产品经理,献上我的 respect。

最后的解决方案就是关闭 IDEA 的这两个配置:

因为 IDEA 在 Debug 模式下会主动的帮我们调用一次 toString 方法,而 toString 方法里面,会去调用迭代器。

而 CLQ 的迭代器,会触发 first 方法,这个里面和之前说的,会修改 head 元素:

一切,都真相大白了。

之前,我认为是玄学。而现在,没有什么是玄学,我们要相信科学。

我身边也有朋友碰到过这个问题,如果不知道这个坑,非常的抠脑壳,很容易就“怀疑人生”了:

最后说一句

文章中提到的《美团点评 2019 技术年货》是公众号【美团技术团队】 2019 年出品的后台技术文章集合,内容非常的丰富:

如果你有兴趣,可以在公众号后台回复关键字【 java
】即可获得 PDF 的下载链接。

好了,看到了这里了,关注一下我的公众号[why技术]吧,文章写好后第一时间会先发布在公众号里面。

写文章很累的,需要一点正反馈。你的关注,就是强有力的正反馈!

才疏学浅,难免会有纰漏,如果你发现了错误的地方,还请你留言给我指出来,我对其加以修改。

抱拳了,铁子!

0

评论区