堆内存动态周转率是量化对象从分配到回收平均存活时间的经验指标，单位为秒；jstat -gc 仅提供瞬时快照与累计值，时间尺度不匹配且缺分配/回收量明细，故无法直接计算。
什么是堆内存动态周转率，为什么不能直接用 jstat -gc 算出来
堆内存动态周转率（Dynamic Heap Turnover Rate）不是 JVM 官方指标，而是运维和调优中用于量化「对象从分配到被回收的平均存活时间」的经验性指标，单位通常是秒。它反映的是堆内对象“流动速度”——值越小，说明对象死得快、GC 勤；越大，说明对象长期驻留，可能有缓存滥用或内存泄漏苗头。
注意：jstat -gc 只给总量（如 YGC 次数、YGCT 总耗时、EU 当前 Eden 使用量），但没提供「每次 GC 回收了多少新对象」或「Eden 区平均每秒分配多少」。直接拿 EU / YGCT 或类似比值是错的——因为 EU 是瞬时快照，YGCT 是累计值，二者时间尺度不匹配。
jstat -gc 必须配合采样频率才能提取有效吞吐数据
要算周转率，核心是拿到「单位时间内 Eden 区的平均分配速率」和「单位时间内 Young GC 实际回收的对象量」。这要求 jstat 以固定间隔持续输出，而非单次快照。
- 用
jstat -gc -t 1000 12345：每秒输出一行带时间戳的 GC 统计，持续到手动中断 - 关键列必须捕获：
EC（Eden 容量）、EU（Eden 已用）、YGC（Young GC 次数）、YGCT（Young GC 总耗时） - 不能用
-h跳过表头——后续计算依赖列顺序；也不建议加-J-Xmx2g这类 JVM 参数，jstat本身不接受运行时堆配置 - 输出示例（截取两行）：
S0C S1C EC EU OC OU YGC YGCT 40960 36864 253952 253952 109056 78921 123 2.145 40960 36864 253952 120456 109056 78921 124 2.158
注意EU从 253952 → 120456，说明第 124 次 GC 清空了约 133MB，这就是一次回收量
用 jstack 辅助排除「假周转」：线程阻塞导致分配停滞
如果 jstat 显示 YGC 频次极低、EU 长期高位不升，但应用逻辑本该高频创建对象，那周转率计算就失效——问题不在 GC，而在分配被卡住。这时 jstack 是唯一能定位的工具。
- 执行
jstack -l 12345 | grep -A 10 "BLOCKED\|WAITING"，重点看是否有大量线程卡在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await或Object.wait - 若发现线程在
new byte[1024*1024]前阻塞（比如等 DB 连接池归还），说明对象分配被上游限流，此时EU上升缓慢 ≠ 对象存活久，而是根本没机会分配 - 不要只看
jstack输出里的RUNNABLE线程——它们可能正忙于序列化、JSON 解析等 CPU 密集型操作，同样会抑制分配速率
最终计算公式与一个可落地的 shell 小脚本
真正可用的周转率 = （两次采样间 Eden 净分配量） / （两次采样间 Young GC 实际回收量） × 平均 GC 间隔。其中「净分配量」= 后次 EU − 前次 EU + 本次 GC 回收量（即 EC − EU 后的差值）。
以下脚本自动抓取 5 秒内 5 组数据，跳过首行表头，用 awk 计算近似周转率（单位：秒）：
jstat -gc -t 1000 12345 5 2>/dev/null | \
awk 'NR>1 {if(NR==2) {eu1=$5; ygc1=$13; ec=$3} else if(NR==6) {eu2=$5; ygc2=$13; print int((eu2-eu1+ec-eu2)/(ygc2-ycg1+1)*1000) "ms"}}'
注意这个结果只是 Eden 层级的粗略周转，不代表整个堆——老年代对象不参与此计算；如果 FGC 频繁，说明部分对象已晋升，此时需结合 jstat -gccapacity 看老年代扩容节奏，否则单看 Eden 周转会严重失真。
