我正在测试zgc 11中包含的新java垃圾收集器，因为它保证了极低的延迟。我们的应用程序是一种实时服务，它每秒创建和销毁许多对象，并使用akka在多线程环境中进行操作。
通过传递选项zgc并启用-XX:+UnlockExperimentalVMOptions -XX:+UseZGC日志来启用gc时，我们可以在日志中看到许多类似于以下内容的消息:
[2020-05-20T18:05:36.563+0000][63.851s][info ][gc] Allocation Stall (Main-akka.remote.default-remote-dispatcher-6) 11332.231ms
[2020-05-20T18:05:36.563+0000][63.851s][info ][gc] Allocation Stall (Main-akka.remote.default-remote-dispatcher-26) 9898.046ms
[2020-05-20T18:05:36.563+0000][63.851s][info ][gc] Allocation Stall (Main-io-blocking-dispatcher-52) 12133.240ms
[2020-05-20T18:05:36.563+0000][63.851s][info ][gc] Allocation Stall (Main-akka.actor.default-dispatcher-54) 9002.299ms
[2020-05-20T18:05:36.563+0000][63.850s][info ][gc] Allocation Stall (Main-io-blocking-dispatcher-50) 12134.218ms
[2020-05-20T18:05:36.563+0000][63.850s][info ][gc] Allocation Stall (Main-akka.actor.default-dispatcher-46) 12132.540ms
[2020-05-20T18:05:36.563+0000][63.851s][info ][gc] Allocation Stall (Main-akka.actor.default-dispatcher-56) 8072.664ms
几秒钟后，JVM退出，没有给出任何原因。我们正在运行
openjdk-java-11。关于如何做这项工作的任何建议？
最佳答案
分配停顿意味着某事正在请求堆，但没有堆可用，因此请求线程正在阻塞。确保您有足够的gc线程设置。 JDK可能无法检测核心计数，这是gc线程的默认值派生自其中的内核，特别是在使用Docker的情况下。参见https://wiki.openjdk.java.net/display/zgc/Main#Main-SettingConcurrentGCThreads
如果在这些期间您的CPU使用率很低，则这尤其可能是问题。
通常，启用hugepages可以帮助提高ZGC的性能。 https://wiki.openjdk.java.net/display/zgc/Main#Main-EnablingLargePagesOnLinux
另外，您可能只需要更多堆。
编辑以添加:也许还值得确保您使用的是最新的jdk和操作系统补丁程序。