为什么JVM full GC 需要stop-the-world? [英] Why does the JVM full GC need to stop-the-world?

问题描述

我认为是因为 JVM 需要移动对象，对吗?

I think it is because the JVM needs to move objects, is that correct?

推荐答案

首先，垃圾维基百科上的收藏文章真的很好阅读.

一般来说，GC 不需要 Stop-the-World 暂停.有些 JVM 实现(几乎)没有暂停(例如 Azul Zing JVM).JVM 何时需要 STW 收集垃圾取决于它使用的算法.

In general GC does not require Stop-the-World pause. There are JVM implementations which are (almost) pause free (e.g. Azul Zing JVM). Whenever JVM require STW to collect garbage depends on algorithm it is using.

Mark Sweep Compact (MSC) 是 HotSpot 默认使用的流行算法.它以 STW 方式实现，分为 3 个阶段:

Mark Sweep Compact (MSC) is popular algorithm used in HotSpot by default. It is implemented in STW fashion and has 3 phases:

• MARK - 遍历活动对象图以标记可达对象
• SWEEP - 扫描内存以查找未标记的内存
• COMPACT - 重新定位标记的对象以对可用内存进行碎片整理

在堆中重定位对象时，JVM 应该更正对该对象的所有引用.重定位过程中对象图不一致，需要STW暂停.

When relocating objects in the heap, the JVM should correct all references to this object. During the relocation process the object graph is inconsistent, that is why STW pause is required.

并发标记扫描 (CMS) 是 HotSpot JVM 中的另一种算法，它不利用 STW 暂停来收集旧空间(与完全收集不完全相同).

Concurrent Mark Sweep (CMS) is another algorithm in HotSpot JVM which does not utilize STW pause for old space collection (not exactly same thing as full collection).

CMS 正在利用写屏障(每次在 Java 堆中写引用时触发)来实现 MARK 的并发版本，而不使用 COMPACT.缺乏压缩可能会导致碎片，如果后台垃圾收集速度不够快，应用程序仍然会被阻塞.在这些情况下，CMS 将回退到 STW 标记-扫描-紧凑收集.

CMS is utilizing write barrier (trigger acting each time you are writing reference in Java heap) to implement concurrent version of MARK and does not use COMPACT. Lack of compaction may result in fragmentation and if background garbage collection is not fast enough application can still be blocked. In these cases CMS will fallback to STW mark-sweep-compact collection.

还有 G1，它是 MSC 的增量变体.您可以阅读更多关于 HotSpot JVM 中的 GC 算法 在我的博客中.

There is also G1 which is an incremental variation of MSC. You can read more about GC algorithms in HotSpot JVM in my blog.

这篇关于为什么JVM full GC 需要stop-the-world?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！