服务器GC日志分析入门：从开启参数到定位内存问题
当Java应用响应变慢、CPU飙升或内存持续上涨时，GC日志往往是第一个能说明问题的证据。
它记录了JVM每次垃圾回收的时间、回收前后内存变化和停顿原因，能帮你判断是内存分配不合理、对象泄漏，还是GC参数需要调整。
这篇文章按零基础也能照做的顺序，讲清如何开启、读取和利用GC日志。
开启GC日志前需要确认的环境
GC日志分析的前提是JVM已经输出了日志。
不同JDK版本参数写法不同，先确认版本：
java -version如果是JDK 8，常用参数如下，加到启动脚本的JAVA_OPTS中：
-Xloggc:/var/log/app/gc.log
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=20MJDK 9及以上推荐使用统一日志框架：
-Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=20M注意：日志目录必须提前创建并给运行用户写权限，否则JVM可能启动失败。
生产环境建议保留轮转，避免单个日志文件无限增长占满磁盘。
修改参数后需重启应用，重启前确认有回滚方案。
看懂GC日志里的关键字段
以JDK 8的ParNew日志为例：
2024-05-10T10:12:33.456+0800: 12345.678: [GC (Allocation Failure) [ParNew: 614400K->68096K(614400K), 0.0521234 secs] 921600K->389632K(1982464K), 0.0523456 secs]需要重点看这几项：
Allocation Failure：触发原因，表示新生代空间不足，属于正常现象。614400K->68096K(614400K)：新生代回收前、回收后、总容量。回收后仍接近总容量说明对象存活多。0.0521234 secs：本次GC耗时。- 整行末尾的
921600K->389632K(1982464K)：堆整体回收前后和总堆大小。
Full GC日志通常带有Full GC字样，耗时明显更长。
如果出现Full GC (System.gc())，要检查代码中是否有显式调用System.gc()。
用日志定位三类常见问题
频繁Young GC：日志中Allocation Failure密集出现，间隔很短。
常见原因是新生代过小或对象创建速率过高。
可以先观察每次回收后存活对象是否稳定，再考虑调整-Xmn或改用G1。
频繁Full GC：短时间内多次出现Full GC，且回收后老年代占用仍居高不下，通常指向内存泄漏或缓存无上限。
用jmap -histo:live 查看对象实例数，结合业务代码排查集合类是否持续增长。
单次GC停顿过长：关注日志中的secs数值。
如果单次超过1秒且影响接口超时，需要评估堆大小、GC算法和对象生命周期。
G1可通过-XX:MaxGCPauseMillis设置目标停顿，但它不是硬性保证。
避坑与验证
不要只凭一次日志下结论。
建议连续观察至少一个业务高峰周期，对比GC频率、耗时和堆占用趋势。
调整参数后，用同样的日志格式再跑一轮，确认改善是否稳定。
如果日志中出现OutOfMemoryError，先保留日志和堆转储文件，再重启服务，避免现场丢失。
堆转储可通过-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/app/配置。
验证是否生效，可以检查日志文件是否按预期轮转、时间戳是否连续、GC次数是否下降。
若日志没有生成，优先检查启动参数是否被脚本覆盖，以及目录权限是否正确。
