文末 JVM 思维导图,有需要的可以自取

熟知并发编程的你认为下面这段代码的执行结果是怎么样的?

我如果说,执行流程是:

  1. t1 线程和 t2 线程一直执行 num 的累加操作
  2. 主线程睡眠 1 秒,1 秒之后醒过来打印此时的 num 值
  3. t1 线程和 t2 线程继续执行加 1 的操作,直到执行完 2亿 次累加操作

你赞成吗?

我的猜想看起来没什么问题,但实际运行效果证明了我是错的,下面是运行动图:

从运行动图上可以看到,将代码跑起来之后,却发现实际执行结果是这样的:

1 秒之后,主线程并没有马上打印 num,而是等 t1 和 t2 分别执行完 2 亿次累加操作退出循环后,才会打印 num 的值

这个结果和预想的不一样。我是基于 JDK1.8 跑的,你也可以试试。

为什么会这样呢?

答案是:

JVM 想要执行某个操作,让所有线程进入安全点,但是 t1 和 t2 线程因为 JIT 对可数循环的过渡优化必须等循环跑完了才进入安全点,所以主线程一直再等 t1 和 t2,迟迟不能输出 num 的值。

可数循环:形如 for (int i = 0; i < 100000000; i++) {...}的循环被称为可数循环

简单来说就是:主线程在等 t1 和 t2 线程进入安全点

这个答案的由来,why 神转载的一篇文章:《真是绝了!这段被 JVM 动了手脚的代码!》中已经说的很清楚了,这里不再重复阐述。

此文就源于我当时的一个疑问:JVM 让线程都进入安全点到底干了什么不为人知的事情?

发生了 GC?

难道是发生了 GC 吗?

第一,代码里面没有创建对象申请内存。

第二,加上 -XX:-PrintGC 也没有打印 GC 日志。

第三,执行 jstat 命令,通过输出日志可以看出,JVM 运行期间各个内存区域都没有发生变化,也没有发生 GC。

所以,因为发生了 GC 而需要进入安全点这种情况被排除了。

问题就变成了:没有发生 GC,需要所有的线程都进入安全点干什么?

安全点日志

加上 -XX:+PrintSafepointStatistics 参数,让程序执行的时候打印安全点的相关日志。

可以看到,这段代码的执行一共进行了三次进入安全点。

其中第二个 EnableBiasedLocking 是 JVM 延时开启偏向锁的操作,这个也比较有意思,不过不是文章的重点,下次有机会再说。

我们重点关注的是第一个 no vm operation 操作。将这段日志单独拿出来,在参数说明上加上中文解释:

总结来说就是:

JVM 想执行 no vm operation ,这个操作需要线程都进入安全点,整个期间一共有 12 个线程,正在运行的线程有 2 个,需要等待这两个线程进入安全点,等待这 2 个线程进入安全点并阻塞耗费了 5037 毫秒。

要找出这两个线程也很简单,它不是需要 5000 多毫秒才进入安全点吗,我就加上参数让进入安全点时间超过 5000 毫秒的线程超时就行了。

于是加上 -XX:+SafepointTimeout 和 -XX:SafepointTimeoutDelay=5000 参数,执行代码。

哦豁,这不就是 t1 和 t2 线程吗。

这个结果也是意料之中的,我们的重点是这个 no vm operation 到底是个什么操作?凭什么让主线程等这么久?

源码定位

这个 VM 操作的名字叫做 no vm operation ,翻译成中文就是不是 VM 操作,连起来就是不是 VM 操作的 VM 操作?

一个不是 VM 操作的操作居然也能让全局进入安全点?

那到底是什么操作呢?知识盲区了呀!

一顿谷歌百度,也没有找到一个比较信服的答案。

于是乎,我决定看 JVM 的源码。

在 JVM 源码里面全局搜索 no vm operation ,发现只有 safepoint.cpp 有这个信息。

点击去一看,果然,一下子定位到打印日志的地方,就是这个 SafepointSynchronize::print_statistics() 方法。

其中有一句很关键的代码:

_vmop_type == -1 ?
"no vm operation" :
VM_Operation::name(sstats->_vmop_type)

这是一个三目运算:如果 _vmop_type 等于 -1,打印的安全点日子操作类型那一栏就会输出 no vm operation

