Linux虚拟机上JVM长时间卡顿排查求助

1. 配置JVM自动捕获诊断信息 #

当JVM无响应时手动工具可能失效，提前配置参数让JVM自动生成关键诊断数据：

• 添加以下JVM启动参数：

  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/dump/path
  -XX:+PrintConcurrentLocks -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
  -Xloggc:/your/gc/log/path/gc.log
  -XX:+UnlockDiagnosticVMOptions -XX:+PrintHungThreads -XX:HungThreadThreshold=300000
  

  其中HungThreadThreshold设置为5分钟（300000毫秒），JVM检测到线程挂起超过这个时间会自动打印线程信息。

2. 系统层面排查（JVM无响应时的核心手段） #

直接从操作系统层面分析进程状态，定位阻塞根源：

• 用top/htop观察进程的CPU、内存、磁盘IO使用率，确认冻结期间是否有资源耗尽的情况。
• 执行iostat -x 1查看磁盘IO的读写速率、等待时间（%util），排查是否是磁盘IO阻塞导致日志写入或JVM操作停滞。
• 用ss -anp | grep <PID>检查进程的网络连接状态，看是否有大量未完成的网络请求（比如TIME_WAIT、ESTABLISHED状态异常）。
• 运行strace -p <PID>跟踪进程的系统调用，观察冻结期间是否长时间卡在某个系统调用（如write、read、futex）上，直接定位到IO、锁等待等问题。
• 使用perf record -g -p <PID>采集性能数据，之后用perf report分析内核态和用户态的热点函数，排查性能瓶颈。

3. 验证日志系统本身的问题 #

两行相邻日志间隔2分钟，先排除日志框架或磁盘的影响：

• 临时替换日志代码为System.err.println("DEBUG 1");和System.err.println("DEBUG 2");，观察控制台输出间隔，若恢复正常则说明是日志框架配置（如异步队列阻塞）或磁盘IO的问题。
• 检查日志框架的配置：比如是否开启异步日志、队列大小是否足够，同步日志的话是否有磁盘挂载点故障。

4. 排查垃圾回收停顿 #

长时间GC是Java应用冻结的常见原因：

• 分析生成的gc.log，查看冻结期间是否发生Full GC、G1混合收集停顿时间过长等情况。
• 用jstat -gcutil <PID> 1000实时监控GC状态，观察Eden区、老年代的使用率和GC频率，确认是否是GC导致的停顿。

5. 分析线程阻塞/死锁 #

即使jstack无响应，也可以通过以下方式获取线程信息：

• 尝试用jcmd <PID> Thread.print获取线程栈，部分场景下jcmd比jstack更可靠。
• 若JVM完全无响应，执行gcore <PID>生成进程核心转储文件，之后用jhsdb jstack --core <core-file> --exe <path/to/java>分析线程栈，定位死锁或长时间阻塞的线程。

内容的提问来源于stack exchange，提问作者BF_PI