Java G1垃圾收集-重复完全GC-这是否表示堆碎片/垃圾压缩问题？

我正在使用Java7Update76和G1垃圾收集器

我们周期性地经历小时间间隔（每4到5秒）发生的完全gc，似乎内存正在被释放，但随后很快又发生了另一次完全gc，似乎再次释放了类似数量的内存

这是否表示存在堆碎片/垃圾压缩问题

Line 21068: 2015-05-27T04:58:38.527+0100: 2792829.022: [Full GC 3987M->236M(4096M), 0.6266670 secs]
Line 21084: 2015-05-27T04:58:46.744+0100: 2792837.238: [Full GC 3901M->237M(4096M), 0.6240680 secs]
Line 21101: 2015-05-27T04:58:51.303+0100: 2792841.797: [Full GC 3991M->238M(4096M), 0.6463980 secs]
Line 21118: 2015-05-27T04:58:55.561+0100: 2792846.055: [Full GC 3903M->238M(4096M), 0.6273730 secs]
Line 21130: 2015-05-27T04:58:59.747+0100: 2792850.241: [Full GC 3901M->238M(4096M), 0.6414350 secs]
Line 21146: 2015-05-27T04:59:04.128+0100: 2792854.623: [Full GC 3902M->237M(4096M), 0.6291800 secs]
Line 21158: 2015-05-27T04:59:08.363+0100: 2792858.857: [Full GC 3902M->239M(4096M), 0.6308080 secs]
Line 21169: 2015-05-27T04:59:12.536+0100: 2792863.031: [Full GC 3814M->240M(4096M), 0.6440340 secs]
Line 21185: 2015-05-27T04:59:18.000+0100: 2792868.495: [Full GC 3905M->239M(4096M), 0.6270340 secs]
Line 21197: 2015-05-27T04:59:22.217+0100: 2792872.711: [Full GC 3902M->239M(4096M), 0.6288050 secs]
Line 21208: 2015-05-27T04:59:26.389+0100: 2792876.883: [Full GC 3902M->239M(4096M), 0.6330140 secs]
Line 21224: 2015-05-27T04:59:30.610+0100: 2792881.104: [Full GC 3904M->239M(4096M), 0.6279680 secs]
Line 21236: 2015-05-27T04:59:34.758+0100: 2792885.253: [Full GC 3813M->239M(4096M), 0.6295690 secs]
Line 21247: 2015-05-27T04:59:38.928+0100: 2792889.422: [Full GC 3903M->239M(4096M), 0.6315110 secs]
Line 21258: 2015-05-27T04:59:43.260+0100: 2792893.754: [Full GC 3814M->240M(4096M), 0.6532740 secs]
Line 21274: 2015-05-27T04:59:49.461+0100: 2792899.955: [Full GC 3993M->239M(4096M), 0.6340010 secs]
Line 21286: 2015-05-27T04:59:53.765+0100: 2792904.260: [Full GC 3903M->240M(4096M), 0.6300460 secs]

---

在这种重复的完全gc重复行为发生之前，系统可以正常运行大约一个月…

这不太可能是G1特定的问题（尝试另一个收集器，同样的情况可能会发生）。你的应用程序中的用户流失率非常高。像yourkit这样的工具非常适合追踪主要犯罪者。

我用过，也用过。两者都很好。

---

我的几个朋友正在使用。我听到了很多关于它的好消息。请注意：-仅适用于战争

“3987M->236M（4096M）”，每隔4-8秒，堆实际上从240M达到3.9G。可能是某些流氓代码正在疯狂地泄漏吗？我的意思是，每一个完整的GC循环占用大约2.3G的内存。难道应用程序不能真正创建这么多对象吗？一些请求，一些方法调用在一个巨大的数据集上循环？是的，我们最初认为这是与代码相关的（仍然可能），但它运行了一个月，然后就不稳定了！您是否在服务器运行不稳定时从服务器获取线程转储和对象直方图转储？他们将提供线索，说明谁应对对象搅动负责，而无需在调试器中复制。您好，我们正在调查并在场外复制此问题-我们计划这样做是的。感谢没有任何迹象表明您尝试了其他JVM标志（如-XX:+useConMarkSweepGC等）。如果您的工作集只有240M，并且在4s中分配4Gb，那么您就有1Gb/s的垃圾创建吞吐量。对于服务器应用程序，您可能需要面向吞吐量的集合；对于需要面向延迟的收集的客户端。在任何情况下，您可能会发现代码的一小部分正在创建所有这些垃圾。我将从查看内存锯齿形状开始—无论是线性还是二次爬升。您可以并排绘制f（x）、f（x）/x、f（x）/（x*x）、f（x）/（ln（x）*x）以获得一些细节。排除的第一个可疑点几乎总是循环中的字符串追加，或者是其他具有二次垃圾创建的不可变集合复制模式。下一步是避免在主热循环中进行分配。垃圾创建速率决定必须触发收集的频率。