而这个 _vmop_typen 呢,是结构体 SafepointStats 中的一个成员,具体的含义是触发安全点的 VM 操作类型

那什么操作类型会将 _vmop_type 设置成 -1 呢?

我在开启安全点方法里面找到了答案:

如果不是 VM 操作触发的安全点事件,这个时候就会将 _vmop_type 设置成 -1。

也就是说还有其他情况也可以触发安全点事件,让所有线程进入安全点。

那么,我们只需要找到触发安全点事件对应的代码就行了。

一个个文件找太难,换个思路,想要进入安全点,必定要调用进入安全点的方法。

而进入安全点的方法就是 safepoint.cpp 里面的 SafepointSynchronize::begin() 方法。

我们只需要全局搜一下哪里调用了这个 SafepointSynchronize::begin() 这个方法应该就能找到触发安全点事件对应的代码。

全局搜索发现只有 vmThread.cpp 里面有调用,vmThread.cpp 封装的都是 VMThread 相关的方法。

VMThread

VMThread 是个什么东西呢?

VMThread 是 JVM 自身启动的一个内部线程,它主要用来协调其它线程达到安全点以及执行 VM 操作。

VM 操作这个概念全文已经多次提到了,那到底有哪些操作是 VM 操作呢?

我们比较熟悉的 CMS 的初始标记和最终标记都是 VM 操作,又比如 thread dump,线程挂起以及偏向锁的撤销等等都是 VM 操作。

VM 操作类型有很多,JVM 对应的源码在 vm_operations.hpp 定义的宏 VM_OPS_DO 里面。

宏 VM_OPS_DO 里面的每个 VM 操作,基本上都有一个单独的子类去实现。

VMThread 里面有个 VMOperationQueue 队列,用于存放一个一个连在一起的 VM 操作。

VMThread 循环执行 VM 操作的方法,叫做 VMThread::loop() 方法。

loop() 方法是 VMThread 的核心方法,该方法不断从 VMOperationQueue 队列中获取待执行的 VM 操作,然后调用每种 VM 操作具体的实现 evaluate() 方法执行不同的逻辑。

这里用了策略模式,VMThread 执行逻辑是固定的,只负责调度,而每种 VM 操作需要根据需求自己实现 evaluate() 方法。

答案出现

而我们上面苦苦寻找的 no vm operation 原因,就在 VMThread 的 loop() 方法里面。

从源码可以看到,在 VM 操作为空的情况下,只要满足以下 3 个条件,也是会进入安全点的:

  1. VMThread 处于正常运行状态
  2. 设计了进入安全点的间隔时间
  3. SafepointALot 是否为 true 或者是否需要清理

程序正常运行 VMThread 肯定能正常运行,所以条件 1 能满足。

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal 2>&1 | grep Safepoint 命令查看 JVM 关于安全点的默认参数,发现 GuaranteedSafepointInterval 默认设置成了 1 秒,所以条件 2 也能满足。

对于条件 3,SafepointALot 默认为 false,那要想条件 3 能满足的话,必须 SafepointSynchronize::is_cleanup_needed()为 true。

点进去看它的具体实现:

通过追踪代码,可以发现 SafepointSynchronize::is_cleanup_needed() 就是判断 StubQueue 里面是否有 stub 缓存。

那 StubQueue 是什么呢?stub 又是什么呢?

这涉及 JVM 的模板解释器和编译器了,由于篇幅有限,下次有机会的话继续深入探讨。

我用一句话概括就是 JVM 执行期间的编译解释代码缓存

清理 stub 你可以简单的理解成清理代码缓存

也就是说,在 JVM 正常运行的时候,如果设置了进入安全点的间隔,就会隔一段时间判断是否有代码缓存要清理,如果有,会进入安全点。

这个触发条件不是 VM 操作,所以会将 _vmop_type 设置成-1,输出日志的时候打印对应的 no vm operation,也就是我们看到的安全点日志。

而文章开头的代码执行效果,主线程一直在等待 t1 和 t2 进入安全点,正是触发了这个条件。

再次验证推论

