Java 使用并发标记扫描 GC 收集器？

using Concurrent Mark Sweep GC Collector?

提问by M Sach

This question is based on my understanding from section Java Garbage Collectors of linkLooks like jvm by default uses "Parallel GC" on windows 7 as i confirmed it -XX:+PrintCommandLineFlags -version. This article also says

这个问题是基于我对链接的Java 垃圾收集器部分的理解 看起来像 jvm 在 Windows 7 上默认使用“并行 GC”，因为我确认了 -XX:+PrintCommandLineFlags -version。这篇文章还说

The parallel garbage collector uses multiple threads to perform the young generation garbage collection. This collector should be used when a lot of work need to be done and long pauses are acceptable

并行垃圾收集器使用多个线程来执行年轻代垃圾收集。当需要完成大量工作并且可以接受长时间的停顿时，应使用此收集器

i am not sure which collector is used for tenured space collection by Parallel GC?

我不确定并行 GC 使用哪个收集器进行终身空间收集？

Also i could not think of applications where long pauses are acceptable(will cause less responsiveness). Anyone would like to less pauses for GC and make app as responsive as it can.

我也想不出可以接受长时间暂停的应用程序（会导致响应速度变慢）。任何人都希望减少 GC 的停顿并使应用程序尽可能地响应。

Then i read Concurrent Mark Sweep (CMS) Collectorwhich collects the tenured generation

然后我读了Concurrent Mark Sweep (CMS) Collector哪些收集了老一代

CMS says it require low pause times and can share resources with the garbage collection.

CMS 说it require low pause times and can share resources with the garbage collection。

My question is should not most of web applications use Concurrent Mark Sweep (CMS) Collector because of its responsiveness.?I am sure there must be some other factors also to make the decision but after going thru this link to me feels like i should change the default GC type to Concurrent Mark Sweep (CMS) Collector. Any thoughts/insights?

我的问题是，大多数 Web 应用程序不应该因为它的响应能力而使用并发标记扫描 (CMS) 收集器。我相信一定还有其他一些因素来做出决定，但是在通过这个链接给我之后，我觉得我应该将默认 GC 类型更改为并发标记扫描 (CMS) 收集器。任何想法/见解？

Further i think application can be best if we use CMS Collector and parallel collector together where CMS is used for old generation and parallel fpr younger generation

此外，我认为如果我们同时使用 CMS 收集器和并行收集器，其中 CMS 用于老年代和并行 fpr 年轻代，应用程序可能是最好的

采纳答案by awksp

i am not sure which collector is used for tenured space collection by Parallel GC?

我不确定并行 GC 使用哪个收集器进行终身空间收集？

Going off of thispage, if you use the parallel GC the parallel scavenge collector is used for the young generation and the parallel mark/sweep collector is used for the old generation (aka tenured generation). So I guess the answer is "The Parallel GC is used for tenured space collection by the Parallel GC". Bit of a circular statement, but I suppose it makes sense.

要去关闭这个页面，如果您使用并行GC使用并行清除收集器年轻一代和并行标记/清除收集用于老一代（又名年老代）。所以我猜答案是“并行 GC 用于并行 GC 的终身空间收集”。有点循环陈述，但我认为这是有道理的。

Also i could not think of applications where long pauses are acceptable(will cause less responsiveness). Anyone would like to less pauses for GC and make app as responsive as it can.

我也想不出可以接受长时间暂停的应用程序（会导致响应速度变慢）。任何人都希望减少 GC 的停顿并使应用程序尽可能地响应。

"Long pause" is relative, and whether they are acceptable depends on the type of application and its use. Applications which require quick user interaction, such as games, would probably require low pause times, while applications that are long-running, have little user interaction (overnight batch jobs, processing jobs which can run for several days, possibly servers which run for long periods of time, etc.), or don't require fastuser interaction (word processors? But who writes word processors in Java?) wouldn't have nearly as strict pause requirements, so pauses would be OK for those. In addition, pauses are not the onlyGC factor to consider, so even if pauses are OK there are other reasons that a GC with longer pauses would be chosen. I'll explain further down.

