Stop The World

举报
SHQ1874009 发表于 2024/01/18 21:20:30 2024/01/18
【摘要】 一、前言小伙伴还记得《JVM进阶(七):从 GC 日志分析堆内存》中我们留下的一个问题吗?什么是停顿类型!经过前面的学习,我们知道JVM垃圾回收首先是需要经过标记的。对象被标记后就会根据不同的区域采用不同的收集方法。看上去很完美的一件事情,其实并不然。 二、STW大家有没有想过这样一件事情,当虚拟机完成两次标记后,便确认了可以回收的对象。但是,垃圾回收并不会阻塞我们程序的线程,他是与当前程...

一、前言

小伙伴还记得《JVM进阶(七):从 GC 日志分析堆内存》中我们留下的一个问题吗?什么是停顿类型!经过前面的学习,我们知道JVM垃圾回收首先是需要经过标记的。对象被标记后就会根据不同的区域采用不同的收集方法。看上去很完美的一件事情,其实并不然。

二、STW

大家有没有想过这样一件事情,当虚拟机完成两次标记后,便确认了可以回收的对象。但是,垃圾回收并不会阻塞我们程序的线程,他是与当前程序并发执行的。所以问题就出在这里,当GC线程标记好了一个对象的时候,此时我们程序的线程又将该对象重新加入了“关系网”中,当执行二次标记的时候,该对象也没有重写finalize()方法,因此回收的时候就会回收这个不该回收的对象。

虚拟机的解决方法就是在一些特定指令位置设置一些“安全点”,当程序运行到这些“安全点”的时候就会暂停所有当前运行的线程(Stop The World 所以叫STW),暂停后再找到“GC Roots”进行关系的组建,进而执行标记和清除。

这些特定的指令位置主要在:

  • 循环的末尾;
  • 方法临返回前 / 调用方法的call指令后;
  • 可能抛异常的位置;

找到“GC Roots”也是要花很长的时间,然而这里又有新的解决方法,就是通过采用一个OopMap的数据结构来记录系统中存活的“GC Roots”,在类加载完成的时候,虚拟机就把对象内偏移量上的类型数据计算出来保存在OopMap,通过解释OopMap就可以找到堆中的对象,这些对象就是GC Roots。而不需要一个一个的去判断某个内存位置的值是不是引用。这种方式也叫准确式GC

回到最开始的问题,那个停顿类型就是刚刚所说的STW,至于有GCFull GC之分,还有Full GC (System)。个人认为主要是Full GCSTW的时间相对GC来说时间很长,因为Full GC针对整个堆以及永久代的,因此整个GC的范围大大增加;还有就是JVM回收算法就是我们之前说过的“标记–清除–整理”,这里也会损耗一定的时间。所以在优化JVM的时候,减少Full GC的次数也是经常用到的办法。

本文篇幅较短,主要为下一章要讲的收集器打下基石,各位只要知道GC之前还有STW这一步骤和知道OopMap以及安全点的存在即可。

三、拓展阅读

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。