jstat+ jstack综合分析系统性能指南

1. 工具定位与数据关联

工具	核心能力	常用参数
jstat	实时监控堆内存、GC 频率与耗时	-gcutil, -gccapacity, -gc
jstack	分析线程状态、锁竞争、死锁	-l（锁信息）

联合分析逻辑：

• 内存不足 → GC 频繁 → 线程阻塞：jstat 发现老年代（Old Gen）内存不足引发 Full GC，jstack 查找 WAITING 线程是否因 GC 停顿阻塞。
• 锁竞争 → 线程堆积 → GC 压力：jstack 发现大量线程竞争锁，导致处理延迟，jstat 观察到 Young GC 次数增加（任务积压产生大量临时对象）。

---

2. 典型场景与操作步骤

---

场景 1：因频繁 Full GC 导致线程阻塞

现象：请求延迟升高，系统吞吐量下降，偶发超时。
操作：

1. 通过 jstat 检查 GC 状态：

   jstat -gcutil <pid> 1000 10  # 每秒采集一次，总共10次
   

   • 观察 FGCT（Full GC 时间）和 O（Old Gen 使用率）：

     S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT 
     0.00  99.80  87.40  99.70  94.27  91.03   2000   15.320    18    8.450   23.770
     

     关键点：O=99.7% 表示老年代已满，引发频繁 Full GC（FGC=18次，耗时 8.45秒）。

2. 通过 jstack 分析线程状态：

   jstack -l <pid> > full_gc_block.txt
   

   • 搜索线程状态：

     "http-nio-8080-exec-5" #31 daemon prio=5 tid=0x00007f8a1412a800 nid=0x3d2 waiting on condition
        java.lang.Thread.State: WAITING (parking)
             at sun.misc.Unsafe.park(Native Method)
             - parking to wait for <0x000000076ab1c1d8> (a java.util.concurrent.linkedblockingqueue)
        Locked ownable synchronizers: None
     

     结论：Full GC 导致系统暂停（STW），线程因 GC 停顿进入 WAITING 状态。

3. 综合诊断：

   • 根本原因：老年代内存不足（可能因内存泄漏或堆大小配置不当）。
   • 验证方式：通过 jstat -gcoldcapacity <pid> 检查老年代容量增长速度。

---

场景 2：锁竞争引发 Young GC 频繁

现象：CPU 使用率高，但 Young GC 次数（YGC）远高于正常值。
操作：

1. 通过 jstat 监控年轻代行为：

   jstat -gc <pid> 1000 5  # 每秒1次，共5次
   

   • 观察 YGC 次数和 YGCT：

     S0C    S1C    ... YGC     YGCT
     5120.0 5120.0 ... 2503   45.231  # 2秒内YGC增加5次（异常）
     

2. 通过 jstack 查找锁竞争：

   jstack -l <pid> > high_ygc.txt
   

   • 搜索 BLOCKED 线程：

     "Thread-2" #12 prio=5 tid=0x00007f8a1412b800 nid=0x4e2 waiting for monitor entry
        java.lang.Thread.State: BLOCKED (on object monitor)
             at com.example.CacheService.updateCache(CacheService.java:20)
             - waiting to lock <0x000000076ac382c0> (a com.example.Cache)
     

     结论：线程因锁竞争阻塞，任务处理延迟，积压的临时对象触发 Young GC。

3. 优化方向：

   • 减少锁粒度（如将全局锁拆分为分段锁）。
   • 用 ConcurrentHashMap 替代 synchronized 代码块。

---

场景 3：内存泄漏导致线程资源耗尽

现象：堆内存持续增长，Full GC 无法释放，线程池任务拒绝。
操作：

1. 通过 jstat 跟踪老年代增长：

   jstat -gcold <pid> 3000  # 每3秒采集一次
   

    OGCMN       OGCMX        OGC         OC       FGC      FGCT
     87360.0    174784.0    174784.0    174784.0     35    20.123  # OGC持续占满
   

2. 通过 jstack 分析线程持有对象：

   • 查找线程的 Locked ownable synchronizers 或 waiting on condition 关联的对象。
   • 发现某线程持有一个未关闭的数据库连接池对象，持续积累 ResultSet 引用。

3. 修复方案：

   • 确保资源（如连接、流）在 finally 块中释放。
   • 使用内存分析工具（如 MAT）检查泄漏对象引用链。

---

3. 自动化分析脚本示例

实现定时采集 jstat 和 jstack 数据，便于对比：

#!/bin/bash
PID=$(jps -l | grep MyApp | awk '{print $1}')
timestamp=$(date +%Y%m%d_%H%M%S)

# 采集 jstat 数据（GC 变化）
jstat -gcutil $PID 1000 10 > gc_$timestamp.log &

# 每隔 5 秒采集一次 jstack
for i in {1..3}; do
   jstack -l $PID > jstack_${timestamp}_$i.txt
   sleep 5
done

---

4. 数据分析技巧

指标组合	问题指向	验证方法
YGC 陡增 + 线程 BLOCKED	锁竞争导致临时对象堆积	jstack 搜索锁等待，检查年轻代对象类型
FGC 频繁 + 线程 WAITING	Full GC 导致线程停顿，系统响应变慢	分析堆转储（jmap -dump + MAT）
O 持续 100% + 线程池满	内存泄漏，线程等待资源无法释放	jstat -gcoldcapacity 监控老年代增速

---

5. 注意事项

1. 采集时机：在性能问题发生时立即抓取数据（如 CPU 突增、延迟升高）。
2. 数据关联：确保 jstat 和 jstack 数据时间戳接近（在 10 秒内）。
3. 工具补充：
   • jmap：生成堆转储分析内存对象分布（jmap -dump:format=b,file=heap.bin <pid>）。
   • GC 日志：启用 JVM 参数（如 -Xloggc:gc.log）获取详细 GC 事件。

---

总结

jstat 提供内存与 GC 的实时量化指标，jstack 揭示线程行为与锁状态，两者结合可精确诊断：

• GC 问题（内存不足、泄漏）导致线程阻塞。
• 线程问题（锁竞争、死锁）引发内存压力。
  通过多工具协同分析、自动化脚本采集和指标关联，能快速定位性能瓶颈，指导代码优化与参数调优（如堆大小、线程池配置）。