Java FlameGraph 火焰图

时间 2019-12-09 标签 java flamegraph 火焰

上周一个偶然的机会听同事提到了Java FlameGraph，刚实验了一下，效果很是好。html

1、什么是FlameGraphjava

直接看图说话。FlameGraph 是 SVG格式，矢量图，能够随意扩大缩小，看不清的信息能够放大看。图中，各类红橙黄色没有什么意义，仅仅作区分用；x轴横条宽度来度量时间指标，代表每一个接口实际占用的CPU时间；y轴表明线程栈的层次，从最底下往上表示堆栈的层层调用。经过看图，能够发现哪一个接口占用的CPU时间较多，从而优化；同时，能够发现调用关系。git

Java火焰图的做者是Brendan Gregg，他的博客很是有意思，不少关于性能的分析。如下连接是对每一个类别的火焰图的详细说明。github

什么是Java Flame Graphs：Java Flame Graphs浏览器

On-CPU：CPU Flame Graphsjvm

Off-CPU：Off-CPU Flame Graphside

Memory：Memory Leak (and Growth) Flame Graphssvg

Hot/Cold：Hot/Cold Flame Graphs函数

Differential：Differential Flame Graphs工具

关于火焰图的PPT（讲解得很是详细）：Blazing Performance with Flame Graphs

2、如何生成

两个步骤：1. 须要java profiler生成trace文件 2. 将trace文件转换为svg格式的火焰图文件。

1. 须要java profiler生成trace文件

在使用Profiler对CPU进行采样时，根据CPU当前执行所处栈位置以及各个函数栈在总的采样次数所占比例就能够得出各个函数执行时的CPU占用比例。经常使用的是lightweight-java-profiler。还有其余的选择，好比honest-profiler，lightweight-java-profiler会从java虚拟机启动开始采样，而有时候咱们须要在CPU飙高的时候开始，这时候honest-profiler提供的动态启停功能就有用武之地了。也有使用perf生成火焰图。（*perf 要研究一下）

下面以lightweight-java-profiler 举例

（1）从github下载软件

（2）编译 make all

（3）生成的程序存放在build-64文件夹下面

（4）（可选）能够更改一些lightweight-java-profiler的一些选项，打开src/globals.h文件。在长时间采样时，能够适当地减小每秒采样次数，否则最终生成的文件会很大，分析起来比较麻烦。

// 每秒采样频率
static const int kNumInterrupts = 100;
// Maximum number of stack traces线程栈个数
static const int kMaxStackTraces = 3000;
// 采样栈深度
static const int kMaxFramesToCapture = 128;

　　kNumInterrupts: 每秒钟抽取样本的次数；

　　kMaxStackTraces: 线程栈的最大数量　　　

　　kMaxFramesToCapture: 线程栈的深度

（5）运行Java程序

　　java -agentpath:path/to/liblagent.so ......

（6）java程序启动后会在当前目录生成一个traces.txt文件，但文件中只有一些说明信息。程序正常结束（不杀掉进程）后，才会写入具体采样信息。

2.将trace文件转换为svg格式的火焰图文件。

（1）从github下载FlameGraph

（2）转换

　　./stackcollapse-ljp.awk < traces.txt | ./flamegraph.pl > traces.svg

（3）浏览器中打开traces.svg文件

3、简单讨论一下Java profiler

关于采样工具的选取，能够看看文章 Evaluating the Accuracy of Java Profilers ，这里面列举了xprof，hprof，jprofile和yourkit四种采样器，并经过几个压测场景证实了这几种采样器的结果是相互矛盾的。总结的缘由有两点：

1. 采样器采样点不够随机，这几种采样器都只有在safe point采样；

2. 不一样的采样器会注入不一样的代码，从而影响程序优化过程，同时也影响了safe point的分布，进一步形成采样差别；

honest-profiler号称是避开了经过SUN/Oracle management agent去采样堆栈，而是使用本身实现的使用UNIX 操做系统信号和为Oracle Performance Studio 设计的内部API的sampling agent，从而提高了采样准确率。

还有一篇文章和 Why many profilers have serous problems。

Java profiler 的两个常见方式：

1.修改代码，从而实现采样。问题是：1. 增长开销；2. 修改了你的代码，致使java编译器的优化行为不肯定；3. 影响了代码的层次，层次越深天然也影响执行效率。

2.经过获取on-cpu线程的线程栈方式。问题是：获取系统范围的线程栈，jvm必须处于safepoint状态（看文章What is Java safepoint）。只有当线程处于safepoint状态的时候，别的线程才能去获取它的线程栈，而这个safepoint是由jvm 控制的，这对于profiler很是不利，有可能一个很热的代码块，jvm不会在该代码块中间放置safepoint，致使profiler没法得到该线程栈，致使错误的profiler结果。

几个商用的profiler工具都存在上述问题。可是，Oracle Solaris studio利用的是jvmti的一个非标准接口AsyncGetCallTrace来实现，不存在上面问题，Jeremy Manson也利用该接口实现了一个简单的profiler工具：lightweight-java-profiler。