定位任意时刻性能问题，持续性能分析实践解析

作者：义泊

01 持续性能剖析简介

更好的应用性能，可以提供更好的用户体验，可以降低企业IT成本，可以让系统更稳定和可靠。在应用性能剖析技术出现以前，开发人员排查问题只能依赖各种日志和监控，这需要提前在应用代码中埋点，不但对应用代码侵入性较大且可能由于埋点不全而无法提供足够信息，诊断问题非常费时，很多时候无法找出原因。

随着应用性能剖析技术出现，开发人员可以很方便的找出应用程序性能瓶颈（如CPU利用率高、内存占用高等），从而进行优化。但由于早期应用性能剖析技术开销较大，只能在开发环境而不能在生产长时间开启，生产环境出问题时很可能没有被记录下来，开发人员在开发环境模拟和复现问题很困难，导致解决问题的效率很低，也很有可能无法解决。

近些年来，性能剖析技术持续发展，功能越来越丰富，开销也显著改善，达到生产环境持续开启水准，不过离广泛普及还存在诸多障碍。性能剖析一般过程有三步：生产环境抓取、保存性能剖析文件、性能剖析文件可视化。当应用体量较大时，这3个步骤每步都存在着难度，需要解决大量计算、存储、产品设计等多方面问题。

**ARMS Continuous Profiler [ 1] 应运而生，由阿里云ARMS（应用实时监控服务 [ 2] ）团队和Dragonwell [ 3] **团队联合研发。它基于当前最成熟的性能剖析技术，将整个性能剖析过程产品化，适合在生成环境持续开启。与常规性能剖析相比，ARMS Continuous Profiler增加时间维度，核心功能如下：

定位任意时刻的性能问题（比如CPU占用高、内存占用高）
支持两个时段的性能对比，找出应用演进过程中的性能差异
观测应用的调用栈，以便更好的审视和理解代码设计

02 ARMS 持续性能分析功能演示

我们举例来说明如何用ARMS持续性能分析来解决问题。

常见场景一：CPU 热点解析

问题现象

以某图书馆的服务应用举例，其Java进程占用大量CPU，接口响应时间达到了十多秒，应用性能很差。

找出热点方法

因为当前应用CPU占用很高，因此我们直接在性能分析类型中选择CPU Time菜单路径：ARMS控制台 -> 应用首页 -> 应用诊断 -> CPU&内存诊断

从火焰图我们可以看到，java.util.LinedList.node(int)方法占用了85%的CPU，对应的业务代码方法是DemoController.countAllBookPages(List)，结合代码，可以发现，这个方法对于对象很多的集合性能很差，因为要从头或者从尾部逐个遍历。

修复问题

定位到原因后，我们可以通过两个解决方案进行修复。第一个方法是将LinkedList修改为下标访问方式更高效的ArrayList

第二个方法是将LinkedList的遍历算法从普通for循环修改为增强的for循环

性能验证

将修复后的代码重新部署，以相同压力分别压测两种方案，可以看到接口响应时间显著下降，Java进程CPU利用率显著下降。

常见场景二：内存申请热点

问题现象

以某图书馆的服务应用举例，其Java进程占用大量CPU，接口响应时间达到十多秒，应用性能很差。

找出热点方法

因为当前应用CPU占用很高，我们直接在性能分析类型中选择：CPU Time菜单路径：ARMS控制台 -> 应用首页 -> 应用诊断 -> CPU&内存诊断

从CPU热点方法，我们发现Java进程89%的时间都在做GC，说明应用存在很大的内存压力。我们下一步选择内存热点剖析。

从上图的内存申请热点火焰图，我们可以找到过去一段时间所有内存申请中，DemoController.queryAllBooks方法占了99%，进一步检查，可以发现业务代码创建了2万个大对象并保存到了List。

注：这个方法本来应该从数据库中读取2万本书，这里进行了简化，但效果相同，都是在堆中创建了一个占用大量内存的List

修复问题

这个接口本来想实现的是按分页查询书籍列表，但由于实现错误，误将所有书籍都查出来了然后最终只返回了指定分页的部分，所以可以直接从数据库中用分页的方式查询，这样就可以避免大量的Java内存占用。

性能验证

将修复后的代码重新部署，以前相同压力进行压测，可以看到接口响应时间显著下降，Java进程CPU利用率显著下降。

03 ARMS 持续性能分析的设计和实现

1、产品设计

产品整体分为3个部分，第一个部分负责在应用端收集性能剖析数据，第二个部分用于传输和存储剖析结果文件，第三部分用于查询和展示。

第一个部分主要使用**Java Flight Recorder [ 4] 、async-profiler [ 5] **，我们会根据Java版本情况自动选择其一，其核心功能是周期性对应用程序进行采样，并且不会因为安全点问题导致结果不准确。下图是对一个线程采样6次的例子，可以看到每次采样瞬间的调用栈。最终保存为JFR格式的文件。