🍺 show-busy-java-threads
用于快速排查Java
的CPU
性能问题(top us
值过高),自动查出运行的Java
进程中消耗CPU
多的线程,并打印出其线程栈,从而确定导致性能问题的方法调用。
目前只支持Linux
。原因是Mac
、Windows
的ps
命令不支持列出进程的线程id
,更多信息参见#33,欢迎提供解法。
PS,如何操作可以参见@bluedavy的《分布式Java应用》的【5.1.1 CPU
消耗分析】一节,说得很详细:
top
命令找出有问题Java
进程及线程id
:- 开启线程显示模式(
top -H
,或是打开top
后按H
) - 按
CPU
使用率排序(top
缺省是按CPU
使用降序,已经合要求;打开top
后按P
可以显式指定按CPU
使用降序) - 记下
Java
进程id
及其CPU
高的线程id
- 开启线程显示模式(
- 用进程
id
作为参数,jstack
有问题的Java
进程 - 手动转换线程
id
成十六进制(可以用printf %x 1234
) - 查找十六进制的线程
id
(可以用vim
的查找功能/0x1234
,或是grep 0x1234 -A 20
) - 查看对应的线程栈,以分析问题
查问题时,会要多次上面的操作以分析确定问题,这个过程太繁琐太慢了。
用法
1 | show-busy-java-threads |
示例
1 | $ show-busy-java-threads |
上面的线程栈可以看出,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
实现逻辑和调用方式,以优化实现解决问题。