JDK 自带工具jstat /jstack/jmap前提这些命令属于JDK bin不是 JRE只能抓本地 Java 进程需要知道进程 PID查看 PID 命令jps -l最常用jpsJava Virtual Machine Process Status ToolJDK 自带工具专门查看 Java 进程不需要额外安装。-l是 long长格式作用输出PID 主类全限定名 /jar 完整路径# 查看java进程拿到pid jps -l假设示例中 Java 进程 PID 12345一、jstatJVM 运行状态统计工具看 GC、类加载、编译等指标全称JVM Statistics Monitoring ToolJDK 自带实时采样监控 JVM 运行统计最常用就是看 GC 情况jstat [-options] pid [间隔ms] [采样次数]常用 optiongcGC 统计最常用gccapacity堆各区域容量 当前占用gcutilGC 百分比视图推荐一眼看使用率gccausegcutil 最后一次 GC 原因class类加载统计compilerJIT 编译统计场景 1排查频繁 FullGC观察 GC 指标最常用需求每 1000ms 输出一次一共输出 10 次查看 S0、S1、E、O、M 的GC 占比jstat -gcutil 12345 1000 10示例输出S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 89.23 45.12 62.31 94.11 91.23 2145 32.123 12 2.456 34.579字段解释S0/S1Survivor0、Survivor1 使用率EEden 区使用率O老年代 Old 使用率M元空间 Metaspace 使用率YGC年轻代 GC 次数YGCTYGC 总耗时FGCFullGC 次数FGCTFullGC 总耗时GCTGC 总耗时✅ 判断点O 老年代持续上涨不断触发 FGC →内存泄漏FGC 次数持续飙升FGCT 时间变长 → 严重卡顿场景 2查看堆内存各区域容量jstat -gccapacity 12345 1000 5可以看到 Eden、Survivor、Old 的最大容量、当前容量。场景 3查看类加载情况排查类泄漏、元空间满jstat -class 12345输出加载类数量、卸载数量、耗时。如果类持续不断加载不卸载 → 元空间溢出。二、jstack线程栈分析工具死锁、线程阻塞、CPU 高、线程池打满Java Stack TraceJDK 自带工具打印 JVM 内所有线程栈快照作用Java 死锁CPU100%线程无限循环线程阻塞、等待锁线程池耗尽、接口长时间 hang 住语法jstack [-l] pid-l额外输出锁信息long listing排查死锁必加⚠️ 如果进程卡死可以加-F强制 dumpjstack -F 12345但 - F 抓取信息会丢失部分信息优先不用。✅一个进程里面包含多个线程。进程是资源容器线程是 CPU 调度的最小单位。场景 1线上 CPU 飙升定位哪段代码占用 CPU完整排查流程top找到java进程PID12345top -H -p 12345查看进程内线程找到 CPU 最高线程号假设线程号23456十进制jstack 12345 thread.log导出线程栈日志十进制转十六进制printf %x\n 23456→ 0x5ba0nid在 thread.log 搜索nid0x5ba0找到对应线程栈定位代码行-p 12345只监控 PID12345 这个进程-H开启线程模式把进程内部所有线程展示出来top 默认只展示进程不展开线程场景 2排查死锁jstack -l 12345 deadlock.logjstack 会自动检测死锁日志末尾会输出Found one Java-level deadlock打印两个线程互相等待的锁和代码位置。示例死锁片段Found one Java-level deadlock: Thread-A: waiting to lock monitor 0x00007f8b1c003210 (object 0x000000076ac21498, a java.lang.Object), which is held by Thread-B Thread-B: waiting to lock monitor 0x00007f8b1c003320 (object 0x000000076ac214a8, a java.lang.Object), which is held by Thread-A场景 3接口响应缓慢大量线程 WAITING/BLOCKEDjstack 12345 stack.log看线程状态BLOCKED被锁阻塞WAITING等待唤醒lock.wait () / 线程池队列等待TIMED_WAITING限时等待sleepRUNNABLE运行中IO 阻塞也会显示 RUNNABLE常见坑大量线程卡在数据库连接池等待就是大量 WAITING。三、jmap内存映像工具堆内存分析OOM、内存泄漏全称Java Memory MapJDK 自带堆内存分析工具。核心能力查看堆配置、查看当前堆使用情况、dump 堆快照文件用于分析OOM、内存泄漏。语法jmap [option] pid常用 optionjmap -heap pid打印堆配置与当前堆概览快速看堆参数jmap -histo[:live] pid查看堆内对象统计对象数量、占用大小histo所有对象histo:live只统计存活对象会触发 FullGCjmap -dump:formatb,fileheap.hprof pid导出 hprof 堆快照文件核心⚠️ dump 堆文件会暂停应用生产尽量业务低峰操作hprof 文件建议下载本地用 MATMemory Analyzer Tool分析。场景 1快速查看 JVM 堆配置Xmx/Xms/ 新生代比例jmap -heap 12345输出堆最大最小Eden、Survivor、Old 大小垃圾收集器类型。场景 2查看堆中对象数量初步判断内存泄漏jmap -histo:live 12345 histo.log输出按占用内存排序num instances bytes class name 1 1200000 48000000 java.util.ArrayList 2 800000 32000000 com.xxx.entity.User如果自定义实体类数量持续暴涨大概率内存泄漏。场景 3OOM 发生导出堆快照最常用jmap -dump:formatb,fileheap_20261008.hprof 12345拿到heap_20261008.hprof文件下载到本地用 MAT 工具打开看大对象看对象引用链找出是谁持有对象没有释放推荐JVM 启动参数增加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/xxx/OOM 时自动 dump 堆文件不用手动执行 jmap。不推荐场景生产不要频繁执行jmap -histo:live因为加了:live会触发 FullGC线上业务会卡顿。四、三个工具对比总结命令关注点适用场景jstatGC 指标、类加载、JIT持续监控 GC判断是否有 GC 异常jstack线程栈、锁、线程状态CPU 高、死锁、接口 hang、线程阻塞jmap堆内存、对象、堆 dumpOOM、内存泄漏分析对象占用五、一套完整线上故障排查流程示例现象服务接口变慢时不时 OOM老年代持续上涨jps -l获取 pidjstat -gcutil pid 1000观察发现 Old 不断上涨FGC 越来越多jstack pid查看是否有线程泄漏、连接不释放jmap -histo pid看到自定义业务对象数量持续暴涨jmap -dump:formatb,fileheap.hprof pid导出堆文件MAT 分析 hprof找到对象引用链定位代码泄漏点六、扩展Q1jstat -gcutil 各个字段含义FGC 持续上涨代表什么答S0 S1 E O M CCS YGC YGCT FGC FGCT GCTS0Survivor0 使用率S1Survivor1 使用率EEden 区使用率O老年代使用率M元空间 Metaspace 使用率CCS压缩类空间使用率YGC年轻代 GC 次数YGCTYGC 总耗时FGCFullGC 次数FGCTFullGC 总耗时GCTGC 总耗时FGC 持续上涨分两种情况每次 FGC 后 Old 能明显下降正常业务短期大对象可观察每次 FGC 后 Old 下降很少很快又涨满内存泄漏对象无法回收需要 jmap dump 堆分析。面试加分FGC 非常耗时间会 STW频繁 FGC 会造成接口超时、服务卡顿。Q2jstack 怎么排查 CPU100%完整步骤答top找到 Java 进程 PIDtop -H -p pid查看进程内所有线程找到 CPU 最高的十进制线程 idprintf %x\n 线程id转为十六进制 nidjstack pid thread.log导出线程栈在日志搜索nid0x十六进制值定位到对应线程栈找到阻塞 / 死循环代码。注意jstack 输出里的 nid 是十六进制top 看到的线程号是十进制很多人这里踩坑。Q3jstack 看到大量 BLOCKED、WAITING 分别是什么含义答BLOCKED线程正在等待监视器锁synchronized拿不到锁被阻塞大概率锁竞争激烈、死锁WAITING无限等待等待被其他线程唤醒如Object.wait()、LockSupport.park()常见线程池无任务、数据库连接池拿不到连接TIMED_WAITING限时等待Thread.sleep()、wait(time)RUNNABLE运行中注意网络 IO 阻塞时线程状态依然是 RUNNABLE这点很容易答错。Q4jmap -histo 和 jmap -histo:live 的区别生产慎用哪个为什么答jmap -histo pid打印堆中所有对象统计不触发 FullGCjmap -histo:live pid只统计存活对象执行前会触发一次 FullGC。生产慎用histo:live因为 FullGC 会 STW业务请求卡顿高峰期可能雪崩。Q5jmap dump 堆快照有什么风险生产什么时候 dump答风险dump 过程会STW暂停应用hprof 文件大小接近堆最大值占用大量磁盘 IO堆越大dump 耗时越长。最佳实践低峰期 dump优先配置 JVM 参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmpOOM 时自动 dump不需要人工执行 jmap拿到 hprof 下载到本地用 MAT 分析不要在线上直接分析。Q6jstat、jstack、jmap 三者分工故障排查时使用顺序答jstat宏观监控看 GC 指标先判断有没有内存 / GC 问题jstack线程层面查 CPU 高、死锁、接口 hangjmap内存对象层面OOM、内存泄漏dump 堆快照。排查顺序jps→jstat确认 GC 异常→jstack看线程是否阻塞→jmap导出堆定位泄漏对象Q7jstack -F 参数作用缺点答jstack pid正常抓取当进程卡死正常 jstack 无法响应时使用jstack -F pid强制 dump。 缺点强制抓取会丢失部分信息丢失 Java 锁信息优先不用。Q8容器环境使用这些命令有什么坑答容器内 Java 进程 PID 是容器内 PID宿主机看不到 解决启动容器添加--pidhost共享宿主机 pid 命名空间 另外注意JDK 镜像必须装 JDK不能只用 JRE缺少 jstat/jstack/jmap 工具。Q9OOM 一定是内存泄漏吗答不一定。内存泄漏对象不再使用但是一直被引用GC 无法回收Old 持续上涨非泄漏 OOM一次性加载超大文件 / 大查询瞬间分配对象超过堆上限堆配置太小。可以通过 jstat 观察区分泄漏是缓慢持续涨老年代大对象是瞬间把 Old 打满。Q10jstat 可以看线程堆栈吗jstack 能看 GC 指标吗答都不行。 jstat只输出统计指标看不到代码堆栈 jstack只打印线程栈不统计 GC、内存占用 各司其职。