【问题标题】:How to achieve deterministic GC pause in Java 7+?如何在 Java 7+ 中实现确定性 GC 暂停?
【发布时间】:2018-06-24 19:00:23
【问题描述】:

由于Jrockit 不再可用,因此有什么方法可以实现确定性(不超过 x 毫秒)GC 暂停?我正在尝试在 java_8_65 中使用 G1 GC,但它是不确定的,很多时候我看到年轻的 gc 暂停大于-XX:MaxGCPauseMillis,这是预期的,但不符合我的要求。

【问题讨论】:

    标签: java garbage-collection


    【解决方案1】:

    简单的答案是否定的。 Hotspot 和其他 JVM(比如我为之工作的Zing from Azul)使用的所有 GC 本质上都是不确定的。在大多数情况下,您当然可以调整 GC 以实现您的延迟目标,并且使用 Zing 会为您提供更可靠的结果,因为它真正与应用程序线程同时执行压缩收集(因此,没有停止 -世界暂停)。

    问题是,如果您的应用程序突然达到一个点,它开始以高得多的速率分配对象或生成垃圾的速度比您调整的快得多,您将开始看到超出目标的暂停。这就是 GC 的工作方式。

    获得像您正在寻找的真正确定性行为的唯一方法是使用real-time JVM(查找RTSJ spec),这也需要一个实时操作系统。这样做的缺点通常是您的吞吐量会受到影响。

    【讨论】:

    • 问题提到了 jrockit,因此似乎暗示不需要 RTSJ 级别的确定性,就像它管理的 GC 一样好。
    【解决方案2】:

    你的选择是

    • 进行一些调整,直到 G1 按预期执行
    • 切换到您正在使用的 JVM 中可用的另一个收集器,例如内容管理系统
    • 切换到不同的 JVM,为收集器提供更强的保证
    • 优化您的应用程序以降低 GC 压力或最坏情况下的行为
    • 为问题添加更多硬件(更多或更快的 CPU 内核、更多 RAM)

    【讨论】:

    • 目前正在进行 G1 gc 调整(虽然很难 :))...不想迁移到 CMS,因为它会根据 openjdk.java.net/jeps/291 被贬低
    【解决方案3】:

    另一个选项可能是OpenJ9 Metronome GC。 据我所知,它是为实时应用程序设计的确定性、短暂停顿。根据文档,默认值为 10 毫秒暂停。但是,它当然需要更多的 CPU 并且更多地为小堆设计。

    我没用过,所以不能分享经验。

    【讨论】:

      【解决方案4】:

      Java 11 的发布包含一个全新的垃圾收集器 ZGC,它承诺非常短的暂停时间。

      该项目的目标是创建一个可扩展的低延迟垃圾收集器,能够处理大小从几 GB 到数 TB 不等的堆,GC 暂停时间不超过 10 毫秒。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-01-08
        相关资源
        最近更新 更多