使用Arthas排查Java应用CPU性能瓶颈：从监测到解决

以下文章来源：mp.weixin.qq.com/s/C_02drs0D…

一、引言

在Java应用运行过程中，性能问题往往在最意想不到的时刻出现 - 系统负载突然飙升、接口响应变慢、CPU使用率居高不下。更棘手的是，这些问题通常只在生产环境中出现，难以在开发环境复现。传统的问题排查方法需要修改代码、添加日志、重启应用，这在生产环境中几乎是不可接受的。

阿里巴巴开源的Java诊断工具Arthas应运而生，它提供了一种无侵入式的方法来实时分析生产环境中的Java应用性能问题。本文将深入探讨如何使用Arthas来排查和解决CPU性能瓶颈问题，从监测到定位，再到最终解决。

二、基础概念

2.1 Arthas是什么？

Arthas（阿尔萨斯）是阿里巴巴开源的一款Java应用诊断工具，它允许开发者在不修改代码、不重启应用的情况下，对线上系统进行问题排查。Arthas支持JDK 6+，适用于Linux、Mac和Windows系统，提供命令行交互模式，并具有丰富的Tab自动补全功能。

2.2 CPU性能瓶颈常见原因

在深入Arthas工具之前，我们先了解一下Java应用中常见的CPU性能瓶颈原因：

1. 1. 死循环或低效循环：代码中的无限循环或处理大量数据的低效循环
2. 2. 频繁GC：过多的对象创建与销毁导致频繁垃圾回收
3. 3. 线程竞争：多线程环境下的资源争用和锁竞争
4. 4. 复杂计算：算法复杂度过高，如O(n²)或更高复杂度的算法
5. 5. 资源泄漏：未正确关闭资源导致的系统负担增加

三、Arthas安装与启动

安装Arthas

Arthas提供了多种安装方式，最简单的是使用arthas-boot.jar：

复制代码

# 下载arthas-boot.jar
curl -O https://arthas.aliyun.com/arthas-boot.jar

# 启动Arthas
java -jar arthas-boot.jar

对于Linux/Unix/Mac系统，也可以使用一键安装脚本：

复制代码

curl -L https://arthas.aliyun.com/install.sh | sh

启动并连接到目标Java进程

启动Arthas后，它会列出当前系统中运行的所有Java进程：

复制代码

$ java -jar arthas-boot.jar
* [1]: 12345 com.example.MainApplication
  [2]: 23456 org.apache.catalina.startup.Bootstrap

输入进程序号（如1）选择要诊断的Java进程，Arthas将会附加到该进程并启动命令行界面。

四、CPU性能问题排查流程

步骤1：全局监控与热点识别

首先使用dashboard命令获取系统整体情况，包括线程、内存和GC信息：

复制代码

$ dashboard

该命令会显示实时更新的系统信息，包括：

• • JVM内存使用情况
• • GC情况
• • 线程数量和状态
• • 最繁忙的前N个线程及其CPU使用率

通过观察dashboard输出，我们可以快速识别出CPU使用率较高的线程。

步骤2：定位高CPU线程

一旦发现系统CPU使用率异常，使用thread命令进一步分析线程情况：

复制代码

# 查看所有线程信息
$ thread

# 查看CPU使用率前N的线程
$ thread -n 3

# 查看指定线程的详细堆栈
$ thread 线程ID

thread -n 3命令会列出CPU使用率最高的3个线程，包括线程ID、名称、CPU使用率和线程状态。通过这些信息，我们可以初步定位到可能存在问题的线程。

步骤3：方法执行分析

一旦确定了可能有问题的线程，下一步是分析该线程正在执行的方法。Arthas提供了几个强大的命令来跟踪方法执行：

使用trace命令分析方法调用耗时

trace命令可以跟踪指定方法的调用路径和每个调用的耗时：

复制代码

# 跟踪类的方法调用
$ trace com.example.Service methodName

# 限制捕获次数
$ trace com.example.Service methodName -n 5

# 设置跟踪的最大深度
$ trace com.example.Service methodName --depth 3

输出示例：

复制代码

