使用JDK自带工具解决性能问题

原创已于 2025-06-16 23:29:20 修改 · 974 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#java

于 2025-06-16 23:27:43 首次发布

Java 同时被 2 个专栏收录

64 篇文章

订阅专栏

JVM

11 篇文章

订阅专栏

JVM调优实战案例：使用JDK自带工具解决性能问题

下面我将通过几个典型案例，展示如何使用Java自带工具进行JVM调优。这些案例都基于JDK自带的工具，无需安装第三方软件。

案例1：Full GC频繁导致系统卡顿

问题描述

某电商系统在促销活动期间，每隔几分钟就会出现一次Full GC，导致系统响应变慢，用户投诉增多。

调优步骤

使用jps查找Java进程ID

jps -l
# 输出示例：
# 12345 com.example.EcommerceApplication

使用jstat监控GC情况

jstat -gcutil 12345 1000 10
# 每1秒采样一次，共10次

输出示例：

 S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0.00  99.80  18.45  98.31  95.47  91.03    134    1.246    33    8.334    9.580
  0.00  99.80  22.15  98.45  95.47  91.03    134    1.246    33    8.334    9.580
  0.00  99.80  25.85  98.67  95.47  91.03    134    1.246    34    8.634    9.880

分析：老年代(O)使用率持续在98%以上，Full GC(FGC)频繁发生

使用jmap生成堆转储文件

jmap -dump:format=b,file=heap.hprof 12345

使用jhat分析堆转储(或使用VisualVM)

jhat heap.hprof
# 访问 http://localhost:7000

分析发现大量未释放的订单缓存对象

解决方案

# 启动参数调整
java -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=200 \
     -XX:InitiatingHeapOccupancyPercent=35 \
     -XX:+PrintGCDetails -Xloggc:gc.log \
     -jar application.jar

调整后效果：

新生代增大到2G，减少对象过早晋升
使用G1收集器并设置最大停顿时间
降低IHOP值让G1更早开始回收

案例2：CPU使用率持续100%

问题描述

后台批处理系统CPU使用率持续100%，任务执行时间比平时长3倍。

调优步骤

使用top找到高CPU的Java进程

top -c
# 发现PID为6789的Java进程CPU占用98%

使用jstack获取线程快照

# 连续获取3次线程栈，间隔1秒
for i in {1..3}; do jstack 6789 > thread_$i.txt; sleep 1; done

分析线程栈
发现多个线程卡在同一个方法上：

"BatchThread-3" #23 prio=5 os_prio=0 tid=0x00007f487c0b7000 nid=0x1b03 runnable [0x00007f486b7fe000]
   java.lang.Thread.State: RUNNABLE
        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
        at java.util.regex.Pattern$Loop.match(Pattern.java:4785)
        at java.util.regex.Pattern$GroupTail.match(Pattern.java:4717)
        at java.util.regex.Pattern$BranchConn.match(Pattern.java:4568)
        at java.util.regex.Pattern$CharProperty.match(Pattern.java:3777)
        at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
        at java.util.regex.Pattern.match(Pattern.java:1133)
        at java.util.regex.Matcher.match(Matcher.java:1270)
        at com.example.DataParser.parse(DataParser.java:45)

使用jstat确认没有GC问题

jstat -gcutil 6789 1000 3

输出显示GC正常，确认是业务代码问题

解决方案
优化DataParser.java中的正则表达式：

预编译正则表达式Pattern
减少复杂正则，拆分多个简单匹配
添加缓存避免重复解析

案例3：内存泄漏导致OOM

问题描述

服务运行一周左右就会出现OutOfMemoryError，需要定期重启。

调优步骤

配置JVM在OOM时自动转储

java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/path/to/dumps \
     -jar application.jar

使用jmap手动生成堆转储(在OOM前)

jmap -dump:format=b,file=oom_heap.hprof 9876

使用jhat分析堆转储
发现某个静态Map持续增长，存储用户会话信息但从未清理
使用jmap查看对象直方图

jmap -histo:live 9876 | head -20

输出：

 num     #instances         #bytes  class name
----------------------------------------------
   1:       543,876     372,392,456  [Ljava.util.HashMap$Node;
   2:       543,870     261,057,600  java.util.HashMap
   3:       543,862     130,526,880  com.example.UserSession
   4:        32,548      41,661,440  [B

解决方案

修复内存泄漏：为静态Map添加LRU淘汰策略或改用WeakHashMap
添加监控：使用JMX监控Map大小
启动参数调整：

java -Xmx2g -XX:+UseG1GC \
     -XX:+ExplicitGCInvokesConcurrent \
     -XX:+HeapDumpOnOutOfMemoryError \
     -jar application.jar

案例4：线程死锁导致服务无响应

问题描述

服务偶尔会完全停止响应，请求超时，但进程仍在运行。

调优步骤

使用jstack检测死锁

jstack 5432 > thread_dump.txt

分析线程转储
在文件末尾发现死锁报告：

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f0134003f58 (object 0x00000000ff4e6f28, a java.lang.Object),
  which is held by "Thread-2"
"Thread-2":
  waiting to lock monitor 0x00007f0134004f58 (object 0x00000000ff4e6f30, a java.lang.Object),
  which is held by "Thread-1"

使用jcmd获取更多信息

jcmd 5432 Thread.print

解决方案

重构锁获取顺序，确保全局一致的获取顺序
使用tryLock()添加超时机制
添加死锁检测监控：

# 定期检查死锁
jcmd <pid> Thread.print | grep deadlock

案例5：合理设置堆大小

问题描述

新服务上线后性能不佳，GC日志显示频繁的Young GC和偶发的Full GC。

调优步骤

使用jstat查看内存使用情况

jstat -gc 1234 1s

分析GC日志

java -Xlog:gc*:file=gc.log -jar application.jar

发现：

Young GC频繁(每3-5秒一次)
每次Young GC存活对象约200MB
老年代每周增长约1GB

使用jmap查看堆使用

jmap -heap 1234

优化方案

# 调整前
java -Xms2g -Xmx2g -jar application.jar

# 调整后
java -Xms4g -Xmx4g -Xmn3g -XX:SurvivorRatio=8 \
     -XX:MaxTenuringThreshold=5 \
     -XX:+UseG1GC -XX:MaxGCPauseMillis=150 \
     -jar application.jar

调整要点：