-xx:+printgcdetails 用于记录垃圾回收时各内存区域占用变化，帮助推断对象是否被回收、何时及在哪一代被回收；java 中回收的是堆上不再被引用的对象实例，而非变量本身。
理解日志中的回收线索
每次 GC 日志行都是一次“快照对比”。例如：
[GC (Allocation Failure) [PSYoungGen: 123456K->12345K(234567K)] 234567K->134567K(567890K), 0.0234567 secs]
- PSYoungGen: 123456K→12345K：年轻代使用量从 123MB 降到 12MB，说明大量新对象（比如方法内创建的临时变量所指向的对象）被回收了
- 箭头左侧数字大、右侧小 → 回收有效；若右侧接近左侧（如 123456K→123400K），说明存活对象多，可能有内存泄漏或对象过早晋升
- 若某次 Young GC 后，Old 区使用量明显上升（看中间部分 234567K→134567K 中老年代贡献变大），说明部分对象躲过 Minor GC 晋升到了老年代——这些对象往往由长生命周期变量（如静态缓存、单例成员）长期持有
定位“谁没被回收”的实用技巧
仅靠 PrintGCDetails 无法知道具体哪个变量没释放，但可结合日志模式缩小范围：
- 持续观察某类 GC 后 Old 区或 Metaspace 增长稳定且不可逆，大概率是静态集合类（如
static Map<string object></string>）在不断 put，对应变量虽在方法结束时出作用域，但静态引用一直持有着对象 - 出现 [Full GC (Ergonomics)] 或频繁 Full GC，且老年代回收前后变化极小（如 528K→516K），说明老年代对象基本不死亡——检查是否有全局监听器、未注销的回调、线程局部变量（ThreadLocal）残留
- 日志中反复出现 (Allocation Failure) 触发 Young GC，但 Eden 区每次几乎填满才触发，说明应用高频创建短生命周期对象（如循环内 new String、JSON 解析生成的 Map/List），对应变量虽及时出作用域，但分配压力大，需关注对象复用或池化
必须搭配的辅助参数
单独用 -XX:+PrintGCDetails 信息有限，务必组合以下参数才能支撑有效分析：
-
-Xloggc:gc.log（JDK 8）或-Xlog:gc*:gc.log（JDK 9+）：把日志落盘，避免刷屏丢失 -
-XX:+PrintGCDateStamps：带绝对时间，方便和业务日志（如请求开始/结束时间）对齐，确认某次慢接口是否引发 GC -
-XX:+PrintGCTimeStamps：显示 JVM 启动后相对秒数，适合看 GC 频率趋势 -
-XX:+PrintHeapAtGC：在每次 GC 前后打印完整堆分布（含各 Survivor 区、老年代起止地址），能看清对象年龄分布和晋升情况 -
-XX:+PrintTenuringDistribution：专看对象在 Survivor 中经历多少次 GC 还活着，辅助判断-XX:MaxTenuringThreshold设置是否合理
注意 JDK 版本差异
日志格式和启用方式在不同版本差别较大：
- JDK 8：用
-XX:+PrintGCDetails -Xloggc:gc.log -XX:+PrintGCDateStamps即可 - JDK 9+：旧参数被标记为 deprecated，推荐统一日志框架：
-Xlog:gc*,gc+heap=debug,gc+age=trace:file=gc.log:time,tags,uptime，支持按标签过滤（如只查元空间回收：-Xlog:gc+metaspace） - 新版日志结构更清晰，每行带明确 tag（如
gc,heap,age），便于脚本解析或导入 GC Easy 等工具做可视化分析
