我如何解释 jstat 输出中的这些 narrow 尖峰？

【问题标题】：how do I explain these *narrow* spikes in jstat output?我如何解释 jstat 输出中的这些 *narrow* 尖峰？
【发布时间】：2009-06-19 20:58:38
【问题描述】：

当尝试使用 jstat 监控 JVM 的性能时，我看到以下几行 -

  Timestamp      PC       PU        OC          **OU**       YGC    FGC    FGCT     GCT
      ...
      283.7 132608.0 132304.8   1572864.0    **398734.1**     20     0    0.000    3.061
      284.0 132608.0 132312.8   1572864.0   **1547795.2**     21     0    0.000    3.061
      284.2 132608.0 132313.7   1572864.0    **417220.7**     21     0    0.000    3.418
      ...

相关 JVM 运行 2.5GB 的 Eden 和 4GB 的 Max。堆(-Xmn2560m -Xms4096m -Xmx4096m)

我不明白这些老一代的使用高峰是如何发生的？

【问题讨论】：

你能在这里添加你的 GC 标志吗？如果您正在使用例如那些不会显示为完整 GC 的 CMS，只会在失败时出现 - stop-the-world GC。

标签： java jvm

【解决方案1】：

完全是猜测，但看起来它发生在年轻一代进行 GC 时可能会将新对象踢入老一代。这可能会在老年代造成更严重的压缩过程。

我猜它会复制所有新的东西（使老一代更大），然后将其压缩回来......再次完全猜测。

由于您要从年轻一代移出一堆东西，因此即使没有完整的 GC，也可能需要时间（和空间）来移动一些东西。

【讨论】：

在一定程度上同意你的看法！我很难相信的部分是当你说“......我猜它会复制所有新东西（使老一代更大），然后将它压缩回去......” - 这不是旧的吗.将军收藏？如果是这样，为什么 FGC 计数不增加？
是的，你是对的。不过，看看你是否每次获得 YGC 时都会出现峰值，这仍然是一个有趣的数据点