问题标签 [g1gc]

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html似乎是 G1 垃圾收集器的官方文档。

提到了两个选项：

• -XX:+G1ParallelRSetUpdatingEnabled
• -XX:+G1ParallelRSetScanningEnabled

当配置 tomcat 以使用带有这些选项的 G1 时，catalina.log 出现

我的JVM是

和

为什么 -XX:+G1ParallelRSetScanningEnabled 不起作用的任何提示？

Java 7已经发布了一段时间，但我找不到任何关于垃圾收集器配置的好资源，特别是新的G1 收集器。

我的问题：

1. G1 是 Java 7 中的默认收集器吗？如果不是，我该如何激活 G1？
2. Java7中g1有哪些可选设置？
3. Java 7 中的cms或并行收集器等其他收集器是否有任何更改？
4. 我在哪里可以找到关于 Java 7 中垃圾收集的优秀文档？

我找不到与 G1 的运作方式有关的任何选项。以下两个命令不再适用于 java7。

我想知道 JDK 7 版本中“垃圾优先”（G1）收集器的官方状态是什么。我想使用 G1 作为 CMS 的低暂停 gc 替代品，但前提是我可以真正相信它的稳健性。

在 JDK 7 出来之前，G1 被宣传为闪亮的新 gc 将取代 CMS 收集器，甚至成为 JDK 7 中的默认 gc。但是，现在使用 Oracle JDK 7u1，G1 不是我拥有的任何机器上的默认 gc试过了。

尽管在 JDK 7 中-XX:+UnlockExperimentalVMOptions使用时不再需要指定-XX:+UseG1GC，但它是一项 JVM 功能，官方完全没有记录：

G1 上的 Java 7 (JDK 7) 垃圾收集和文档

我能找到的唯一一个提到 G1 的官方文档已经严重过时，并且是在 JDK 7 发布之前很久就写的：

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

例如，官方的“Java HotSpot VM Options”文档 ( http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html ) 记录了如何启用和调整其他收集器，但确实更别提G1的存在了。好像不存在一样！

这很令人困惑，我想知道 G1 的真实状态和未来是什么。真的稳定了吗？剩下的问题（如泄漏、虚假崩溃和缺少仪器支持）是否已解决？如果是这样，为什么甲骨文将 G1GC 视为无证（尴尬？）秘密？G1 可能是一个失败的项目，现在默默地停止了吗？还是我需要为文件和支持付费？还是只是测试版？有人可以告诉我这里发生了什么吗？

我目前遇到垃圾收集时间很长的问题。请参阅以下内容。我当前的设置是我正在使用 -Xms1g 和 -Xmx3g。我的应用程序使用的是 java 1.4.2。我没有设置任何垃圾收集标志。从外观上看，3gb 是不够的，我真的有很多对象要垃圾收集。

问题：

我应该改变我的垃圾收集算法吗？我应该用什么？是不是更好用-XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

还是我应该使用这种组合

占用内存的主要是报告数据，而不是缓存数据。另外，机器有 16gb 内存，我计划将堆增加到 8gb。

这两个选项之间有什么区别，因为我仍然很难理解。机器有多个处理器。我最多可以承受 5 秒的打击，但 30 到 70 秒真的很难。

谢谢您的帮助。

只是好奇。我听说新的 G1GC 解决了这个延迟问题。我不能/不想使用 RTSJ。

提前致谢

当使用 G1 收集器时，是否有人遇到过 JVM（热点）泄漏内存的问题？

我已将堆大小固定为 60GB（-ms 和 -ms 都设置为 60G），但 java 进程的大小（根据 ps 命令的 vsz 列）从 64GB 左右开始，但增加到 84GB 7小时内。

使用并行收集器，进程大小在 20 小时运行后保持稳定，大约为 65GB 左右。

有没有其他人对 G1 收集器有类似的问题？我正在运行一个非常简单的基准测试，并且我没有使用任何直接缓冲内存或其他堆外内存（我知道）。

Java版本为1.7.0，更新5

（我已经向 Oracle 提出了一个关于这个问题的错误，但我想我也会在这里检查一下，以防有人有解决方法）。

我已经在 J​​ava 上运行了计数器。它可以 24 小时工作，并且点击率大约每秒 100 次。白天 GC 处理时间从 20-60 毫秒缓慢上升到 10000-60000 毫秒，然后下降到 20-60 毫秒。这种模式不时重复。从 GC 日志中，我发现大部分时间 GC 都花在处理引用对象（Ref Proc）上。那么这么长的GC时间可能是什么原因呢？

GC 日志示例：

时间 - “Ref Proc”图表：

我在 java 源参数 PrintReferenceGC 中找到了。接下来显示 GC 日志

这是 JNI 弱引用的一些问题。

我注意到在我的应用程序中使用 G1 垃圾收集器偶尔会出现完整的 GC，并试图找出它们发生的原因。

从一个区域扫描开始到下一个区域的循环摘录如下。在 61807.406，记录了一个完整的 GC，然后是一个并发标记中止的条目。我想知道的是为什么 GC 觉得有必要进行一次完整的、停止世界的垃圾收集以及如何避免它。

请注意，这个问题之前似乎已经在 OpenJDK 邮件列表中提出过，但没有任何回复。

为简洁起见，我已经修剪了年轻 GC 的细节，但如果需要，我可以在某处发布完整的块。

这是使用 Java Hotspot 1.7.0_7 版本，具有以下有趣的设置：

我们目前已经安装并配置了 JDK1.7 以使用 G1GC。我想知道的是这个。

停止世界暂停只是Major GC的一个特点吗？还是 Minor GC 也有这个问题？