java 排查性能问题,JVM那点事—show-busy-java-threads排查CPU性能问题

show-busy-java-thread用于快速排查Java的CPU性能问题(top us值过高)，自动查出运行的JAVA进程中消耗CPU多的线程，并打印出其线程栈，从而确定导致性能问题的方法调用。

1. 以往方法

top命令找出消耗CPU高的Java进程及其线程id：

i. 开启线程的显示模式(top -H，或者打开top后按H)。

ii. 按cpu使用率排序(top缺省就是按CPU的使用率降序)。

iii. 记下Java进程id及其CPU高的线程id。

查看消耗CPU高的线程栈：

i. 用进程id作为参数，jstack出有问题的Java进程。

ii. 手动转换线程id成16进制(可以使用printf %x pid)。

iii. 在jstack输出中查找16进制的线程id(jstack -l pid > test.txt | grep16进制的值)

查看对应的线程栈，分析问题。

查问题时，会要多次上面的操作以分析确定问题，这个过程太繁琐太慢了。

2. show-busy-java-threads命令

2.1 安装

推荐使用直接在网络上下载安装包，并解压的方式。

## 下载安装包

source-shell

wget --no-check-certificate https://github.com/oldratlee/useful-scripts/archive/release.zip

## 解压

unzip release.zip

2.2 常用命令

使用方式：sh show-busy-java-threads.sh

2.2.1 基本命令

# 从所有运行的Java进程中找出最消耗CPU的线程(缺省5个)，打印出其线程栈

show-busy-java-threads

# 缺省会自动从所有的Java进程中找出最消耗CPU的线程，这样用更方便

# 当然你可以手动指定要分析的Java进程Id，以保证只会显示你关心的那个Java进程的信息

show-busy-java-threads -p

show-busy-java-threads -c

# 多次执行

show-busy-java-threads []

# 记录到文件以方便回溯查看

show-busy-java-threads -a

# 指定jstack输出文件的存储目录，方便记录以后续分析

show-busy-java-threads -S

2.2.2 注意事项

# 如果Java进程的用户 与 执行脚本的当前用户 不同，则jstack不了这个Java进程

# 为了能切换到Java进程的用户，需要加sudo来执行，即可以解决：

sudo show-busy-java-threads

# 对于sudo方式的运行，JAVA_HOME环境变量不能传递给root，

# 而root用户往往没有配置JAVA_HOME且不方便配置，

# 显式指定jstack命令的路径就反而显得更方便了

show-busy-java-threads -s

2.2.3 其他命令

# -m选项：执行jstack命令时加上-m选项，显示上Native的栈帧，一般应用排查不需要使用

show-busy-java-threads -m

# -F选项：执行jstack命令时加上 -F 选项(如果直接jstack无响应时，用于强制jstack)，一般情况不需要使用

show-busy-java-threads -F

# -l选项：执行jstack命令时加上 -l 选项，显示上更多相关锁的信息，一般情况不需要使用

# 注意：和 -m -F 选项一起使用时，可能会大大增加jstack操作的耗时

show-busy-java-threads -l

2.3 示例

$ show-busy-java-threads

[1] Busy(57.0%) thread(23355/0x5b3b) stack of java process(23269) under user(admin):

"pool-1-thread-1" prio=10 tid=0x000000005b5c5000 nid=0x5b3b runnable [0x000000004062c000]

java.lang.Thread.State: RUNNABLE

at java.text.DateFormat.format(DateFormat.java:316)

at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)

at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:127)

at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

[2] Busy(26.1%) thread(24018/0x5dd2) stack of java process(23269) under user(admin):

"pool-1-thread-2" prio=10 tid=0x000000005a968800 nid=0x5dd2 runnable [0x00000000420e9000]

java.lang.Thread.State: RUNNABLE

at java.util.Arrays.copyOf(Arrays.java:2882)

at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)

at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)

at java.lang.StringBuffer.append(StringBuffer.java:320)

- locked <0x00000007908d0030> (a java.lang.StringBuffer)

at java.text.SimpleDateFormat.format(SimpleDateFormat.java:890)

at java.text.SimpleDateFormat.format(SimpleDateFormat.java:869)

at java.text.DateFormat.format(DateFormat.java:316)

at com.xxx.foo.services.common.DateFormatUtil.format(DateFormatUtil.java:41)

at com.xxx.foo.shared.monitor.schedule.AppMonitorDataAvgScheduler.run(AppMonitorDataAvgScheduler.java:126)

at com.xxx.foo.services.common.utils.AliTimer$2.run(AliTimer.java:128)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:662)

......

上面的线程栈可以看出，CPU消耗最高的2个线程都在执行java.text.DateFormat.format，业务代码对应的方法是shared.monitor.schedule.AppMonitorDataAvgScheduler.run。可以基本确定：

AppMonitorDataAvgScheduler.run调用DateFormat.format次数比较频繁。

DateFormat.format比较慢。(这个可以由DateFormat.format的实现确定。)

多执行几次show-busy-java-threads，如果上面情况高概率出现，则可以确定上面的判定。

因为调用越少代码执行越快，则出现在线程栈的概率就越低。

脚本有自动多次执行的功能，指定 重复执行的间隔秒数/重复执行的次数 参数。

分析shared.monitor.schedule.AppMonitorDataAvgScheduler.run实现逻辑和调用方式，以优化实现解决问题。

推荐阅读

相关文章