Java垃圾收集总是必须“停止世界”吗？ [英] Does Java Garbage Collect always has to "Stop-the-World"?

问题描述

我试图更深入地理解Java的垃圾收集。

I am trying to understand Java's garbage collection more deeply.

在HotSpot JVM世代集合中，在堆中，有三个区域（Young generation，Old generation和永久性的一代）。此外，还有两种算法：

In HotSpot JVM generational collection, in the heap, there are three areas (Young generation, Old generation and permanent generation). Also, there are two kinds of algorithms:

1） Mark Sweep Compact 。

2）并发标记和扫描。

GC是否需要Stop-the-world取决于它使用的算法是否正确而不是它在哪一代运作？换句话说，如果我在所有三个区域使用1）作为GC算法，STW将永远发生？

Is that true whether GC needs "Stop-the-world" depends on the algorithm it uses rather than which generation it operates on? In another word, if I use 1) as GC algorithm on all three areas, STW will always happen ?

另外，我理解差异是第二个GC算法没有'需要压缩，最终会导致碎片化。那么第二个问题是为什么压缩需要STW暂停？

Also, I understand the difference is the second GC algorithm doesn't require Compaction which will result in fragmentation eventually. So the second question comes to why the compaction needs a STW pause?

推荐答案

压缩导致STW暂停的关键原因如下，JVM需要移动对象并更新对它的引用。现在，如果您在更新引用之前移动对象，并且正在运行的应用程序从旧引用访问它而不是有问题。如果您首先更新引用并且尝试移动对象，则更新的引用是错误的，直到移动对象并且对象未移动时的任何访问都将导致问题。

Key reason why compaction leads to STW pause is as follows, JVM needs to move object and update references to it. now if you move object before updating the references and application that is running access it from old reference than there is trouble. if you update reference first and than try to move object the updated reference is wrong till object is moved and any access while object has not moved will cause issue.

对于两个CMS和并行收集器年轻代收集算法是相似的，它停止世界，即收集发生时应用程序停止
JVM正在做的事情是，标记从根集可到达的所有对象，将对象从Eden移动到幸存者空间并且将已经超过终点阈值的集合中的对象移动到旧代。当然，JVM必须更新对已移动的对象的所有引用。

For both CMS and Parallel collecter the young generation collection algorithm is similar and it is stop the world ie application is stopped when collection is happening Stuff JVM is doing is, marking all objects reachable from root set, moving the objects from Eden to survivor space and moving objects that have survived collections beyond tenuring threshold to the old generation. Of course JVM has to update all the references to the objects that have moved.

对于旧代并行收集器，在一次停止中执行所有标记，压缩和引用更新世界（STW）阶段，这导致GB中的堆数暂停几秒钟。对于具有严格响应时间要求的应用程序来说，这很痛苦。到目前为止，Paralle collector仍然是吞吐量或批处理的最佳收集器（在Oracle Java中）。事实上，我们已经看到了同样的情况，即使停顿时间比CMS更多并行收集器仍然可以获得更高的吞吐量，我认为这与更紧凑的空间局部性有关。

For old generation parallel collector is doing all marking, compaction and reference updates in a single stop the world(STW) phase, this leads to pauses in seconds for heaps in GBs. This was painful for the applications that have strict response time requirements. Till date Paralle collector is still the best collectors(among Oracle Java) for throughput or batch processing. In fact we have seen for same scenario even if time spent in pauses is more in parallel collector than CMS still we get a higher throughput, this I think has to do with better spatial locality due to compaction.

CMS通过同时执行标记解决了主要集合中的高暂停问题。有两个STW部分，初始标记（从根集中获取引用）和备注暂停（标记结束时的小STW暂停，以便在标记和应用程序同时工作时处理对象图中的更改）。对于几GB的堆大小和合理数量的应用程序线程，这两个暂停都在100 -200毫秒的范围内（记住更多活动线程更多根）

CMS solved the problem of high pauses in major collection by doing the Marking concurrently. There are 2 STW parts, Initial marking (getting the references from root set) and Remark Pause (a small STW pause at the end of marking to deal with changes in the object graph while marking and application was working concurrently). Both these pauses are in range of 100 -200 milliseconds for few GB of heap sizes and reasonable number of application threads(remember more active threads more roots)

G1GC计划在成为CMS的替代品并接受暂停目标。通过逐步压缩堆来处理碎片。虽然工作是增量的，但你可以获得更小的暂停，但这可能会以更频繁的暂停为代价

G1GC is planned to be a replacement of CMS and accept goals for pauses. takes care of fragmentation by incrementally compacting the heap.Though the work is incremental so you can get smaller pauses but that may come at the cost of more frequent pauses

没有应用程序运行时，上面可以压缩堆（CMS根本不压缩）。 AZUL GPGC垃圾收集甚至可以在不停止应用程序的情况下进行压缩，还可以处理参考更新。因此，如果您想深入了解GC如何工作，那么值得阅读GPGC的算法。 AZUL将其作为无停顿的收藏家推销。

None of the above can compact heap(CMS does not compact at all) while application is running. AZUL GPGC garbage collection can even compact without stopping the application and also handle reference update. So if you want to go deep into how GCs work it will be worth reading the algorithm for GPGC. AZUL markets it as a pause-less collector.

这篇关于Java垃圾收集总是必须“停止世界”吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！