应通过相邻两次 jstat -gc 输出中 ygc 和 fgc 的差值判断发生频率，而非单看累计值；ygc 每秒增10+次或 fgc 任意增长均需立即排查。
怎么看 Young GC 和 Full GC 的发生频率
直接看 YGC 和 FGC 两列的数值变化——它们是累计计数器，不是瞬时值。频率高低得靠「相邻两次输出的差值」来判断，而不是单看某一行数字。
例如执行 jstat -gc 12345 1000（每秒刷新），连续几行输出中：
-
YGC从 120 → 125 → 130，说明过去两秒各发生了 5 次 Young GC -
FGC从 3 → 3 → 4，说明在第二个 1 秒周期内触发了 1 次 Full GC
注意：如果 YGC 每秒涨 10+ 次，大概率是 Eden 区太小或对象创建过快；FGC 出现任何增长都要立刻查原因，不能等它变多。
为什么 -gcutil 比 -gc 更适合快速判断频率
-gcutil 输出的是百分比（如 E 表示 Eden 使用率），配合 YGC 列，能一眼看出「是不是刚 GC 完又快满了」——这才是高频回收的真实信号。
常见误判点：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 只盯着
YGC数字本身，忽略时间间隔，把 10 分钟涨 50 次当成“高频” - 用
-gc看EU（Eden 使用量 KB）时，因堆大小不同，数值难横向比较；而-gcutil的E列统一为 0–100%，更直观 -
-gcutil默认不显示YGCT/FGCT，如需耗时分析，得切回-gc或加-gccause
怎么识别“伪高频”和真实风险点
某些场景下 YGC 看似频繁，但实际无害；另一些则隐藏严重问题。关键看三组关联指标：
- 高频 +
E常在 95% 以上 → Eden 太小，调大-Xmn或调整比例 - 高频 +
O（老年代使用率）持续 >75% → 对象晋升过快，检查是否有大数组、缓存未清理、survivor 区过小导致提前晋升 -
FGC增长 +OU不降反升 → 元空间泄漏或老年代内存泄漏，要结合jstat -class看loaded是否持续上涨
特别注意：FGC 即使只增加 1 次，只要 FGCT 超过 1 秒，就已影响请求延迟，别等它“频繁”才处理。
生产环境采样频率怎么设才不丢数据也不拖慢 JVM
jstat 自身开销极低，但采样太密（如 100ms）会导致终端刷屏、日志膨胀，反而掩盖趋势；太疏（如 10s）可能漏掉短时毛刺。
推荐组合：
- 日常巡检：
jstat -gcutil 12345 2000（2 秒一刷），人眼可读，也方便重定向进日志做简单聚合 - 问题定位中：
jstat -gc -gccause 12345 500（500ms 一刷），重点看LGCC（Last GC Cause）列，比如Metadata GC Threshold直接指向元空间不足 - 避免踩坑：
jstat进程自身不要长期挂后台跑，尤其别用&放到后台后忘记 kill；它不自动退出，PID 占着资源还可能被误杀
真正容易被忽略的是：jstat 读取的是 JVM 内部 perfdata 文件，若目标 JVM 启用了 -XX:+PerfDisableSharedMem，jstat 就会报错「Could not attach to process」——这个开关在某些安全加固镜像里默认开启，得先确认。
