导致GC流失一致的技术
我正在寻找基准如何在与大量正在进行的垃圾收集竞争时执行的操作。 我之前已经对它在稳定的单线程运行中的行为进行了基准测试，现在我想在更加紧张的JVM中进行相同的测试; 本质上我想让背景线程以合理一致的速度创建和销毁对象。
我正在寻找有关如何实施稳定但GC密集型操作的建议。 它需要完成几个目标：
- 在GC中花费相当多的时间（比方说，20-50％）
- 随着时间的推移做大致一致的工作量，并为GC创建类似一致的工作量
- 避免泛滥堆并触发
Java heap space错误 - 避免GC过载并触发
GC overhead limit exceeded错误
我实现了自己的传递，可能导致稳定的垃圾收集量。 完整代码可在此处获取： https ： //bitbucket.org/snippets/dimo414/argzK
肉是这两种方法，它们在给定的实时时间内构建和释放大量对象（而不是线程时间或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> 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> 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()报告的线程分配的总字节数。 com.sun.management.ThreadMXBean.getThreadAllocatedBytes() 。
控件（0％流失）不应该基本上引入任何GC，我们可以看到它几乎不分配任何对象，并且花费近100％的时间在线程中。 从5％到95％的流失率我们看到相当一致的时间大约有三分之二的时间花在了线程上，大概是另外三分之一花在了GC上。 我会说，合理的百分比。 有趣的是，在流失百分比的极高端，我们看到花在线程上的时间更多，大概是因为GC正在清理这么多，它实际上能够更有效率。 看起来大约20％是每个周期都要搅拌的大量物体。
这绘制了线程如何在地图和列表的不同目标大小下运行，我们可以看到随着大小的增加，必须在GC中花费更多的时间，有趣的是我们实际上最终会分配更少的对象，因为更大的数据大小意味着它无法在同一时间内制作尽可能多的循环。 由于我们有兴趣优化JVM必须处理的GC流失量，我们希望它需要处理尽可能多的对象，并在工作线程中花费尽可能少的时间。 因此，大约4-500左右是一个很好的目标尺寸，因为它会产生大量的物体，并且在GC中花费了大量的时间。
所有这些测试都是使用标准的java设置完成的，因此使用堆可能会导致不同的行为 – 特别是，〜2000是我在堆填满之前可以设置的最大大小，我们可能会看到更好的结果如果我们增加堆的大小，则更大。