`---ts=2023-07-11 16:15:41;thread_name=http-nio-8080-exec-5;id=16;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@5c45d770
    `---[8.066072ms] com.example.Service:methodName()
        +---[0.018104ms] com.example.Utils:helperMethod1() #23
        +---[7.048928ms] com.example.Utils:helperMethod2() #25
        `---[0.883391ms] com.example.Utils:helperMethod3() #30

通过这个输出，我们可以清楚地看到方法调用链以及每个方法的执行时间，快速定位到耗时较长的方法。

使用stack命令查看调用栈

stack命令可以显示方法的调用路径，帮助我们了解方法是如何被调用的：

复制代码

$ stack com.example.Service methodName

输出示例：

复制代码

ts=2023-07-11 16:20:41;thread_name=http-nio-8080-exec-2;id=13;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@5c45d770
    @com.example.Service.methodName()
        at com.example.Controller.handleRequest(Controller.java:42)
        at com.example.Controller.processRequest(Controller.java:21)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
        ...

这个输出显示了methodName方法的完整调用栈，帮助我们了解该方法在何处被调用。

步骤4：使用profiler进行性能分析

Arthas的profiler命令基于async-profiler，可以生成火焰图来直观地展示CPU热点：

复制代码

# 启动CPU性能分析
$ profiler start

# 运行30秒后停止分析
$ profiler stop --format html --file /tmp/cpu-profile.html

生成的火焰图可以直观地显示CPU时间在各个方法上的分布，帮助我们快速识别热点方法。

在火焰图中：

• • Y轴表示调用栈深度
• • X轴表示CPU时间占用
• • 每个方块代表一个方法，宽度越大表示占用CPU时间越多
• • 颜色越亮的区域通常是热点

步骤5：监控方法执行

一旦确定了可能的问题方法，我们可以使用monitor命令持续监控该方法的执行情况：

复制代码

$ monitor -c 5 com.example.Service methodName

这个命令会每5秒统计一次methodName方法的执行次数、平均RT、成功率等信息：

复制代码

 timestamp            class                                     method         total  success  fail  avg-rt(ms)  fail-rate
---------------------------------------------------------------------------------------------------------------------------
 2023-07-11 16:30:00  com.example.Service                       methodName     10     10       0     79.00       0.00%
 2023-07-11 16:30:05  com.example.Service                       methodName     11     11       0     81.12       0.00%
 2023-07-11 16:30:10  com.example.Service                       methodName     9      9        0     83.78       0.00%

步骤6：查看方法的入参和返回值

使用watch命令可以查看方法的入参和返回值，帮助我们理解方法执行的上下文：

复制代码

# 查看方法入参和返回值
$ watch com.example.Service methodName "{params, returnObj}" -x 2

# 查看方法抛出的异常
$ watch com.example.Service methodName "{params, throwExp}" -e

输出示例：

复制代码

method=com.example.Service.methodName location=AtExceptionExit
ts=2023-07-11 16:35:00; [cost=168.779ms] result=@ArrayList[
    @Object[][
        @Integer[10000],
    ],
    java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3332)
        at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
        ...
]

这个输出显示方法执行时抛出了OutOfMemoryError异常，并且入参是10000，这可能是导致CPU使用率高的原因之一。

五、实际案例分析：CPU飙升问题排查

让我们通过一个实际案例来展示Arthas如何帮助排查CPU飙升问题。

问题背景

某电商平台的订单服务在促销活动期间CPU使用率突然飙升至90%以上，系统响应变得极其缓慢。运维团队紧急联系开发人员进行排查。

排查过程

1. 全局监控

首先使用dashboard命令获取系统整体情况：

复制代码

$ dashboard

输出显示多个线程的CPU使用率较高，其中一个名为"order-processing-thread-3"的线程CPU使用率达到了78%。

2. 定位高CPU线程

使用thread命令查看CPU使用率最高的线程：

复制代码

$ thread -n 3

输出：

复制代码

ID        NAME                           GROUP                  PRIORITY   STATE      CPU%      DELTA_TIME TIME      INTERRUPTED DAEMON     
12        order-processing-thread-3      main                   5          RUNNABLE   78.57     0.000      0:0       false       false      
11        order-processing-thread-2      main                   5          RUNNABLE   10.23     0.000      0:0       false       false      
14        GC Thread                      system                 5          RUNNABLE   5.78      0.000      0:0       false       true       

查看线程12的详细堆栈：

复制代码

$ thread 12

输出显示该线程正在执行com.example.order.PromotionService.calculateDiscount方法。

3. 方法执行分析

使用trace命令分析calculateDiscount方法的执行情况：

复制代码

$ trace com.example.order.PromotionService calculateDiscount

输出：

复制代码

`---ts=2023-07-11 20:15:41;thread_name=order-processing-thread-3;id=12;is_daemon=false;priority=5;TCCL=sun.misc.Launcher$AppClassLoader@5c647e05
    `---[1520.166072ms] com.example.order.PromotionService:calculateDiscount()
        +---[0.018104ms] com.example.order.OrderItem:getPrice() #126
        +---[0.045928ms] com.example.order.OrderItem:getQuantity() #126
        +---[1519.883391ms] com.example.order.PromotionEngine:applyRules() #127
            +---[1519.701273ms] com.example.order.RuleEngine:evaluate() #89
                +---[1519.523591ms] com.example.order.RuleEngine:findMatchingRules() #142
                    `---[1519.482173ms] com.example.order.RuleEngine:iterateRuleSet() #201

从输出可以看出，RuleEngine.iterateRuleSet方法占用了大量CPU时间。

