[转帖]性能优化必备——火焰图

性能,优化,必备,火焰 · 浏览次数 : 0

小编点评

## Flame Graph 的生成原理以下是通过 Demo 代码分析火焰图的步骤： 1. **获取当前运行 main 函数的 PID：** 使用 `TOP` 命令获取 JVM 堆栈信息，并写入 `tmp.txt` 文件。 2. **统计方法执行时间：** 从 `tmp.txt` 文件中获取每个方法的执行时间。 3. **归并方法执行时间：** 对所有方法的时间进行归并，并按执行时间排序。 4. **分析火焰图：** 根据归并结果，确定方法执行时间最长的那个方法是性能瓶颈。 5. **定位性能瓶颈根因：** 比较火焰图中方法执行时间的最高值和平均值，可以确定性能瓶颈的根因。 ## 结论通过分析火焰图，我们可以定位性能瓶颈的根因，并进行性能优化。在代码中，我们可以记录方法执行时间，然后通过归并和排序的方式，找出性能瓶颈。最后，通过分析火焰图，我们可以确定性能瓶颈的根因。

正文

引言

本文主要介绍火焰图及使用技巧，学习如何使用火焰图快速定位软件的性能卡点。
结合最佳实践实战案例，帮助读者加深刻的理解火焰图构造及原理，理解 CPU 耗时，定位性能瓶颈。

背景

当前现状

假设没有火焰图，你是怎么调优程序代码的呢？让我们来捋一下。

1. 功能开关法

想当年我刚工作，还是一个技术小白时，排查问题只能靠玄学，大致能猜出问题可能是由某个功能代码导致的，此时的排查手段就是删除多余的功能代码，然后再运行查看 CPU 消耗，确定问题。（至今我工作时还会发现一些老人使用如此方法调试性能。）

public void demo() {

    if (关闭1) {
        // 功能1
        handle1();
    }

    if (关闭2) {
        // 功能2
        handle2();
    }

    if (打开3) {
        // 功能3
        handle3();
    }

    // 功能4
    handle4();
}

此法全靠“经验”和“运气”，而且改动了代码结构，假设这是一个已经通过测试的集成区代码，此时需要修改代码功能来调试程序是非常危险的一件事，当然有 Git 仓库可以“一键还原”，但是，是人操作，总归会有失手的时候，且定位效率太低

2. StopWatch 埋点法

当程序出现性能问题时，且不确定是哪一段代码导致耗时，可以借助方法耗时来判断，此时我们只要在调用方法前后追加执行所需耗时日志，即可判定到底是哪个方法最耗时。

