jstat中新生代使用率=EU/EC×100%，老年代使用率=OU/OC×100%；G1下OC代表老年代总容量、OU为已用空间，需用-jgcold分离查看；单位为KB，容器环境须启用-XX:+UseContainerSupport。
怎么看 jstat 输出里新生代和老年代的使用率
jstat 默认输出不直接标“新生代”“老年代”，它用 S0C/S1C/EC/OC/MC 这类缩写，得先对上号。G1 垃圾回收器下更麻烦，EU（Eden 使用）、SU（Survivor 使用）、MU（Metaspace 使用）才是关键指标，而 OC 在 G1 下其实代表老年代（Old Region）总容量，但实际已不常用——G1 用的是堆内动态分区，OU 才是老年代已用空间。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先用
jstat -options确认 JVM 版本支持哪些输出模式；JDK 8 常用-gc，JDK 11+ 推荐-gc -gcnew -gcold拆开看 - 关注列名含义：例如
jstat -gc <pid> 1s</pid>输出中，EC是 Eden 容量、EU是 Eden 已用，所以 Eden 使用率 =EU/EC*100%；同理OC/OU对应老年代容量与已用 - 注意单位是 KB，不是 MB，心算时别漏掉除以 1024
- 如果看到
OC = 0，大概率是用了 G1 或 ZGC，此时得切到-gcnew和-gcold分开查，否则老年代数据会“消失”
回收次数和耗时怎么看，哪几列真正反映 GC 压力
YGC 和 FGC 是最常被误读的两列：YGC 是 Young GC 次数，但不等于“新生代回收次数”——它只统计了触发了 Minor GC 的次数，而 G1/ZGC 下部分 Young GC 可能被合并或跳过，YGC 数值会偏低；FGC 在 G1 下几乎恒为 0，因为 G1 不做 Full GC（除非退化），此时要看 OGCMN/OGCMX/OGC 和 OGC 变化趋势，再结合 jstat -gcold 中的 OC/OU 判断老年代是否持续上涨。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
YGCT是所有 Young GC 累计耗时（秒），除以YGC得平均单次耗时；若YGCT飙升但YGC增长慢，说明每次 GC 越来越卡，可能有大对象频繁晋升或 Survivor 区太小 - JDK 9+ 开始，
FGC列在 G1 下已弃用，改看jstat -gcold <pid></pid>中的OC是否长期 >90%、OU是否阶梯式上涨 - 留意
EU在两次采样间是否“回不去”——比如上次是 120MB，下次还是 115MB，说明对象没被清掉，可能有内存泄漏苗头
为什么 jstat 显示的内存和 jmap/jconsole 差很多
根本原因是 jstat 统计的是 GC 管理的堆内存分代视图，而 jmap histo 或 jconsole 的“Memory Pool”页展示的是运行时实际内存布局，包括未被 GC 触达的浮动垃圾、TLAB 分配残留、G1 的 Remembered Set 开销等。更关键的是：jstat 的 EC/OC 是 JVM 启动时预估的逻辑容量，实际堆物理分配受 -XX:MaxRAMPercentage 或容器 cgroup 限制，可能远小于配置值。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 容器环境必须加
-XX:+UseContainerSupport（JDK 10+ 默认开启），否则 jstat 读到的max值仍是宿主机内存，导致使用率计算严重失真 - 对比 jstat 和 jmap 时，优先看
jmap -heap <pid></pid>输出里的 “used” 和 “capacity”，它和 jstat 的EU/EC是同一套数据源；而jmap -histo的 total 是对象实例总大小，不含元数据、栈帧、直接内存 - 如果 jstat 显示
OU持续增长但FGC=0，别急着调参——先用jstat -gccause <pid></pid>看最近一次 GC 原因，Allocation Failure是正常，G1 Evacuation Pause是 G1 自身行为，Metadata GC Threshold才意味着 Metaspace 快爆了
实时监控时怎么避免 jstat 自身干扰 GC
jstat 本身是通过 JVM TI 接口 attach 到目标进程的，高频轮询（如 100ms 间隔）会触发 JVM 内部 safepoint 等待，尤其在 GC 频繁时，可能导致 STW 时间被拉长、甚至引发 VM Operation Timeout 错误。这不是 bug，而是设计使然：jstat 要读取 GC 数据，就得让 JVM 暂停线程快照。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 生产环境轮询间隔不低于
1s，压测或问题定位时可临时设为250ms，但不要低于100ms - 避免在 GC 高峰期（如日志显示
YGCT突增）同时跑多个 jstat 实例，每个 attach 都是一次 safepoint 请求 - 长期监控别用 shell while 循环 + jstat，改用 JMX（如 Prometheus + jmx_exporter）或 JVM 自带的
JFR（Java Flight Recorder），它们走的是异步事件流，不依赖频繁 safepoint
GC 状态不是一眼能看懂的数字表，它是分代策略、JVM 版本、GC 算法、运行环境四者咬合的结果。同一个 OU 值，在 ParallelGC 下可能是危险信号，在 G1 下可能只是正常浮动。盯住变化趋势，比记住某一行数值重要得多。
