java - 引起一致的 GC Churn 的技术

Question

我希望在应对大量正在进行的垃圾收集的同时，对某些东西的性能进行基准测试。我之前已经对它在稳定的单线程运行中的行为进行了基准测试，现在我想在压力更大的 JVM 中进行相同的测试；本质上，我想让后台线程以合理一致的速度创建和销毁对象。

我正在寻找有关如何实现稳定但 GC 密集型操作的建议。它需要完成几个目标:

• 在 GC 上花费相当多的时间(比如 20-50%)
• 随着时间的推移做大致一致的工作量，并为 GC 创建类似一致的工作量
• 避免溢出堆并触发 Java 堆空间 错误
• 避免 GC 过载并触发 GC overhead limit exceeded错误

Answer 1

我在可能导致垃圾收集量稳定的地方实现了自己的通行证。完整代码可在此处获得:https://gist.github.com/dimo414/5243162

主要是这两种方法，它们在给定的实时时间段(与线程时间或 CPU 时间相对)构造和释放大量对象:

/**
 * Loops over a map of lists, adding and removing elements rapidly
 * in order to cause GC, for runFor seconds, or until the thread is
 * terminated.
 */
@Override
public void run() {
    HashMap<String,ArrayList<String>> map = new HashMap<>();

    long stop = System.currentTimeMillis() + 1000l * runFor;
    while(runFor == 0 || System.currentTimeMillis() < stop) {
        churn(map);
    }
}

/**
 * Three steps to churn the garbage collector:
 *   1. Remove churn% of keys from the map
 *   2. Remove churn% of strings from the lists in the map
 *      Fill lists back up to size
 *   3. Fill map back up to size
 * @param map
 */
protected void churn(Map<String,ArrayList<String>> map) {
    removeKeys(map);
    churnValues(map);
    addKeys(map);
}

该类实现了 Runnable，因此您可以在其自己的后台线程中启动它(或同时启动多个)。只要您指定它就会运行，或者如果您愿意，您可以将它作为守护线程启动(因此它不会阻止 JVM 终止)并指定它以 0 秒永远运行作为构造函数参数。

---

我对此类进行了一些基准测试，发现它花费了将近三分之一的时间用于阻塞(大概是在 GC 上)，并确定了 15-25% 的流失率和约 500 的大小的近似最佳值。每次运行完成 60 秒，下图绘制了线程时间(由 java.lang.managment.ThreadMXBean.getThreadCpuTime() 报告)和线程分配的总字节数，如下所示由 com.sun.management.ThreadMXBean.getThreadAllocatedBytes() 报告。

控制(0% 流失)本质上不应该引入任何 GC，我们可以看到它几乎不分配任何对象并且将近 100% 的时间花在线程上。从 5% 到 95% 的流失率，我们相当一致地看到大约三分之二的时间花在线程上，大概另外三分之一花在 GC 上。一个合理的百分比，我会说。有趣的是，在流失百分比的非常高的一端，我们看到更多的时间花费在线程上，大概是因为 GC 正在清理这么多，它实际上能够更有效率。似乎每个周期要搅动的对象数量大约为 20%。

这描绘了线程如何在 map 和列表的不同目标大小下运行，我们可以看到随着大小的增加，必须在 GC 上花费更多的时间，有趣的是，我们实际上最终分配了更少的对象，因为更大的数据大小意味着它无法在同一时间段内进行尽可能多的循环。由于我们对优化 JVM 必须处理的 GC 搅动量感兴趣，因此我们希望它需要处理尽可能多的对象，并在工作线程中花费尽可能少的时间。似乎 4-500 左右是一个很好的目标大小，因此，因为它会生成大量对象并在 GC 中花费大量时间。

所有这些测试都是使用标准 java 设置完成的，因此使用堆可能会导致不同的行为 - 特别是，~2000 是我在堆填满之前可以设置的最大大小，它是如果我们增加堆的大小，我们可能会在更大的大小上看到更好的结果。