java - 为什么 G1 提供更好的暂停时间但吞吐量较低?

标签 java garbage-collection g1gc

为什么 G1 的暂停时间较短,但吞吐量较低(较低的吞吐量意味着 GC 将运行更多的总时间(以秒为单位))

根据我的理解,内存被分为更小的部分,现在 full 必须在比完整堆更小的部分上运行。事实上,我们可以说现在没有完整的 GC,因为它没有在完整堆上运行,而是有多个后台线程同时运行,并首先清除那些包含最大数量死对象的内存块。因此暂停时间很短。

吞吐量较低,因为较大的内存被划分为较小的 block ,因此多个 GC 线程必须在较小的 block 而不是单个 block 上运行。所以大部分时间都会很忙

正确吗?

另外,为什么 G1 更适合大于 4GB 的堆?我相信它应该更适合所有堆大小,因为它会分成更小的阻塞器,并且暂停时间会很慢。那么为什么大于 4 GB 的堆建议使用 G1 呢?

最佳答案

G1 同时标记 Activity 对象,但停止世界清理死对象。因此,暂停时间比 stop-the-world GC(例如 Parallel Scavenge)短,但执行 GC 的时间更长,因为用于并发标记 Activity 对象的资源较少,并且需要额外的时间来重新标记 Activity 对象(在并发标记阶段更改的对象)。

关于java - 为什么 G1 提供更好的暂停时间但吞吐量较低?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39687702/

相关文章:

java - 将 java.home 从 JVM 中取出,无需编写 Java 代码来打印它

java - JDK 8 在 KeyStore.load 中使用 SHA 哈希算法安全吗?

python - 扭曲的Python垃圾收集

java - 创建子类的两种方法实际上是相同的?

java - 在比较 Java 中的两个原语和两个对象时,== 实际上是相同还是不同?

java - G1GC 日志中的时间

java - G1 GC 中的内存分配

java - 为什么 Java CMS 垃圾收集器不允许使用的堆大小增长到可用堆大小?

javascript - 用chrome调试node js垃圾收集/内存问题

javascript - 我的 PyV8 上下文泄漏内存