4. 性能分析

使用profiler命令生成火焰图：

复制代码

$ profiler start
$ profiler stop --format html --file /tmp/cpu-profile.html

火焰图清晰地显示RuleEngine.iterateRuleSet方法是主要的CPU热点，特别是其中的一个循环。

5. 查看方法实现

使用jad命令反编译RuleEngine.iterateRuleSet方法：

复制代码

$ jad com.example.order.RuleEngine iterateRuleSet

反编译结果显示：

复制代码

private List<Rule> iterateRuleSet(Order order) {
    List<Rule> matchingRules = new ArrayList<>();
    for (Rule rule : allRules) {  // allRules包含数万条规则
        boolean isMatch = true;
        for (OrderItem item : order.getItems()) {
            // 低效的嵌套循环
            for (Condition condition : rule.getConditions()) {
                if (!condition.evaluate(item)) {
                    isMatch = false;
                    break;
                }
            }
            if (!isMatch) break;
        }
        if (isMatch) {
            matchingRules.add(rule);
        }
    }
    return matchingRules;
}

6. 问题定位与解决

通过分析，我们发现问题出在iterateRuleSet方法的三层嵌套循环上，当订单项目和规则数量较多时，计算复杂度会急剧增加。

解决方案：

1. 1. 引入规则索引，避免全量遍历
2. 2. 使用缓存存储常用规则的匹配结果
3. 3. 优化算法，减少不必要的条件评估

修改后的代码：

复制代码

private List<Rule> iterateRuleSet(Order order) {
    // 使用Map预先按类别索引规则
    Map<String, List<Rule>> ruleIndex = getRuleIndexCache();
    
    // 获取订单可能适用的规则类别
    Set<String> applicableCategories = order.getItems().stream()
        .map(OrderItem::getCategory)
        .collect(Collectors.toSet());
    
    // 只评估可能匹配的规则
    List<Rule> matchingRules = new ArrayList<>();
    for (String category : applicableCategories) {
        List<Rule> categoryRules = ruleIndex.getOrDefault(category, Collections.emptyList());
        for (Rule rule : categoryRules) {
            if (ruleMatchesOrder(rule, order)) {
                matchingRules.add(rule);
            }
        }
    }
    return matchingRules;
}

// 使用缓存存储规则索引
private Map<String, List<Rule>> getRuleIndexCache() {
    return ruleIndexCache.computeIfAbsent("ruleIndex", k -> {
        Map<String, List<Rule>> index = new HashMap<>();
        for (Rule rule : allRules) {
            String category = rule.getCategory();
            index.computeIfAbsent(category, c -> new ArrayList<>()).add(rule);
        }
        return index;
    });
}

优化后，CPU使用率从90%下降到了正常的30%左右，系统响应恢复正常。

六、高级技巧与最佳实践

1. 结合多种命令使用

在实际排查过程中，通常需要结合多种Arthas命令来全面分析问题：

• • 使用dashboard和thread命令识别热点线程
• • 使用trace和stack分析方法调用链和耗时
• • 使用profiler生成火焰图直观展示热点
• • 使用watch和tt分析方法入参和返回值
• • 使用jad反编译代码查看具体实现

2. 设置合理的条件表达式

Arthas的大多数命令都支持条件表达式，可以帮助我们更精确地定位问题：

复制代码

# 只跟踪执行时间超过10ms的方法调用
$ trace com.example.Service methodName '#cost > 10'

# 只监控特定参数值的方法调用
$ watch com.example.Service methodName 'params[0].equals("SPECIAL_VALUE")'

3. 注意性能影响

虽然Arthas设计为低开销工具，但某些命令（如频繁使用的trace或深度较大的stack）仍可能对系统性能产生影响。在生产环境使用时应注意：

• • 尽量限制命令的执行次数（使用-n选项）
• • 减少跟踪的调用栈深度（使用--depth选项）
• • 使用更精确的条件表达式减少不必要的数据收集
• • 完成诊断后及时退出Arthas（使用quit或exit命令）

4. 使用异步分析

对于长期运行的应用，可以使用Arthas的异步分析功能：

复制代码

# 后台启动CPU分析
$ profiler start -d 300

# 300秒后自动停止并生成报告

这种方式可以在较长时间内收集性能数据，更容易捕获间歇性问题。

七、结论

Arthas作为一款强大的Java应用诊断工具，为我们提供了一种无侵入式的方法来实时排查生产环境中的性能问题。通过本文介绍的方法和实际案例，我们可以看到Arthas在CPU性能瓶颈排查中的强大能力。

掌握Arthas不仅能帮助我们快速定位和解决生产环境中的性能问题，还能提升我们对Java应用运行机制的理解。在实际工作中，建议将Arthas作为标准工具纳入问题排查流程，与传统的日志分析、JVM监控等方法结合使用，构建完整的性能问题排查体系。