性能文章>JVM 锁 bug 导致 G1 GC 挂起问题分析和解决>

JVM 锁 bug 导致 G1 GC 挂起问题分析和解决原创

2054012

编者按:笔者在AArch64中遇到一个G1 GC挂起,CPU利用率高达300%的案例。经过分析发现问题是由JVM的锁机制导致,该问题根因是并发编程中没有正确理解内存序导致。本文着重介绍JVM中Monitor的基本原理,同时演示了在什么情况下会触发该问题。希望通过本文的分析,读者能够了解到内存序对性能、正确性的影响,在并发编程时更加仔细。

现象

本案例是一个典型的弱内存模型案例,大致的现象就是AArch64平台上,业务挂死,而进程占用CPU持续维持在300%。配合top和gdb,可以看到是3个GC线程在offer_termination处陷入了死循环:
image.png

多个并行GC线程在Minor GC结束时调用offer_termination,在offer_termination中自旋等待其他并行GC线程到达该位置,才说明GC任务完成,可以终止。(关于并行任务的中止协议问题,可以参考相关论文,这里不做着重介绍。简单地说,在并行任务执行时,多个任务之间可能存在任务不均衡,所以JVM内部设计了任务均衡机制,同时必须设计任务终止的机制来保证多个任务都能完成,这里的offer_termination就是尝试终止任务)。

在该案例中,部分GC线程完成自己的任务,等待其他的GC线程。此时出现挂起,很有可能是因为发生了死锁。所以问题很可能是由于那些尚未完成任务的GC线程上错误地使用锁。

所以使用gdb观察了一下其他GC线程,发现其他GC线程全都阻塞在一把JVM的锁上:
image.png
而这把Monitor中的情况如下:

  1. cxq上积累了大量GC线程
  2. OnDeck记录的GC线程已经消失#
    5._owner记录的锁持有者为NULL

分析

在进一步分析前,首先普及一下JVM锁组件Monitor的基本原理,Monitor类主要包含4个核心字段:

1. “Thread * volatile _owner;”字段指向这把锁的持有线程

2. “SplitWord _LockWord;”字段被设计为1个机器字长,目的是为了确保操作时天然的原子性,它的最低位被设计为上锁标记位,而高位区域用来存放256字节对齐的竞争队列(cxq)地址

3. “ParkEvent * volatile _EntryList;”字段指向一个等待队列,跟cxq差别不大,个人理解只是为了缓解cxq的竞争压力而设计

4. “ParkEvent * volatile _OnDeck;”字段指向这把锁的法定继承人,同时最低位还充当了内部锁的角色

接下来通过一组流程图来介绍加解锁的具体流程:
image.png
上图是加锁的一个整体流程,大致分为3步:

1. 首先走快速上锁流程,主要对应锁本身无人持有的最理想情况

image.png

2. 接着是自旋上锁流程,这是预期将在短时间内获取锁的情况
image.png
3. 最后是慢速上锁流程,申请者将会加入等待队列(cxq),然后进入睡眠,直到被唤醒后发现自己变成了法定继承者,于是进入自旋,直到完成上锁。
image.png
而且,基于性能考虑,整个上锁流程中的每一步几乎都做了“插队”的尝试:
image.png
如上图代码中所示,“插队”的意思就是不经过排队(cxq),直接尝试置上锁标志位。
image.png
上图就是整个解锁流程了,显然真正的解锁操作在第二步中就已经完成了(意味着接下来时刻有“插队”现象发生),剩下的主要就是选出继承者的过程,大致分为以下几步:

1. 解锁线程首先需要将内部锁(_OnDeck)标记上锁

2. 从竞争队列(cxq)抽取所有等待者放入等待队列(_EntryList)

3. _ EntryList取出头一个元素,写入_OnDeck的同时解除内部锁标记,这代表选出了继承者

4. 唤醒继承者

当然伴随着整个解锁流程每一步的,还有对“插队”行为的处理。

