java - 垃圾收集器问题

<分区>

我在一本书(“Java 性能:权威指南”，作者 Scott Oaks)中读到，无论使用哪种 GC 算法，年轻代收集器始终是停止世界和单线程的。如果那是真的，为什么与老一代收集相比，年轻一代收集的时间总是可以忽略不计？是因为 young gen 空间比 oldgen 小吗？ (如果是，GC 花费的时间与堆的数量有何关系 - 指数？)
如果初始堆大小 (-Xms) 的值较小且上限 (-Xmx) 较大，达到初始限制时会发生什么情况？ JVM 会执行完整的 GC 还是会增加堆大小直到达到 -Xmx 限制？

最佳答案

I read in a book that the young gen collector is always stop-the-world, no matter which GC algorithm is being used.

或多或少，是的。但除了 SerialGC 之外，它们是多线程的，因此在这个问题上投入更多的核心可以让年轻的收集更快地获得相同数量的内存。

If that is true, why is that young gen collection always takes negligible amount of time compared to old gen collection ?

它并不总是可以忽略不计，影响新生代大小的因素有很多

Is it because young gen space is small compared to oldgen ?

在某种程度上是的，但不仅仅是大小， Activity 对象的比例也很重要。如果对象死得很快，就不需要访问/复制它们。

If yes, how is the time taken for GC related to the amount of heap - exponential ?

这取决于。如果我们谈论暂停时间，那就相当复杂了。如果我们谈论的是完整 GC 消耗的 CPU 周期(包括并发)，它与 Activity 对象的数量大致呈线性关系。如果我们谈论的是整个 CPU 周期(而不是每个 GC)，它又会变得更加复杂。

但无论哪种方式，它都不是指数级的。花在垃圾收集上的 CPU 周期数通常应该是花在应用程序代码上的 CPU 周期的一小部分。但是如上所述，CPU 周期!= 暂停时间。

When you have a small value for initial heap size ( -Xms ) and a larger upper limit ( -Xmx ), what happens when the initial limit is reached ? Will teh JVM do a full GC or will it grow the heap size till it hits the -Xmx limit ?

取决于所选的 GC 和各种其他设置。我建议您简单地观察 GC 的运行情况 GCViewer

进一步阅读: