在将一些应用程序从CMS迁移到G1时，我发现其中一个应用程序的启动时间延长了4倍。由于GC循环导致的应用程序停止时间不是原因。比较应用程序行为后，我发现这个应用程序在启动后携带着2.5亿个活动对象（在12G堆中）。进一步调查显示，该应用程序在前500万个分配期间速度正常，但随着活动对象池越来越大，性能逐渐下降。
进一步实验表明，一旦达到一定数量的活动对象阈值，使用G1时分配新对象的速度确实会变慢。我发现，将活动对象数量翻倍似乎需要花费2.5倍的时间进行分配。对于其他GC引擎，这个因素只有2。这确实可以解释减速。
然而，有两个问题让我怀疑这个结论：
1. 大约500万个活动实例的阈值似乎与整个堆有关。对于G1，我本来希望任何这样的退化阈值都与一个区域有关，而不是与整个堆有关。 2. 我在网上寻找了解释（或至少说明）此行为的文档，但没有找到。我甚至没有找到“拥有超过xxx个活动对象是不好的”这样的建议。
因此：如果有人能告诉我我的观察结果是正确的，并可能指向一些说明文件或关于此领域的推荐，那将是很棒的。或者，另外一个人告诉我我做错了什么。:)
以下是一个简短的测试用例（多次运行，取平均值，减去显示的垃圾收集时间）：
进一步实验表明，一旦达到一定数量的活动对象阈值，使用G1时分配新对象的速度确实会变慢。我发现，将活动对象数量翻倍似乎需要花费2.5倍的时间进行分配。对于其他GC引擎，这个因素只有2。这确实可以解释减速。
然而，有两个问题让我怀疑这个结论：
1. 大约500万个活动实例的阈值似乎与整个堆有关。对于G1，我本来希望任何这样的退化阈值都与一个区域有关，而不是与整个堆有关。 2. 我在网上寻找了解释（或至少说明）此行为的文档，但没有找到。我甚至没有找到“拥有超过xxx个活动对象是不好的”这样的建议。
因此：如果有人能告诉我我的观察结果是正确的，并可能指向一些说明文件或关于此领域的推荐，那将是很棒的。或者，另外一个人告诉我我做错了什么。:)
以下是一个简短的测试用例（多次运行，取平均值，减去显示的垃圾收集时间）：
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();
}
}
PrintGCDetails）并且提到您正在使用的Java版本将会很有帮助。 - the8472