当我们的某些应用程序从CMS转移到G1时,我注意到其中一个应用程序的启动时间延长了4倍。由于GC循环导致的应用程序停止时间不是原因。在比较应用程序行为时,我发现这个在启动后(在一堆12G中)携带了高达2.5亿个活动对象。进一步调查显示,在前500万次分配期间,应用程序的速度正常,但随着活动对象池的增大,性能会越来越差。
进一步的实验表明,一旦达到一定的活动物体阈值,使用G1时新物体的分配确实会减慢。我发现活动对象数量增加一倍似乎在分配所需的时间上增加了大约2.5倍。对于其他GC引擎,因子只有2.这确实可以解释减速。
有两个问题让我怀疑这个结论:
所以:如果有人能够告诉我我的观察结果是正确的,并且可能会向我指出一些解释性文件,或者某些有关该领域的建议,那将会很棒。或者,有人告诉我我做错了什么。 :)
这是一个简短的测试用例(多次运行,取平均值,扣除显示的垃圾收集时间):
import java.util.HashMap;
/**
* Allocator demonstrates the dependency between number of live objects
* and allocation speed, using various GC algorithms.
* Call it using, e.g.:
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime -XX:+UseG1GC
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime
* Deduct stopped times from execution time.
*/
public class Allocator {
public static void main(String[] args) {
timer(2000000, true);
for (int i = 1000000; i <= 32000000; i*=2) {
timer(i, false);
}
for (int i = 32000000; i >= 1000000; i/=2) {
timer(i, false);
}
}
private static void timer(int num, boolean warmup) {
long before = System.currentTimeMillis();
Allocator a = new Allocator();
int size = a.allocate(num);
long after = System.currentTimeMillis();
if (!warmup) {
System.out.println("Time needed for " + num + " allocations: "
+ (after - before) + " millis. Map size = " + size);
}
}
private int allocate(int numElements) {
HashMap<Integer, String> map = new HashMap<>(2*numElements);
for (int i = 0; i < numElements; i++) {
map.put(i, Integer.toString(i));
}
return map.size();
}
}
答案 0 :(得分:1)
如上述评论所述:
你的测试用例会预先分配非常大的参考数组,这些数组是长寿命的,并且基本上占据了它们自己的区域(它们可能最终位于旧的或巨大的区域),然后用数百万个附加对象填充它们很可能生活在不同的地区。
这创建了许多跨区域引用,G1可以适度处理,但不是每个区域数百万。
通过G1的启发式方法,高度互联的区域也被认为是昂贵的,因此即使它们完全由垃圾组成也不太可能被收集。
将对象分配在一起以减少跨区域引用。
没有明确地延长它们的生命周期(例如将它们放入某种缓存中)也允许它们在年轻一代GC中死亡,这比旧区域更容易收集,旧区域本质上累积了从不同区域引用的对象。
所以你所有的测试用例都对G1的基于区域的性质持怀疑态度。