在日常工作中经常会遇到系统应用出现full gc、cpu内存飙高等场景，如果想要快速解决这些线上问题就需要首先能快速定位，最好能定位到具体代码。本文旨在通过一款线上监控诊断产品，阿里巴巴的arthas（阿尔萨斯）内部集成的火焰图工具async-profiler结合自身系统应用中的使用，方便我们能够快速定位线上问题。

一、背景

1、在订单域任务系统，master机器和slaver机器频繁出现full gc和cpu间歇性升高的现象，young GC也出现平均1分钟10次。master机器线程也增加到1500左右。系统应用采用的是CMS垃圾回收器，4c8g分配堆内存大小4G。但是堆内存和非堆内存正常。

2、随着时间推移，full gc从每隔20分钟一次变成每个5分钟或者3分钟一次，stop the world。FULL GC 和 Young GC 不正常，如下图。

堆内存和非堆内存正常。

CPU一分钟一次达到高点，部分机器达到75%以上。线程，在上午超过1400，重启后正常。

系统稳定性受到挑战，需要尽快排查出问题所在。

二、工具选型及实践

市面上很多排查工具，怎样才能快速排查出问题。结合arthas、async-profiler火焰图（采样）、visualVM（跨时间dump文件对比）、gceasy这四种工具，都进行实战对比。

1、arthas分析

下图分析master机器是反序列化商品域渠道配置接口对象耗CPU

下图也发现反查快手任务也会引起高cpu。分析这台机器既是master，又是slaver。slaver会执行反查快手任务。

2、visualVM分析

dump两个文件，跨时一天，进行对比。

启动visualVM

cd /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/bin

jvisualvm

/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/visualvm目录下 visualvm.conf修改内存空间大小

对比发现，最大是查询ES的数据，反序列化对象并不是最大，但是也能在dump文件中查找到。因为arthas查的是CPU和线程，dump文件是内存，所以不完全一致。

一次500个

3、gceasy分析

修改jvm，-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log，打印gc日志。

通过gceasy.io线上对比工具，没有内存泄露，但是也未发现gc产生的具体原因。

4、async-profiler火焰图

从上图，看到主要分为两大部分，左边的反查快手任务（因master机器，既是master，也是slaver），右边是扫描es里面代扣任务的反序列化对象占用很大比重。和arthas分析的一样。

下载内存火焰图， 可以看到左边也是快手反查，右边则是查询ES（包含反序列化对象）。和dump文件比较能核对上。

三、修复上线

根据上述四种工具的排查过程，可以明显看到使用arthas集成的async-profiler更直观和方便，便于定位问题。在修改对应的代码后，上线进行后续观察系统稳定正常。

四、使用步骤

async-profiler 火焰图。

1、申请堡垒机（root权限）

2、登陆以后下载最新的jar包 wget alibaba.github.io/arthas/arth...

3、安装（admin权限 cd）java -jar arthas-boot.jar

4、查看cpu耗时、dashboard(q命令表示退出)、thread

5、profiler start 启动火焰图工具进行采样

perl 复制代码

https://jlynet.github.io/2021/08/07/Java%E8%AF%8A%E6%96%AD%E5%B7%A5%E5%85%B7Arthas%E9%AB%98%E7%BA%A7%E5%91%BD%E4%BB%A4%E6%95%99%E7%A8%8B/Arthasprofiler%E5%91%BD%E4%BB%A4/

profiler getSamples

profiler status

profiler stop --format html。生成火焰图

6、下载火焰图