垃圾收集器疯了答案

【问题标题】：Garbage collector going crazy垃圾收集器疯了
【发布时间】：2013-12-03 05:04:11
【问题描述】：

我刚刚注意到，由于一个动作（我试图找出）虚拟机卡住了几次（看起来像垃圾收集器停止了世界）。通常小型 GC 需要 0.05 秒，突然发生了一些事情，我可以在日志中看到每个小型 GC 甚至增加到 15 秒。虚拟机在大约 10 分钟内不稳定。

有什么方法可以在源代码中找出原因（除了询问用户当时他们在做什么）？

虚拟机在专用机器（Linux 操作系统）中运行，我只能远程访问它。进程使用的总内存为 6 gb（稳定时），因此创建内存快照需要大量时间

【问题讨论】：

如果你还没有看到这个，你可能对这个线程感兴趣。它给出了一个调试VM的例子：stackoverflow.com/a/1849365/751245
您是否尝试过将 Concurrent Mark-Sweep GC 与并行新一代并行使用？
我正在使用这样的参数：-Xmx16G -XX:PermSize=2G -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -verbose:gc -XX:+ PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log

【解决方案1】：

在这种情况下，15 秒听起来有些过分。您应该检查一下，以免您只是交换（尤其是在 GC 本身期间），这可以解释缓慢的 GC 时间。

让vmstat 5 或类似的运行，并检查si 和so 字段。如果它们不为零，则表示您正在交换。

【讨论】：

【解决方案2】：

尝试在 YoungGen 峰值之前和之后收集 线程转储。此外，您可以尝试同时收集类直方图。如果是 FullGC 处于峰值状态，您可以使用 VM 标志来收集每个 FullGC 之前/之后的类直方图。

jstat 将让您更深入地了解堆区域的占用情况（与 GC 日志相比），请尝试收集它。

也可以附加 profiler，使用 采样模式 - 例如Mission Control 的开销很低，应该可以让您深入了解在 GC 峰值期间 VM 中发生的情况。

收集iostat、netstat、vmstat等将帮助您排除来自VM外部的任何干扰。

【讨论】：