public void demo() {
    Stopwatch stopwatch = Stopwatch.createStarted();
    handle1();
    log.info("method handle1 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle2();
    log.info("method handle2 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle3();
    log.info("method handle3 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle4();
    log.info("method handle4 cost: {} ms", 
             stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
}

此法较上一个方法的优势是，不改变代码的逻辑情况下，只是增强了一些观测点位，由方法的耗时来定位性能瓶颈。但是，假设方法的处理调用栈很深，就不得不在子方法中再次埋点，此时判定流程即为：埋点 -> 发版 -> 定位 -> 埋点 -> 发版 -> 定位 -> .......且本质上也是改了代码，就有出错的可能。心累，不高效！

3. TOP 命令定位热线程

一般企业的软件服务都是部署在 Linux 操作系统上，有经验的老手排查性能最方便的办法就是 top 定位。

top -p pid -H

明显看到，pid 103 消耗了 40%的 CPU, 找到对应的 stack 线程信息如下（忽略查找办法，我假设你已经会了：））：

此时可以得出结论，当前最耗 CPU 的线程是写入磁盘文件，追查代码最终会定位到是因为在高并发场景下打了大量的 INFO 日志，导致磁盘写入成为瓶颈。

总结：TOP 命令对于找 CPU 性能瓶颈时很有效的，但是存在如下几个问题：

排名最前的一定是当时最消耗 CPU 的，但不一定是程序性能的诱因。例如因某个 BUG 导致打印了大量 ERROR 日志，最终 LOG 到磁盘是最消耗 CPU的，但罪魁祸首不是它。
TOP 注定使你只会关注最高的，等你修复最耗 CPU 的问题后，往往还会遇到别的程序问题导致 CPU 偏高，即一次只能看到一个问题，看不到全貌。
文本的表现力非常有限：首先你得对 Linux 及 JVM 命令非常熟悉，其次文本对两个及以上值做关联性分析时，就捉襟见肘了，此时就迫切的需要另一种分析工具——图。

什么是火焰图

火焰图（Flame Graphs），因其形似火焰而得名。

如上就是一个典型的火焰图，它由各种大小/颜色的方块组成，每个方块内部还标识了文字，整个图片顶部凹凸不平，形似一簇簇“火苗”，因此得名火焰图。
火焰图是 SVG 生成，因此可以与用户互动，鼠标悬浮在某个方块时，会详细展示内部文字。点击后，即会以当前被点击方块为底向上展开。

特征
使用火焰图分析之前，我们得首先了解火焰图的基本构造

每一列代表一个调用栈，每一格代表一个被调用函数
方块上的字符标识调用方法，数字表示当前采样出现次数
Y 轴表示调用栈深度，X 轴将多个调用栈归并，并首字母排序展示
X 轴宽度表示采样数据中出现频次，即宽度越大，导致性能瓶颈的原因可能就越大（注意：是可能，不是确定）
颜色没什么意义，随机分配（可能创始人想让你看起来更像一个火焰。。）

火焰图可以做什么

那此时你已经知道了火焰图，如何定位软件问题呢？我们需要一套寻找性能瓶颈的方法论。
可以明确的是 CPU 消耗高的口径
```
CPU 消耗高的口径 = 调用栈出现频率最高的一定是吃 CPU 的
```

如上我们已经知道了火焰图的构造，及“物料”含义，此时我们的关注点应该在方形的宽度上，方形的宽度大小代表了该调用栈在整个抽样历史中出现的次数。次数意味着频率，即出现次数越多的即可能最消耗 CPU。

但只关注最长的是没用的，如底部的 root 和中部的方块都很宽，只能说明这些方法是“入口方法”，即每次发起调用都会经过的方法。
我们更应该关注火焰山顶部的"平顶山"（plateaus）出现的次数多，即没有子调用，抽样出现的频率高，说明执行方法的时间较长，或者执行频率太高（如长轮询），即CPU 大部分执行都分配给了“平顶山”，它才是性能瓶颈的根因。

总结方法论：火焰图看“平顶山”，山顶的函数可能存在性能问题！

最佳实践

实践是检验真理的唯一标准！下面我将以一个小的 Demo 来展示如何定位程序性能问题，加深对火焰图使用的理解。

Demo 程序如下：

public class Demo {

    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(20);

        while (true) {
            executorService.submit(Demo::handle1);
            executorService.submit(Demo::handle2);
            executorService.submit(Demo::handle3);
            executorService.submit(Demo::handle4);
        }
    }

    @SneakyThrows
    private static void handle4() {
        Thread.sleep(1000);
    }

    @SneakyThrows
    private static void handle2() {
        Thread.sleep(50);
    }

    @SneakyThrows
    private static void handle3() {
        Thread.sleep(100);
    }

    @SneakyThrows
    private static void handle1() {
        Thread.sleep(50);
    }
}

代码很简单，当然现实中也不会这么写，主要是配合演出。。
主要是开了一个线程池，且分别执行四个 task，不同的 task 耗时不一致，此时我们的性能瓶颈在 handle4 这个任务上，在知道结论的前提下，我们比较看火焰图得出答案的是否符合预期！

1. JVM堆栈信息拉取

当前我是在自己的 Mac 上运行的程序，idea 执行这一段程序非常便捷，那如何获取当前运行 main 函数的 PID？
此时需要用到 TOP 命令，上面是个 while 死循环，很明显吃 CPU最厉害，只要找到归属 Java 线程的最高一个 PID 即为所求。

很明显得到 COMMAND = java 最高的 PID = 20552
此时执行如下命令获取堆栈信息，并写入 tmp.txt 文件

jstack -l 20552 > tmp.txt

2. 生成火焰图

生成火焰图的工具有很多，我一般会借助 FastThread，在线分析堆栈，非常方便，同时支持生成火焰图，方便我们定位问题

打开官网首页，选择刚刚 dump 的堆栈文件，点击 Analyze，此时只需要等待网站分析好后（正常 3~5 s），即可查看火焰图

fastThread 网站分析报告非常丰富，一般的问题我们直接通过它给出的结论基本能定位到问题了，本文暂且无需关注，感兴趣的话，后续我会分享，直接拉到 Flame Graph 子标题处

此时明显能看出4个“平顶山”，且 com.Demo.handle4 宽度最大，com.Demo.handle3 次之，符合预期！

原理剖析

基于上述小 Demo ，我们深入理解下火焰图的生成原理。

举个例子，便于你理解，假设我们要观测一个人在忙些什么，哪些事最占用他的时间，会怎么做？
从时间维度的话，且不考虑成本的话，我肯定安排一个监控摄像头，全天候 24h，360度监控他，然后再安排人员，逐帧排查，并汇总他所做的事，得出：睡觉 8h，工作8h，玩手机 4h，吃饭2h，其它2h。从而得出结论：睡觉占用他时间最多。

由上可以总结一套分析流程：

记录（监控）-> 分析&归并（逐帧排查） ->  Top N -> 得出结论

带着流程去看我们应该如何排查 CPU 在执行中，哪些事（进程/线程）最占用它的时间呢？
简单粗暴的方法是每时每刻都记录执行的方法堆栈，再汇总归并，得出最耗时的方法栈在哪。此法的问题在于

数据量大
时间长

其实只要采样去观测 CPU 在干什么就好了，这是一个概率学问题，如果 CPU 因为执行某个方法耗时，大概率采样下来，得到的归并结果也是最多的，虽然有误差，但是多次统计下，差不了多少的。
同理，dump 下的堆栈，查看大多数线程在干什么，依据堆栈内每个方法出现的频率聚合，出现的频次最多的就是当前 CPU 分配执行最多的方法。

"pool-1-thread-18" #28 prio=5 os_prio=31 tid=0x00007f9a8d4c0000 nid=0x8d03 sleeping[0x000000030be59000]
    java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at com.Demo.handle2(Demo.java:31)
    at com.Demo$$Lambda$2/1277181601.run(Unknown Source)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

    Locked ownable synchronizers:
- <0x00000006c6921ac0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

至于我们的 jstack 信息如何被处理成火焰图的格式，社区已经为常见的 dump 格式都提供了工具，stackcollapse-jstack.pl 处理 jstack 输出。

Example input:

"MyProg" #273 daemon prio=9 os_prio=0 tid=0x00007f273c038800 nid=0xe3c runnable [0x00007f28a30f2000]
    java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:121)
        ...
        at java.lang.Thread.run(Thread.java:744)

Example output:

MyProg;java.lang.Thread.run;java.net.SocketInputStream.read;java.net.SocketInputStream.socketRead0 1

总结&展望

火焰图的介绍到此结束，相信你又多了一种排查问题的手段！
存在即合理，工具之开发重要性而言不必多说，我始终持包容态度面对新事物，它确确实实解决了某些痛点而脱颖而出的。
后续我会介绍更多排查问题的手段，如果你喜欢本文风格，请关注或留言，欢迎讨论！