如何提高堆利用率以防止/延迟GC？

Question

我已经为 Java 应用程序分配了 8G 的初始堆大小，并且已经运行了大约 12 个小时，我有一个 cronjob 可以在 22 小时后终止 Java 进程。从连续的线程转储中查看堆信息：

Heap
 garbage-first heap   total 8388608K, used 526854K [0x00000003d5a00000, 0x00000003d5c08000, 0x00000007c0000000)
  region size 2048K, 259 young (530432K), 6 survivors (12288K)
 Metaspace       used 22982K, capacity 44820K, committed 44928K, reserved 1114112K
  class space    used 2666K, capacity 2862K, committed 2944K, reserved 1048576K

Heap
 garbage-first heap   total 8388608K, used 758278K [0x00000003d5a00000, 0x00000003d5c08000, 0x00000007c0000000)
  region size 2048K, 372 young (761856K), 6 survivors (12288K)
 Metaspace       used 22982K, capacity 44820K, committed 44928K, reserved 1114112K
  class space    used 2666K, capacity 2862K, committed 2944K, reserved 1048576K

堆似乎没有得到充分利用。分配了8G，但使用了大约只有0.7G左右。

但是，在查看 gc 日志时，我注意到有 3 个年轻的 gc。

OpenJDK 64-Bit Server VM (25.352-b08) for linux-amd64 JRE (1.8.0_352-b08), built on Oct 17 2022 20:39:31 by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-10)
Memory: 4k page, physical 65685332k(28882716k free), swap 4194300k(4194300k free)
CommandLine flags: -XX:+AggressiveOpts -XX:+AlwaysPreTouch -XX:-DisableExplicitGC -XX:G1HeapRegionSize=2097152 -XX:G1MaxNewSizePercent=60 -XX:G1NewSizePercent=20 -XX:InitialBootClassLoaderMetaspaceSize=33554432 -XX:InitialHeapSize=8589934592 -XX:MaxGCPauseMillis=50 -XX:MaxHeapSize=16815444992 -XX:MetaspaceSize=104857600 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UnlockExperimentalVMOptions -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
2023-03-28T10:27:28.325+0800: 2591.299: [GC pause (G1 Evacuation Pause) (young) 1638M->12571K(8192M), 0.0492549 secs]
2023-03-28T11:27:05.000+0800: 6167.975: [GC pause (G1 Evacuation Pause) (young) 1636M->9215K(8192M), 0.0406190 secs]
2023-03-28T13:38:51.005+0800: 14073.980: [GC pause (G1 Evacuation Pause) (young) 1636M->10758K(8192M), 0.0292244 secs]

鉴于未充分利用，我可以将年轻代大小

-XX:NewSize=size

增加到更高的值以防止/延迟 GC 暂停吗？或者我应该修改/减少老一代的大小 (

-XX:NewRatio

) 因为它似乎没有分配给老一代（尽管我觉得这很奇怪，因为我确实使用对象池来重用容器对象 -所以对象池及其元素应该是“旧的”？）。

我发现了这个question，它建议不要触及年轻一代的大小，让 G1GC 自己处理。所以我不太确定是否继续进行上述操作。