通过堆内存变化模式可判断核心业务对象存活时长：关注Survivor留存比例（5%–15%为正常）、老年代晋升量稳定性、对象年龄分布（预期2–3次GC晋升）、及老年代增速反推平均存活时间，四者交叉验证生命周期是否符合业务逻辑。
直接看堆内存变化前后的数字，就能判断核心业务对象“活了多久”——关键不是绝对值，而是变化模式是否匹配你的业务逻辑。
盯住年轻代回收后 Survivor 区的留存比例
Minor GC 后，日志里类似 PSYoungGen: 33456K->4567K(36864K) 这样的字段，重点看箭头后那个数字（4567K）占 Survivor 总容量（36864K）的比例。如果稳定在 5%–15%，说明大多数对象确实在 Eden 区就死了，符合“朝生夕死”的业务特征；若长期高于 25%，就要怀疑：订单、用户会话、缓存实体等本该短期存在的对象，是不是被意外持有（比如静态集合、未清理的 ThreadLocal）而滞留下来了。
比对多次 Minor GC 后老年代的增长节奏
提取连续 5–10 次 Minor GC 日志中老年代使用量（如 56789K->27890K(120320K) 的第二个数字），画个简易趋势图。如果每次晋升量（即老年代增量）基本恒定（比如每次+1.2MB），说明对象生命周期稳定、可预测；但如果某次突增 3 倍以上，且紧随其后出现 Full GC，大概率是某笔批量查询返回了千级 DTO 对象，或某个定时任务加载了全量配置未释放——这就是生命周期异常拉长的信号。
结合 -XX:+PrintTenuringDistribution 看对象年龄分布
启用该参数后，每次 GC 日志末尾会打印 Survivor 中各年龄对象大小，例如：
Desired survivor size 2129920 bytes, new threshold 7 (max 15) - age 1: 12456784 bytes, 12456784 total - age 2: 3456789 bytes, 15913573 total - age 7: 1234 bytes, 15914807 total
如果核心订单对象（预期存活 2–3 次 GC）大量堆积在 age 6 或 age 7，说明它们被反复复制却迟迟不晋升——往往因为 Survivor 区太小被迫提前进入老年代，或被某个长生命周期对象（如单例服务类）意外强引用。这时要检查对象图，而非单纯调大 Survivor。
用老年代占用增速反推平均存活时间
假设系统稳定运行 1 小时，老年代从 200MB 增至 450MB，共发生 120 次 Minor GC，则平均每轮晋升约 2.08MB。若你业务中一个典型订单对象平均 4KB，那每轮约有 520 个订单对象晋升。再结合你已知的订单平均处理时长（比如 8 分钟），就能交叉验证：8 分钟 ÷ （1 小时 / 120 次）≈ 16 次 GC —— 若实际晋升集中在前 3–5 次，说明对象实际存活远短于业务周期，可能存在过早缓存或冗余持有。
