Java线上故障排查核心是快速定位OOM、死锁、高CPU或响应慢类型，再用jps、jstat、jmap、jcmd等JDK原生命令直击JVM状态，不依赖GUI、不重启、不加探针。
线上 Java 故障排查，核心是快速定位问题类型（OOM、死锁、高 CPU、响应慢），再用 JDK 命令行工具直击 JVM 底层状态——不依赖 GUI、不重启服务、不加探针，原生命令最稳。
第一步：确认目标进程 PID
所有后续操作都依赖准确的进程 ID。别靠 ps aux | grep java 猜，容易误杀或漏掉：
-
jps -l：显示完整主类名或 JAR 路径，精准区分多个 Spring Boot 应用（如/opt/app.jar） -
jps -m：带启动参数，可识别不同 profile（如-Dspring.profiles.active=prod） -
jps -v：查真实 JVM 参数，验证是否开了-XX:+HeapDumpOnOutOfMemoryError或-XX:NativeMemoryTracking=summary - 容器环境注意：
jcmd -l更可靠，但需确保/proc和/tmp可读写；若为空，检查是否启用-XX:+DisableAttachMechanism
第二步：按故障类型选工具组合
不是每个问题都从 jstat 开始，要对症下药：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
堆内存 OOM 或持续 Full GC：先用
jstat -gc <pid> 2000观察 EU（Eden 使用率）、OU（老年代使用率）、YGC/FGC 次数。若 OU 持续上涨且 FGC 频繁，立刻执行jmap -dump:format=b,file=heap.hprof <pid>抓快照（注意磁盘空间 ≥ -Xmx） -
线程卡死或死锁：用
jcmd <pid> Thread.print（比 jstack 更稳定，不卡在 IN_NATIVE）；输出后搜索deadlock或WAITING/BLOCKED线程栈，重点关注锁对象和持有者 -
内存“大户”不明，怀疑泄漏：运行
jcmd <pid> GC.class_histogram（等价于jmap -histo:live），看实例数和字节数排序前列的类；若某业务类排前三且数值异常高，就是重点嫌疑对象 -
堆外内存飙升（DirectByteBuffer、JNI）：先确认启动加了
-XX:NativeMemoryTracking=summary，再执行jcmd <pid> VM.native_memory summary，盯住[thread]、[class]、[internal]模块增长趋势
第三步：关键参数与避坑细节
命令本身简单，但参数错一个就白忙：
立即学习“Java免费学习笔记（深入）”；
-
jmap -dump会触发 Full GC，生产环境慎用；若服务敏感，改用jmap -histo <pid>先看摘要 -
jstat -gc -t <pid> 5000加-t输出时间戳，方便关联日志时间点 -
jinfo -flag +PrintGCDetails <pid>可动态开启 GC 日志（JDK 8u60+ 支持），无需重启 -
jcmd <pid> VM.flags -all能看到 JVM 自动推导的参数（如-XX:MaxRAMPercentage算出的实际堆大小），比配置文件更真实 - 所有 dump 文件（.hprof）体积大，建议压缩后下载分析，避免直接在生产机上用 MAT 打开
第四步：日常巡检推荐最小集
每天花 2 分钟执行，早发现问题早干预：
-
jps -l：确认关键进程还在 -
jstat -gc <pid> 1000 3：看最近 3 秒 GC 是否平稳 -
jcmd <pid> VM.system_properties | grep spring.profiles.active：核对当前生效 profile -
jcmd <pid> VM.native_memory summary（若已启用 NMT）：查原生内存有无缓慢上涨
