环境准备与基础信息环境要求Linux 系统JDK8 或 JDK11。第一步获取 Java 进程 PID# 方法一使用 jps jps -l 方法二使用 ps ps -ef | grep java假设获取到的进程 PID 为 12345下文所有命令中的 PID 请替换为你的实际进程 ID。一、线程堆栈 ThreadDump现场抓取建议多次抓取对比ThreadDump 用于排查死锁、线程阻塞、CPU 飙高等问题。方式 1jstack最常用# 输出线程栈到文件 jstack 12345 thread_dump_12345_$(date %Y%m%d_%H%M).txt 连续抓取 3 次间隔 2 秒便于观察线程状态变化 jstack 12345 thread1.txt sleep 2 jstack 12345 thread2.txt sleep 2 jstack 12345 thread3.txt 强制模式当进程无响应时使用 jstack -F 12345 thread_dump_force.txt方式 2kill -3不杀死进程仅输出线程栈kill -3 12345⚠️ 注意这是kill -3不是kill -9。kill -3只是向进程发送信号用于打印线程栈到标准输出通常为 catalina.out 或应用日志。二、内存快照 HeapDump.hprof 文件排查 OOM、内存泄漏1. jmap 手动触发 dump进程存活时抓取# 完整堆 dumplivetrue 只 dump 存活对象推荐过滤死亡对象文件更小 jmap -dump:live,formatb,fileheap_12345_$(date %Y%m%d_%H%M).hprof 12345参数说明live执行 FullGC只保存存活对象文件更小去掉 live 会 dump 全部对象包括垃圾对象。formatb二进制 hprof 格式MAT 等工具可识别。# 强制模式当进程无响应时使用 jmap -dump:live,formatb,fileheap_force.hprof -F 123452. OOM 自动 dump需事前配置故障发生后无法临时添加在 JVM 启动参数中添加以下配置发生 OOM 时自动生成 hprof 文件-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump.hprof两种 OOM 情况JVM 内部 OOMJava 抛出java.lang.OutOfMemoryError进程可能退出也可能僵死不退出假死不响应请求CPU 使用率低。系统层 OOM Killer整机物理内存耗尽操作系统直接杀死 Java 进程dmesg中可见 OOM-kill 记录。业务恢复手段进程僵死进程存在但接口无响应、页面卡死先抓现场再重启进程切勿直接 kill。进程已被系统 OOM Killer 杀死直接启动应用恢复业务。多实例部署若集群有多台机器可先下线故障节点由其他机器承接流量保证业务可用性再排查故障机器。三、GC 日志重点GC 日志不能事后抓取必须 JVM 启动时预先开启JDK8 GC 日志启动参数-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/data/logs/gc-%t.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize100MJDK11 使用统一 Xlog新 API-Xlog:gc*:file/data/logs/gc-%t.log:time,uptimemillis:filecount10,filesize100M故障现场实时查看 GC 状态jstat实时采样# 每 1000ms 输出一次共输出 20 次 jstat -gc 12345 1000 20重点监控指标YGCYoung GC 次数、YGCTYoung GC 时间、FGCFull GC 次数、FGCTFull GC 时间、GCT总 GC 时间。关注 FullGC 次数和总停顿时间。查看 GC 日志若 JVM 启动参数已配置 GC 日志直接查看日志文件关注频繁 FullGC、OOM 异常若未开启历史 GC 日志可现场实时采样 GC 状态jstat -gc PID 1000 30 jstat_gc.log查看应用 stdout/catalina.out 日志# 搜索 OOM 异常堆栈 grep -n OutOfMemoryError app.log若进程已被杀死、不复存在无法通过jstack/jmap抓取 dump只能依赖历史监控、GC 日志、应用日志进行复盘。四、故障现场完整操作脚本可直接复制执行PID12345 DATE$(date %Y%m%d_%H%M%S) 1. 连续 3 次线程 dump jstack $PID thread_dump_${DATE}1.txt sleep 2 jstack $PID thread_dump${DATE}2.txt sleep 2 jstack $PID thread_dump${DATE}_3.txt 2. 堆内存快照注意大堆 dump 会卡顿业务确保磁盘空间充足 jmap -dump:live,formatb,fileheapdump_${DATE}.hprof $PID 3. 实时 GC 采样 jstat -gc $PID 1000 10 jstat_gc_${DATE}.log五、工具总结清单内容命令输出文件用途备注线程堆栈jstack PID xxx.txt.txt死锁、CPU 高、线程阻塞抓 3 次对比卡死用 -F堆内存快照jmap -dump:live,formatb,filexxx.hprof PID.hprof内存泄漏、OOM 分析大堆会 STW占磁盘 IOGC 历史日志JVM 启动参数 -Xloggcgc-xxx.logGC 停顿、频繁 FullGC必须提前开启事后无法抓取实时 GC 状态jstat -gc PID 1000 20控制台输出现场看当前 GC 情况快照采样不是历史日志线程栈备选kill -3 PID输出到应用 stdout/catalina.out线程栈不会杀死进程六、常见注意事项jmap dump 大堆8G会造成业务卡顿尽量在业务低峰期执行故障迫不得已时才执行。GC 日志必须 JVM 启动时配置进程已经挂了就拿不到 GC 历史。hprof 文件需要 MAT 工具解析不要直接使用 vim 打开。执行 jstack/jmap 需要和 Java 进程同用户root 用户有时会因权限问题导致异常。
Java 故障排查：GC 日志、线程堆栈、内存快照 dump 全套命令
环境准备与基础信息环境要求Linux 系统JDK8 或 JDK11。第一步获取 Java 进程 PID# 方法一使用 jps jps -l 方法二使用 ps ps -ef | grep java假设获取到的进程 PID 为 12345下文所有命令中的 PID 请替换为你的实际进程 ID。一、线程堆栈 ThreadDump现场抓取建议多次抓取对比ThreadDump 用于排查死锁、线程阻塞、CPU 飙高等问题。方式 1jstack最常用# 输出线程栈到文件 jstack 12345 thread_dump_12345_$(date %Y%m%d_%H%M).txt 连续抓取 3 次间隔 2 秒便于观察线程状态变化 jstack 12345 thread1.txt sleep 2 jstack 12345 thread2.txt sleep 2 jstack 12345 thread3.txt 强制模式当进程无响应时使用 jstack -F 12345 thread_dump_force.txt方式 2kill -3不杀死进程仅输出线程栈kill -3 12345⚠️ 注意这是kill -3不是kill -9。kill -3只是向进程发送信号用于打印线程栈到标准输出通常为 catalina.out 或应用日志。二、内存快照 HeapDump.hprof 文件排查 OOM、内存泄漏1. jmap 手动触发 dump进程存活时抓取# 完整堆 dumplivetrue 只 dump 存活对象推荐过滤死亡对象文件更小 jmap -dump:live,formatb,fileheap_12345_$(date %Y%m%d_%H%M).hprof 12345参数说明live执行 FullGC只保存存活对象文件更小去掉 live 会 dump 全部对象包括垃圾对象。formatb二进制 hprof 格式MAT 等工具可识别。# 强制模式当进程无响应时使用 jmap -dump:live,formatb,fileheap_force.hprof -F 123452. OOM 自动 dump需事前配置故障发生后无法临时添加在 JVM 启动参数中添加以下配置发生 OOM 时自动生成 hprof 文件-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump.hprof两种 OOM 情况JVM 内部 OOMJava 抛出java.lang.OutOfMemoryError进程可能退出也可能僵死不退出假死不响应请求CPU 使用率低。系统层 OOM Killer整机物理内存耗尽操作系统直接杀死 Java 进程dmesg中可见 OOM-kill 记录。业务恢复手段进程僵死进程存在但接口无响应、页面卡死先抓现场再重启进程切勿直接 kill。进程已被系统 OOM Killer 杀死直接启动应用恢复业务。多实例部署若集群有多台机器可先下线故障节点由其他机器承接流量保证业务可用性再排查故障机器。三、GC 日志重点GC 日志不能事后抓取必须 JVM 启动时预先开启JDK8 GC 日志启动参数-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/data/logs/gc-%t.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize100MJDK11 使用统一 Xlog新 API-Xlog:gc*:file/data/logs/gc-%t.log:time,uptimemillis:filecount10,filesize100M故障现场实时查看 GC 状态jstat实时采样# 每 1000ms 输出一次共输出 20 次 jstat -gc 12345 1000 20重点监控指标YGCYoung GC 次数、YGCTYoung GC 时间、FGCFull GC 次数、FGCTFull GC 时间、GCT总 GC 时间。关注 FullGC 次数和总停顿时间。查看 GC 日志若 JVM 启动参数已配置 GC 日志直接查看日志文件关注频繁 FullGC、OOM 异常若未开启历史 GC 日志可现场实时采样 GC 状态jstat -gc PID 1000 30 jstat_gc.log查看应用 stdout/catalina.out 日志# 搜索 OOM 异常堆栈 grep -n OutOfMemoryError app.log若进程已被杀死、不复存在无法通过jstack/jmap抓取 dump只能依赖历史监控、GC 日志、应用日志进行复盘。四、故障现场完整操作脚本可直接复制执行PID12345 DATE$(date %Y%m%d_%H%M%S) 1. 连续 3 次线程 dump jstack $PID thread_dump_${DATE}1.txt sleep 2 jstack $PID thread_dump${DATE}2.txt sleep 2 jstack $PID thread_dump${DATE}_3.txt 2. 堆内存快照注意大堆 dump 会卡顿业务确保磁盘空间充足 jmap -dump:live,formatb,fileheapdump_${DATE}.hprof $PID 3. 实时 GC 采样 jstat -gc $PID 1000 10 jstat_gc_${DATE}.log五、工具总结清单内容命令输出文件用途备注线程堆栈jstack PID xxx.txt.txt死锁、CPU 高、线程阻塞抓 3 次对比卡死用 -F堆内存快照jmap -dump:live,formatb,filexxx.hprof PID.hprof内存泄漏、OOM 分析大堆会 STW占磁盘 IOGC 历史日志JVM 启动参数 -Xloggcgc-xxx.logGC 停顿、频繁 FullGC必须提前开启事后无法抓取实时 GC 状态jstat -gc PID 1000 20控制台输出现场看当前 GC 情况快照采样不是历史日志线程栈备选kill -3 PID输出到应用 stdout/catalina.out线程栈不会杀死进程六、常见注意事项jmap dump 大堆8G会造成业务卡顿尽量在业务低峰期执行故障迫不得已时才执行。GC 日志必须 JVM 启动时配置进程已经挂了就拿不到 GC 历史。hprof 文件需要 MAT 工具解析不要直接使用 vim 打开。执行 jstack/jmap 需要和 Java 进程同用户root 用户有时会因权限问题导致异常。