回过头来再看文章开头的代码,通过加上 -XX:GuaranteedSafepointInterval = 0 将进入安全点间隔时间设置成 0,也就是关闭定时进入安全点,看看代码运行结果是怎么样的。

-XX:GuaranteedSafepointInterval 是诊断性质的参数,需要加上-XX:+UnlockDiagnosticVMOptions 参数解锁诊断参数方可使用。

从运行结果上可以看到,关闭过一段时间进入安全点的设置之后,主线程睡了 1 秒后,不再需要等待 t1 和 t2 线程循环执行完,睡完之后马上就打印了此时的 num 值。

这样的运行结果,也再一次的验证了我们的推论。

间隔一秒进入安全点的设置还是有它的作用的,我建议你别去动它。

-XX:GuaranteedSafepointInterval 是个诊断性质的参数,不建议线上使用。

从网上的文献来看,关掉这个参数也有可能会造成一些未知错误,具体是什么错误我也没有遇见过,也不知道是真是假。

总之,线上环境谨慎一点总没错,如果你对 JVM 底层不是很熟悉的话,我建议还是别去动它。

有趣的注释

知识点分享到这里就结束了,分享一个有趣的事情。

在我追踪 JVM 源码的过程中,我发现编写 StubQueue 的作者留下了这样一段注释:

我润色翻译一下就是:在你不能证明你改的没问题的时候,别特么乱动我代码,这段代码比你想象中牛逼的多

看到没有,这就是大神的骄傲和自信!

反观我呢,我平时给代码写注释的时候,只敢在上面写:如果你看到我的代码有 BUG,麻烦帮我修一下,谢谢了

从写注释的骄傲和自信上就能看得出,我和大神差距有多大了。

我一定要加油,以后也能写出这样霸气的注释!

思维导图

我把我个人觉得重要的 JVM 知识点,按照自己理解思路整理成了一个思维导图。

有需要的可以自取就行,如果图片被平台压缩了,你可以公众号后台回 JVM 获取高清图片。

需要强调的是,这是我整理的知识点,里面的知识并不是我原创的。

我没有创造知识,只是分享自己如何学习和理解知识。

思维导图的制作参照了大量的书籍和博客,包括但不限于《深入理解 Java 虚拟机》、美团技术团队文章、阿里技术团队文章、R 大的文章、寒泉子大大的调优文章。

好了,今天的文章就到此结束了。

我是 CoderW,一个有时候喜欢钻牛角尖的程序员,我们下期再见!

