年轻代对象过早晋升老年代是Full GC频发主因，需通过GC日志查tenuring threshold异常降低、jstat观察Survivor持续满载、核对-Xmn/-XX:SurvivorRatio/-XX:MaxTenuringThreshold参数匹配度，并用jmap+MAT分析老年代对象分布定位真实泄漏源。
年轻代对象过早或过快晋升到老年代，是导致老年代占用飙升、Full GC 频繁的核心原因之一。排查关键不在于“有没有晋升”，而在于“为什么不该晋升的晋升了”。核心思路是：确认晋升行为异常 → 定位触发原因 → 验证代码或配置缺陷。
看 GC 日志确认晋升是否异常
启用详细 GC 日志（推荐 JDK8+）：
- -Xlog:gc*,gc+age=trace:file=gc.log:time,tags,uptime（JDK10+ 推荐）
- 或传统参数：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
重点关注日志中类似这样的行：
Desired survivor size 1048576 bytes, new threshold 1 (max 10)Age table with threshold 1:
age 1: 1234567 bytes, 123456 objects
如果 threshold 很低（如 1 或 2），且大量对象在第一次 Minor GC 后就进入 Survivor 并很快晋升，说明晋升阈值被动态调低——这通常意味着 Survivor 空间不足，发生“担保失败”，被迫提前晋升。
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
用 jstat 观察 Survivor 区使用和晋升行为
执行：jstat -gc -h10 <pid> 1000（每秒刷新，带表头）
- 观察 S0U / S1U 持续接近 100%：说明 Survivor 区太小，无法容纳存活对象，导致对象“挤”进老年代
- 观察 YGC 频率高 + YGCT 上升 + FGC 随之增多：典型“Survivor 溢出 → 提前晋升 → 老年代快速填满 → Full GC”链路
- 对比 EC（Eden 使用率）和 EU（Eden 已用）：若 EC 高但 EU 增长慢，可能有大对象直接分配到老年代（-XX:PretenureSizeThreshold 未设或设得太小）
检查 JVM 参数是否合理
重点核对三组参数是否匹配实际负载：
- -Xmn（年轻代大小）：太小 → Eden 和 Survivor 都紧张 → 晋升加速。建议设为堆总大小的 1/3～1/4（如 -Xmx4g → -Xmn1g～1.3g）
- -XX:SurvivorRatio=N：控制 Eden : S0（或 S1）比例。默认 8 表示 Eden 占年轻代 80%，两个 Survivor 各占 10%。若 Survivor 区频繁打满，可尝试调大（如 -XX:SurvivorRatio=6，使 Survivor 总占比升至 ~33%）
- -XX:MaxTenuringThreshold：仅设上限，不决定实际晋升年龄；真正起作用的是 GC 过程中动态计算的 tenuring threshold（见 jstat 输出中的 “TH” 列或 GC 日志中的 “threshold”），它由 Survivor 容量和存活对象大小共同决定
抓堆快照分析真实晋升对象
在老年代快速增长时，立即执行：
jmap -dump:format=b,file=heap.hprof <pid>用 MAT 打开后重点关注：
- Dominator Tree：排序查看谁占老年代最多（如某个 HashMap、StringBuilder、HTML 字符串缓存）
- Leak Suspects：自动提示疑似泄漏点（例如静态 Map 持有大量 Response 对象）
- 直方图（Histogram）→ Group by package/class：筛选老年代中数量多、单个不大的对象（如 char[]、String、ByteBuf），它们往往是“被长期引用的小对象”，根源常在缓存、日志、模板拼接等逻辑中
特别注意：如果发现大量 HTML 片段、JSON 字符串、Base64 编码数据集中在老年代，大概率是业务层返回前做了冗余拼接或未流式处理，让本该短暂存在的中间对象活过了多次 GC。
