JDK 8/9须用-XX:+PrintGCDetails等传统参数组合，JDK 10+必须用-Xlog:gc*:file=...，混用会导致日志失效或启动失败；路径权限、滚动策略、关键标签（如gc+heap、gc+age）缺一不可，容器中还需校验cgroup内存限制与-Xmx匹配。
GC日志参数没配对，等于没日志——查问题时只能靠猜。修复核心不是“换一套参数”，而是让日志能真实、完整、可读地反映 GC 行为，并适配当前 JDK 版本和运行环境。
确认 JDK 版本，选对日志开关语法
不同 JDK 对日志配置方式差异很大，混用会导致日志不输出或 JVM 启动失败：
- JDK 8 / 9：必须用传统参数组合，缺一不可：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
少了-XX:+PrintGCDetails，就看不到 Eden/Survivor 变化；少了-XX:+UseGCLogFileRotation，单个日志可能涨到几个 GB，后续分析卡死。 - JDK 10+（含 JDK 17/21）：统一用
-Xlog，传统参数部分失效或被忽略：
-Xlog:gc*:file=/data/logs/gc.log:time,level,tags:filecount=10,filesize=100M
注意gc*是通配，包含 gc、gc+heap、gc+age 等子标签；若只写-Xlog:gc，会漏掉关键的晋升年龄、堆分布等信息。 - 常见错误：JDK 17 还硬加
-XX:+PrintGCDetails，或 JDK 8 误用-Xlog——JVM 启动直接报错退出。
路径与权限必须实际可用
日志写不进磁盘，比不配还危险——你以为有日志，其实全是空文件：
- 路径必须是绝对路径，且目录已存在、有写权限。例如
-Xloggc:/data/logs/gc.log，先执行mkdir -p /data/logs && chown appuser:appgroup /data/logs； - 容器环境要特别注意：挂载卷是否覆盖了日志目录？Pod 重启后 /tmp 是否被清空？推荐固定挂载一个持久化路径，如
/app/logs； - 验证是否真在写：启动后立刻执行
ls -lh /data/logs/gc.log*，再等 30 秒看文件大小是否增长；也可用tail -f /data/logs/gc.log实时观察。
补全关键诊断字段，别只留“基本日志”
只开 -XX:+PrintGC 或 -Xlog:gc，等于只记“发生了 GC”，却不知道“为什么发生、谁占了内存、对象怎么流动”：
- 必加年龄分布（定位晋升风暴）：
JDK 8/9 加-XX:+PrintTenuringDistribution；
JDK 10+ 加-Xlog:gc+age=debug； - 必加堆内存快照（判断碎片与分配压力）：
JDK 8/9 加-XX:+PrintHeapAtGC；
JDK 10+ 加-Xlog:gc+heap=debug； - 线上建议默认开启
-Xlog:gc+metaspace=debug，元空间泄漏往往比堆泄漏更隐蔽，但日志里一行Metaspace used=420MB, committed=450MB, reserved=1100MB就能快速定性。
容器环境要额外校验 cgroup 与日志一致性
在 Kubernetes 或 Docker 中，JVM 看到的内存上限 ≠ 宿主机物理内存，日志里显示“老年代用了 1.8G”，但 cgroup limit 只有 2G，那 Full GC 就是必然结果：
- 启动后立即检查：
cat /sys/fs/cgroup/memory/memory.limit_in_bytes，对比 JVM 的-Xmx；若前者明显更小（比如 2G limit 配了-Xmx4g），JVM 会因无法申请内存而频繁触发Allocation Failure； - 此时日志中会出现大量
GC (Allocation Failure)，但堆使用率并不高——本质是 OS 层面拒绝分配，不是 GC 算法问题； - 修复方式：要么调低
-Xmx至 cgroup limit 的 75%（留出元空间、直接内存余量），要么在容器启动时显式设置--memory=4g并同步调整 JVM 参数。
