Java 调整G1GC参数以进行积极的垃圾收集？

我的JVM基本上是一个spark执行器，它一个接一个地运行任务。任务内存不足，在其生命周期中需要大量内存

上面的JVM在G1GC上使用默认参数运行。正如您在下午4:25到4:32之间右侧的VisualVM报告中所看到的，峰值是由于执行者运行的每个任务造成的（基本上，每个峰值是由于执行者在前一个任务完成后拾取新任务造成的）。当我在4:35触发手动GC时，我看到堆使用率急剧下降。此外，正如您在JConsole报告的左侧所看到的，G1GC从未收集旧的gen空间（16:35之前旧的gen空间急剧减少是由于手动GC）。

---

由于我的应用程序是一个spark批处理作业应用程序，如果JVM花大量时间做GC，我就可以了。但是，我的内存有点不足。因此，我想知道如何调整我的JVM G1GC参数，以便有更频繁的GC（同时收集旧的gen空间），并且我可以用更少的堆空间（XMX）完成工作。

对于G1，将未使用的内存迅速返回到操作系统是OpenJDK 12的一项功能：

如果内存不足，可能需要控制RSS（从操作系统分配的总内存），而不仅仅是Java堆中使用的内存。在当前OpenJDK中使用G1时，（半）手动触发的完整GCs似乎是触发RSS减少的唯一方法。（如果您改变经常发生的全面地面军事系统的人体工程学，G1将表现不佳。）

如果您的OpenJDK构建包含，那么如果您需要节省内存，尤其是在进行一些调优时，例如使用

-XX:ShenandoahGCHeuristics=compact

，那么它可能是一个更好的选择

---

最终也应该支持返回内存，但是；尚未合并。

是否检查此项：

https://www.oracle.com/technetwork/articles/java/g1gc-1984535.html#Taming

我尝试更改-XX:InitiatingHeapOccupancyPercent。我试过用0，5，10。值越低，GC的使用频率越高，消耗的CPU越多，但行为不一致。过了一段时间，堆的使用率会急剧上升，如果我们将XMX值设置为比上图中的值小（6GB），它会抛出OOMthat

shenandoahelocationstrics

将毫不延迟地执行背对背的GC调用，至少还应该启用

shenandoahelocationthreshold

。