没有发生GC也进入了安全点?这段关于安全点的JVM源码有点意思!的更多相关文章

  1. JVM 源码解读之 CMS 何时会进行 Full GC

    t点击上方"涤生的博客",关注我 转载请注明原创出处,谢谢!如果读完觉得有收获的话,欢迎点赞加关注. 前言 本文内容是基于 JDK 8 在文章 JVM 源码解读之 CMS GC 触 ...

  2. jvm源码解读--14 defNewGeneration.cpp gc标记复制之后,进行空间清理

    进入Eden()->clean()函数 void EdenSpace::clear(bool mangle_space) { ContiguousSpace::clear(mangle_spac ...

  3. Golang源码探索(三) GC的实现原理(转)

    Golang从1.5开始引入了三色GC, 经过多次改进, 当前的1.9版本的GC停顿时间已经可以做到极短.停顿时间的减少意味着"最大响应时间"的缩短, 这也让go更适合编写网络服务 ...

  4. 源码分析HotSpot GC过程(三):TenuredGeneration的GC过程

    老年代TenuredGeneration所使用的垃圾回收算法是标记-压缩-清理算法.在回收阶段,将标记对象越过堆的空闲区移动到堆的另一端,所有被移动的对象的引用也会被更新指向新的位置.看起来像是把杂陈 ...

  5. 【转】.NET(C#):浅谈程序集清单资源和RESX资源 关于单元测试的思考--Asp.Net Core单元测试最佳实践 封装自己的dapper lambda扩展-设计篇 编写自己的dapper lambda扩展-使用篇 正确理解CAP定理 Quartz.NET的使用(附源码) 整理自己的.net工具库 GC的前世与今生 Visual Studio Package 插件开发之自动生

    [转].NET(C#):浅谈程序集清单资源和RESX资源   目录 程序集清单资源 RESX资源文件 使用ResourceReader和ResourceSet解析二进制资源文件 使用ResourceM ...

  6. Go语言GC实现原理及源码分析

    转载请声明出处哦~,本篇文章发布于luozhiyun的博客:https://www.luozhiyun.com/archives/475 本文使用的 Go 的源码1.15.7 介绍 三色标记法 三色标 ...

  7. GC 源码分析

    java对象的内存分配入口 Hotspot 源码解析(9) •内存代管理器TenuredGeneration对垃圾对象的回收2015-01-18阅读1154 •内存代管理器DefNewGenerati ...

  8. CoreCLR源码探索(三) GC内存分配器的内部实现

    在前一篇中我讲解了new是怎么工作的, 但是却一笔跳过了内存分配相关的部分. 在这一篇中我将详细讲解GC内存分配器的内部实现. 在看这一篇之前请必须先看完微软BOTR文档中的"Garbage ...

  9. linux中断源码分析 - 中断发生(三)

    本文为原创,转载请注明:http://www.cnblogs.com/tolimit/ 回顾 上篇文章linux中断源码分析 - 初始化(二)已经描述了中断描述符表和中断描述符数组的初始化,由于在初始 ...

随机推荐

  1. 2019_西湖论剑_预选赛 testre

    2019_西湖论剑_预选赛 testre 程序中关键操作是比较ptr,其中夹杂的一部分v26计算是为了混淆我们的分析.那么我们只要跟踪ptr数组的生成便可,向上发现v11,加密操作数组. 接下来跟踪v ...

  2. 敏捷史话(十二):你现在接触的敏捷也许是“黑暗敏捷”——Ron Jeffries

    他很少提起往事,也不再提及二十年前那场引起软件行业变革的会议,他专注于当下,一直活跃在敏捷领域.八十多岁的他依然运营维护着网站和博客,是极限编程网站 XProgramming.com 的作者,该网站是 ...

  3. 快速排序(QuickSort)Java版

    快速排序 快速排序是对冒泡排序的一种改进. 它的基本思想是:通过一趟排序将要排序的数据分割成独立的两部分,其中一部分的所有数据都比另外一部分的所有数据都要小,然后再按此方法对这两部分数据分别进行快速排 ...

  4. jenkins构建maven聚合项目,发布jar包,可配置单独发布某个模块

    https://blog.csdn.net/qq_42703181/article/details/109643330

  5. 茫茫内存,我该如何用 windbg 找到你 ?

    一:背景 1. 讲故事 前天wx上有个朋友丢给我一个dump,让我帮忙鉴定一下某些敏感信息在内存中是否也是加密的,现在数据安全很重要,不仅数据库中的信息要加密,灌到内存后数据同样也需密文存储,随用随解 ...

  6. SAP QM 检验批跳号解决

    SAP QM 检验批跳号解决 在生产系统中,发现存在检验批规则或不规则跳号问题. 首先,查看事务代码SNRO编号范围对象QLOSE中BUFFER字段值,将其设置为NO BUFFER(无缓冲) 如果还存 ...

  7. Mediapipe 在RK3399PRO上的初探(一)(编译、运行CPU和GPU Demo, RK OpenglES 填坑,编译bazel)

    PS:要转载请注明出处,本人版权所有. PS: 这个只是基于<我自己>的理解, 如果和你的原则及想法相冲突,请谅解,勿喷. 前置说明   本文作为本人csdn blog的主站的备份.(Bl ...

  8. 「starter推荐」简单高效Excel 导出工具

    EasyExcel EasyExcel是一个基于Java的简单.省内存的读写Excel的开源项目.在尽可能节约内存的情况下支持读写百M的Excel. 64M内存1分钟内读取75M(46W行25列)的E ...

  9. Ambassador-04- Mapping 资源

    官方文档:https://www.getambassador.io/docs/latest/topics/using/intro-mappings/#resources Ambassador 通过Ma ...

  10. Day06_30_抽象类(Abstract)

    抽象类 Abstract 什么是抽象类? 在面向对象的概念中,所有的对象都是通过类来描绘的,但是反过来,并不是所有的类都是用来描绘对象的,如果一个类中没有包含足够的信息来描绘一个具体的对象,这样的类就 ...