“长停顿”是相对的，是否可以接受取决于应用程序的类型及其用途。需要快速用户交互的应用程序（例如游戏）可能需要较短的暂停时间，而长时间运行的应用程序几乎没有用户交互（隔夜批处理作业、可以运行数天的处理作业、可能运行很长时间的服务器）时间段等），或者不需要快速的用户交互（文字处理器？但是谁用 Java 编写文字处理器？）几乎没有那么严格的暂停要求，所以暂停对那些人来说是可以的。此外，暂停不是唯一需要考虑的 GC 因素，因此即使暂停没问题，也有其他原因会选择暂停时间较长的 GC。我将进一步解释。

My question is should not most of web applications use Concurrent Mark Sweep (CMS) Collector because of its responsiveness.?

我的问题是，大多数 Web 应用程序不应该因为它的响应能力而使用并发标记扫描 (CMS) 收集器。

The CMS collector has drawbacks. In the article you mentioned, there's this line:

CMS 收集器有缺点。在你提到的文章中，有这样一行：

Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects.

通常并发低暂停收集器不会复制或压缩活动对象。垃圾收集是在不移动活动对象的情况下完成的。

So no heap compaction would lead to heap fragmentation, which could be detrimental to performance. Thispost states another drawback (I'm not sure exactly how reliable this post is, but it seems to be pretty decent at a first glance):

所以没有堆压缩会导致堆碎片，这可能对性能有害。这篇文章指出了另一个缺点（我不确定这篇文章到底有多可靠，但乍一看似乎还不错）：

A more important disadvantage of the CMS collector is related to the fact that it cannot be started when the Old generation heap is full. Once the Old generation is full, it is too late for the CMS and it must then fall back to the usual stop-the-world strategy (announced by a “concurrent mode failure” in the GC log).

...

The biggest disadvantage of the CMS, however, is related to the fact that it does not compact the Old generation heap. It therefore carries the risk of heap fragmentation and severe operations degradation over time.

...

It is obvious that with these settings the JVM worked well for almost 14 hours under loadtest conditions (in production and with lower load this treacherously benign period may last much longer). Then suddenly there were very long GC pauses which actually stopped the JVM for about half of the remaining time. There were not only attempts to clean up the mess in the Old generation which lasted more than 10 seconds but even New generation GC pauses were in the seconds range because the collector spent a lot of time searching for space in the Old generation when it tried to promote objects from new to Old generation.

CMS 收集器的一个更重要的缺点是当老年代堆满时它无法启动。一旦老年代满了，CMS 就太迟了，它必须回退到通常的 stop-the-world 策略（通过 GC 日志中的“并发模式失败”宣布）。

...

然而，CMS 的最大缺点与它不压缩老年代堆的事实有关。因此，随着时间的推移，它会带来堆碎片和严重操作降级的风险。

...

很明显，在这些设置下，JVM 在负载测试条件下可以正常运行近 14 小时（在生产和低负载情况下，这个危险的良性时期可能会持续更长时间）。然后突然有很长的 GC 暂停，实际上在剩余的一半时间内停止了 JVM。不仅尝试清理老年代的混乱，持续时间超过 10 秒，甚至新生代 GC 暂停也在秒范围内，因为收集器在尝试时花费了大量时间在老年代寻找空间将对象从新生代提升到老年代。

There is more detail in the blog post, which you should probably read as there's a lot covered outside the quote here as well as some fantastic demonstrations. But the point to take away is that the CMS collector is not a one-size-fit-all collector. It has its drawbacks as well, which might cause a programmer to pick a different collector instead. Using it as the default may be OK for short-running applications, but for long-running applications such behavior would be very bad...

博客文章中有更多详细信息，您可能应该阅读这些内容，因为这里的引用之外还有很多内容以及一些精彩的演示。但需要指出的是，CMS 收集器并不是一个通用的收集器。它也有它的缺点，这可能会导致程序员选择不同的收集器。对于短期运行的应用程序，将其用作默认值可能没问题，但对于长时间运行的应用程序，这种行为将非常糟糕......

Further i think application can be best if we use CMS Collector and parallel collector together where CMS is used for old generation and parallel fpr younger generation

此外，我认为如果我们同时使用 CMS 收集器和并行收集器，其中 CMS 用于老年代和并行 fpr 年轻代，应用程序可能是最好的

This is actually the default mode when you pass the -XX:+UseConcMarkSweepGCargument to your VM. But as stated above, you may want to really take some time to think about what collector you want to use. Picking a collector without considering your use case probably isn't a good idea. (Side note: I thoughtI saw some document from Oracle on how to decide what GC to use, but I can't find it any more...)

