Java GC日志是定位停顿、内存泄漏及GC性能问题的核心依据；需按JDK版本选用参数：JDK 8用-XX:+PrintGCDetails等，JDK 9+推荐-Xlog:gc*:file=gc.log:time,tags,uptime,level，并关注Pause、Allocation Failure等关键信号及STW停顿时长。
Java 垃圾回收（GC）日志是定位应用停顿、内存泄漏和 GC 性能问题的核心依据。开启后，结合日志中的时间戳、GC 类型、堆内存变化和暂停时长，就能快速判断停顿是否由 GC 引起，以及具体是哪类 GC（Young GC / Full GC / ZGC 并发阶段等）导致。
开启 GC 日志的 JVM 参数（JDK 8/11/17 兼容写法）
推荐使用统一、可读性强的日志格式（以 JDK 8–17 通用参数为例）：
- -Xloggc:/path/to/gc.log：指定 GC 日志输出路径（JDK 9+ 推荐用 -Xlog，但 -Xloggc 在 JDK 8 和部分 JDK 11 仍有效）
- -XX:+PrintGCDetails：打印详细 GC 信息（如各代大小、回收前后占用、晋升量）
- -XX:+PrintGCDateStamps 或 -XX:+PrintGCTimeStamps：添加时间戳（建议用 -XX:+PrintGCDateStamps，便于关联业务日志）
- -XX:+UseGCLogFileRotation + -XX:NumberOfGCLogFiles=5 + -XX:GCLogFileSize=10M：启用日志滚动，防止单文件过大
✅ JDK 9+ 更推荐统一使用 -Xlog（功能更强、更结构化）：
- -Xlog:gc*:file=/path/to/gc.log:time,tags,uptime,level:filecount=5,filesize=10M
- 其中 gc* 表示开启所有 GC 相关日志（包括 gc+heap、gc+ergo、gc+age 等），可根据需要精简，例如只看停顿：-Xlog:gc+pause
识别关键停顿指标：看懂日志里的“Stop-The-World”
真正影响响应延迟的是 STW（Stop-The-World）事件。重点关注日志中明确标有 Pause、(to-space exhausted)、Full GC、Allocation Failure 或 Concurrent Mode Failure 的条目。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 年轻代 GC（ParNew / G1 Young / ZGC Pause）：单次停顿通常几毫秒到几十毫秒；若频繁发生（如每秒多次），说明对象创建过快或 Survivor 区太小，导致对象提前晋升
- 老年代 GC（CMS / G1 Mixed / ZGC End-of-cycle）：CMS 的 concurrent mode failure 或 G1 的 to-space exhausted 会触发退化为 Serial Old，停顿可达数百毫秒甚至秒级
- Full GC：几乎总是 STW，原因常见于 System.gc() 调用、元空间耗尽、CMS 失败、G1 回收失败、JDK 10+ 的 ZGC 不再有传统 Full GC，但 GC cycle end 仍有短暂停顿
分析停顿根因的典型线索
不要只看“用了多久”，要结合上下文看“为什么发生”和“发生了什么”：
- 日志开头出现 [Full GC ... ] 或 [Pause Full GC] → 检查是否显式调用了 System.gc()（加 -XX:+DisableExplicitGC 规避）、元空间是否不足（-XX:MaxMetaspaceSize）、老年代碎片或已满
- 频繁 ParNew + Promotion Failed / to-space exhausted → 年轻代过小、SurvivorRatio 设置不合理、对象存活时间长（如缓存未设 TTL）、存在大对象直接进老年代（-XX:PretenureSizeThreshold）
- G1 日志含 “Evacuation Failure” 或 “Mixed GC did not collect enough” → 增加 -XX:G1HeapWastePercent（默认 5%），或调大堆、降低 -XX:G1MixedGCCountTarget
- ZGC / Shenandoah 日志中 Pause 后紧跟 “Load Addresses” 或 “Relocate” → 正常并发阶段后的短暂停顿；若 Pause 时间突增（>10ms），检查是否 CPU 资源争抢、TLB miss 高、或堆太大导致地址映射开销上升
辅助分析工具推荐
纯文本日志难定位趋势，建议配合工具提升效率：
- GCEasy（https://gceasy.io）：上传 gc.log 自动分析停顿分布、GC 频率、内存泄漏迹象、给出优化建议（免费版够用）
- GCViewer：离线桌面工具，适合对比多轮压测日志，可视化 Young/Old GC 吞吐与停顿曲线
-
VisualVM / JConsole + GC 插件：运行时监控 Eden/Survivor/Old 使用率，结合 jstat -gc
实时验证日志结论
停顿分析不是只看一次日志，而是“参数 → 日志 → 工具图表 → 调优 → 再验证”的闭环。重点始终落在：这次停顿是不是 GC 引起？是哪一类 GC？它为什么被触发？有没有避免路径？