至此,JVM锁组件Monitor的原理就介绍到这里,再回归到问题本身,一个疑问就是_OnDeck上记录的继承者为何消失?作为继承者,既然已经消失在竞争队列和等待队列里,显然意味着它大概率已经持有锁、然后解锁走人了,所以问题很可能跟继承者选取过程有关。基于这种猜测,我们对相关代码着重进行了梳理,就发现了下图两处红框标记位置存在疑点,那就是在选继承者过程第3步中:

image.png

写_ EntryList和写_OnDeck之间没有barrier来保证执行顺序,这可能出现_OnDeck先于_ EntryList写入的情况,一旦继承人提前持有锁,后果就可能非常糟糕…
image.png
这里贴了一张可能的问题场景:

1. 线程A处于解锁流程中,由于乱序,先写入了继承者同时解除内部锁

2. 线程B处于上锁流程,发现自己就是法定继承者后,立刻完成上锁

3. 线程B又迅速进入解锁流程,并从_EntryList中取出头元素(也就是线程B!)作为继承者写入_OnDeck,完成解锁走人

4. 线程A此时才更新_EntryList,然后唤醒继承者(也就是线程B!),完成解锁走人

5. _OnDeck上的继承者线程B,实际已经完成加解锁离开,后续等待线程再也无法被唤醒

正巧在社区的高版本上找到了一个相关的修复记录(JDK- 8166197),这里贴出2个关键的代码片段:
image.png
上面这段代码位于慢速上锁流程,被唤醒后检查继承者是否是自己,修复后的代码在读_OnDeck时加了Load-Acquire的barrier。

image.png

上面这段代码位于解锁时选继承者流程,从_ EntryList取出头一个元素,写入_OnDeck的同时解除内部锁标记,修复后的代码在写_OnDeck时加了Store-Release的barrier。

显然,围绕_OnDeck添加的这对One-way barrier可以确保:当继承者线程被唤醒时,该线程可以“看”到_EntryList已经被及时更新。

总结

在AArch64这种弱内存模型的平台上(关于内存序更多的知识在接下来的分享中会详细介绍),一旦涉及多线程对公共内存的每一次访问,必须反复确认是否需要通过barrier来严格保序,而且除非存在有效的依赖关系,否则barrier需要在读写端成对使用。

后记

本文是JDK技术剖析系列的第二篇,第一篇介绍的通过perf解决JDK8u小版本升级后的性能问题,具体见链接https://heapdump.cn/article/2533149。

如果遇到相关技术问题(包括不限于毕昇JDK),可以通过毕昇JDK社区求助(目前毕昇JDK最新的官网http://bishengjdk.openeuler.org已经上线,可以点击原文进入官网查找所有相关资源,包括二进制下载、代码仓库、使用教学、安装、学习资料等)。毕昇JDK社区每双周周二举行技术例会,同时有一个技术交流群讨论GCC、LLVM、JDK和V8等相关编译技术,感兴趣的同学可以添加如下微信小助手,回复Compiler入群。

image.png

请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
线程池运用不当的一次线上事故
在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高
YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
【活动结果公布:兑奖见置顶评论】每日一签到,解锁你的PerfMa壕礼
叮......Perfma达人福利发车啦!社区每日签到解锁活动上线啦~除了每日签到必得积分奖励外,还为大家增加了壕礼相赠、解锁Perfma终极大奖等环节奖励 ~来Perfma社区留下你的签到足迹,告诉
使用Top_X插件排查内存过载问题
Top命令是Linux 系统下常用的监控工具,用于实时获取进程级别的 CPU 或内存使用情况。XPocket中的Top_X为Linux Top的增强版,可以显示CPU占用率/负载,CPU及内存进程使用
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
记一次类加载失败导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。这一次碰到了一个类加载失败导致的性能问题。用文字记录下了问题的整个发
一次大量 JVM Native 内存泄露的排查分析(64M 问题)
我们有一个线上的项目,刚启动完就占用了使用 top 命令查看 RES 占用了超过 1.5G,这明显不合理,于是进行了一些分析找到了根本的原因,下面是完整的分析过程,希望对你有所帮助。会涉及到下面这些内容Linux 经典的 64M 内存问题堆内存分析、Native 内存分析的基本套路