这实际上是您将-XX:+UseConcMarkSweepGC参数传递给 VM时的默认模式。但是如上所述，您可能真的需要花一些时间来考虑要使用什么收集器。不考虑您的用例而选择收集器可能不是一个好主意。（旁注：我以为我从 Oracle 那里看到了一些关于如何决定使用什么 GC 的文档，但我再也找不到了……）

In addition, you might want to consider the shiny new G1 collector, if you have Java 7u4 or later. It's supposed to be the replacement for the CMS collector.

此外，如果您有 Java 7u4 或更高版本，您可能需要考虑闪亮的新 G1 收集器。它应该是 CMS 收集器的替代品。

回答by dcernahoschi

i am not sure which collector is used for tenured space collection by Parallel GC?

我不确定并行 GC 使用哪个收集器进行终身空间收集？

If you don't specify the flag "-XX:+UseParallelOldGC" the jvm will choose the single threaded or the multithreaded collector based on the number of cores available on the machine, os, 32/64 bits, etc.

如果您不指定标志“-XX:+UseParallelOldGC”，jvm 将根据机器上可用的内核数、操作系统、32/64 位等选择单线程或多线程收集器。

My question is should not most of web applications use Concurrent Mark Sweep (CMS) Collector because of its responsiveness.?

我的问题是，大多数 Web 应用程序不应该因为它的响应能力而使用并发标记扫描 (CMS) 收集器。

The problem with the CMS collector is that it does no old generation memory compaction leading to performance degradation in memory allocation and eventually to a stop the world FULL GC as with the Parallel GC.

CMS 收集器的问题在于它没有进行老年代内存压缩，导致内存分配的性能下降，并最终像并行 GC 一样停止世界 FULL GC。

If your web app uses a small heap(4-5GB) that is not filling up to often (1-2 times a day) and pauses of 1s/(old gen. GB) are acceptable then the Parallel GC is a good choice.

如果您的 Web 应用程序使用的小堆 (4-5GB) 不会经常填满（每天 1-2 次）并且可以接受 1 秒/（旧版 GB）的暂停，那么并行 GC 是一个不错的选择。

If you have larger heaps, CMS is a better option as it does not induce long stop the world pauses when collecting the old generation. But you should anyway schedule a FULL memory gc let's say once a day on off peak hours in order to do memory compaction.

如果你有更大的堆，CMS 是一个更好的选择，因为它不会在收集老年代时引起世界暂停。但是无论如何你应该安排一个完整的内存gc，让我们说在非高峰时间每天一次，以便进行内存压缩。

Further i think application can be best if we use CMS Collector and parallel collector together where CMS is used for old generation and parallel fpr younger generation

此外，我认为如果我们同时使用 CMS 收集器和并行收集器，其中 CMS 用于老年代和并行 fpr 年轻代，应用程序可能是最好的

They can't be setup to be used together: the Parallel GC and CMS. But young generation collection is parallel and stop the world with both collectors.

它们不能设置为一起使用：Parallel GC 和 CMS。但年轻一代的收藏是平行的，并与两位收藏家一起停止世界。