JAVA服务CPU 100% 根因定位与JFR性能火焰图分析
各位同学，大家好！今天我们来深入探讨一个在JAVA开发中经常遇到的问题：JAVA服务CPU突然飙升至100%。这个问题往往比较棘手，因为它可能由多种原因引起，定位起来比较困难。本次讲座将从根因定位的思路和方法入手，并结合JFR性能火焰图分析，帮助大家快速有效地找到并解决这类问题。
一、 理解CPU飙升的常见原因
在深入分析之前，我们首先要了解CPU飙升的常见原因，这能帮助我们缩小排查范围，提高效率。常见的CPU飙升原因包括：
-
死循环或无限递归: 这是最常见的原因之一，程序陷入无法退出的循环或递归调用，导致CPU资源被持续占用。
-
频繁的GC (垃圾回收): JAVA的垃圾回收机制会消耗CPU资源，如果GC过于频繁，例如因为内存泄漏导致堆空间快速增长，就会导致CPU利用率飙升。
-
大量的线程竞争: 多线程应用中，如果线程之间存在激烈的锁竞争，会导致线程频繁地阻塞和唤醒，消耗大量的CPU资源。
-
大量的I/O操作: 频繁的文件读写、网络请求等I/O操作也会占用CPU资源，尤其是在同步I/O模型下。
-
复杂的算法或计算: 执行复杂度高的算法或进行大规模的计算，例如图像处理、科学计算等，也会导致CPU利用率上升。
-
不合理的线程池配置: 线程池配置不当，例如线程数量过少或队列过长，会导致任务积压，线程频繁创建和销毁，也会造成CPU压力。
-
外部依赖服务故障: 依赖的外部服务（数据库、缓存等）响应缓慢或出现故障，会导致JAVA服务线程阻塞等待，增加CPU上下文切换的开销。
二、 定位问题的基本思路和步骤
面对CPU飙升问题，我们需要遵循一定的思路和步骤，才能快速定位到根源：
-
监控与告警: 首先，需要建立完善的监控体系，实时监控CPU利用率、内存使用情况、线程状态等关键指标。当CPU利用率超过预设阈值时，触发告警，及时通知相关人员。可以使用Prometheus + Grafana, Zabbix等工具实现监控告警。
-
确定问题发生的时间段: 根据监控数据，确定CPU飙升发生的时间段，这有助于我们缩小排查范围，例如查看这段时间内是否有新功能上线、配置变更等。
-
获取进程ID (PID): 通过
top命令或其他系统工具，找到占用CPU最高的JAVA进程的PID。top在
top命令的输出中，找到CPU使用率最高的java进程，记录其PID。 -
定位占用CPU最高的线程: 使用
jstack命令，打印JAVA进程的线程堆栈信息。jstack <PID> > thread_dump.txt其中
<PID>是JAVA进程的PID。打开thread_dump.txt文件，查找nid(native ID) 对应的线程，该nid是十六进制的线程ID。 将PID转换为十六进制。public class HexConverter { public static void main(String[] args) { int decimal = 12345; // 替换为你的PID String hex = Integer.toHexString(decimal); System.out.println("Decimal: " + decimal); System.out.println("Hex: " + hex); } }然后，在
thread_dump.txt中，搜索这个十六进制的nid，可以找到对应的线程堆栈信息。例如，找到的线程堆栈信息可能如下所示：
"pool-1-thread-1" #27 prio=5 os_prio=0 tid=0x00007f9d8c03a000 nid=0x73b5 runnable [0x00007f9d8b76d000] java.lang.Thread.State: RUNNABLE at com.example.cpu.HeavyCalculation.calculate(HeavyCalculation.java:10) at com.example.cpu.TaskExecutor.run(TaskExecutor.java:15) 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)从线程堆栈信息中，可以分析出线程正在执行的代码，从而定位到问题代码。
-
使用JFR (Java Flight Recorder) 进行性能分析: 如果
jstack的信息不够详细，或者问题比较复杂，可以使用JFR进行性能分析。JFR是JDK自带的性能分析工具，可以记录JAVA应用的运行时数据，例如CPU使用情况、内存分配、GC情况、锁竞争等。
三、 JFR的使用和火焰图分析
-
启动JFR录制: 可以使用
jcmd命令启动JFR录制。jcmd <PID> JFR.start duration=60s filename=myrecording.jfr其中
<PID>是JAVA进程的PID，duration是录制时长，filename是录制文件的名称。 -
分析JFR录制文件: 可以使用JDK Mission Control (JMC) 打开JFR录制文件，进行性能分析。JMC是一个图形化的JFR分析工具，可以直观地展示JAVA应用的运行时数据。
另一种方式是使用命令行工具
jfr print或者jfr analyze。jfr print myrecording.jfr > jfr_output.txt或者使用
jfr analyze myrecording.jfr(JDK 17+) -
生成火焰图: 火焰图是一种可视化CPU使用情况的工具，可以清晰地展示代码的调用关系和CPU消耗。可以使用JMC自带的火焰图功能，或者使用第三方工具生成火焰图。这里介绍使用perf工具+FlameGraph生成火焰图的方法：
-
首先，需要安装perf工具。在Linux系统上，可以使用以下命令安装：
sudo apt-get install linux-tools-common linux-tools-$(uname -r) -
然后，下载FlameGraph工具。
git clone https://github.com/brendangregg/FlameGraph.git -
使用perf工具收集CPU采样数据。
perf record -F 99 -p <PID> -g -- sleep 60 perf script > out.perf其中
<PID>是JAVA进程的PID，-F 99表示每秒采样99次，-g表示记录调用栈。 -
使用FlameGraph工具生成火焰图。
./FlameGraph/stackcollapse-perf.pl out.perf > out.folded ./FlameGraph/flamegraph.pl out.folded > flamegraph.svg打开
flamegraph.svg文件，即可看到生成的火焰图。
-
-
分析火焰图: 火焰图的横轴表示样本数，纵轴表示调用栈的深度。火焰越宽，表示该代码段消耗的CPU时间越多。从火焰图的顶部开始，找到最宽的火焰，就可以定位到CPU消耗最高的代码段。
- 看高度: 火焰的高度表示代码的调用深度，越高表示调用链越长。
- 看宽度: 火焰的宽度表示CPU的占用时间，越宽表示占用CPU的时间越长，通常需要关注最宽的火焰。
- 看颜色: 火焰的颜色没有特殊含义，只是为了区分不同的代码段。
- 点击火焰: 点击火焰可以放大显示该代码段的调用栈。
四、 常见问题的案例分析
下面，我们通过几个具体的案例，来演示如何使用JFR和火焰图定位CPU飙升问题。
案例1：死循环
假设我们的代码中存在一个死循环：
package com.example.cpu;
public class DeadLoop {
public static void main(String[] args) {
while (true) {
// 模拟一些计算
int i = 0;
i++;
}
}
}运行这段代码，CPU利用率会迅速飙升至100%。
-
定位方法: 使用
jstack命令，可以发现线程堆栈信息中，DeadLoop.main方法一直在执行。 -
JFR分析: 使用JFR录制一段时间的数据，然后生成火焰图。火焰图会清晰地显示
DeadLoop.main方法占据了大量的CPU时间。
案例2：频繁的GC
假设我们的代码中存在内存泄漏，导致GC频繁发生：
package com.example.cpu;
import java.util.ArrayList;
import java.util.List;
public class MemoryLeak {
private static List<Object> list = new ArrayList<>();
public static void main(String[] args) throws InterruptedException {
while (true) {
// 不断向list中添加对象，导致内存泄漏
list.add(new byte[1024 * 1024]); // 1MB
Thread.sleep(1);
}
}
}运行这段代码，CPU利用率会升高，并且GC会变得非常频繁。
-
定位方法: 使用JMC打开JFR录制文件，查看GC相关的事件，可以发现GC非常频繁，并且每次GC的时间都很长。
-
火焰图分析: 火焰图会显示
GC相关的代码占据了大量的CPU时间。同时，还可以看到分配内存的代码占据了较高的比例。
案例3：锁竞争
假设我们的代码中存在激烈的锁竞争：
package com.example.cpu;
public class LockContention {
private static final Object lock = new Object();
private static int counter = 0;
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(() -> {
while (true) {
synchronized (lock) {
counter++;
}
}
}).start();
}
}
}运行这段代码，CPU利用率会升高，并且线程会频繁地阻塞和唤醒。
-
定位方法: 使用JMC打开JFR录制文件，查看锁相关的事件，可以发现锁竞争非常激烈，并且线程频繁地阻塞和唤醒。
-
火焰图分析: 火焰图会显示
synchronized关键字相关的代码占据了大量的CPU时间。
五、 优化建议
定位到CPU飙升的原因后，我们需要采取相应的措施进行优化：
-
避免死循环和无限递归: 仔细检查代码，确保循环和递归调用能够正常退出。
-
解决内存泄漏问题: 使用内存分析工具，例如MAT (Memory Analyzer Tool)，找到内存泄漏的代码，并修复。
-
减少锁竞争: 使用更细粒度的锁，或者使用无锁数据结构，例如ConcurrentHashMap、AtomicInteger等。
-
优化I/O操作: 使用异步I/O，或者使用缓存，减少I/O操作的次数。
-
优化算法和计算: 选择更高效的算法，或者使用并行计算，减少计算的时间。
-
合理配置线程池: 根据实际情况，调整线程池的大小和队列长度。
-
优化外部依赖服务: 使用缓存、连接池等技术，减少对外部服务的依赖，或者优化外部服务的性能。
六、 代码示例：使用JFR API进行自定义事件监控
除了使用命令行工具和JMC，我们还可以使用JFR API在代码中自定义事件，监控特定的代码段。
import jdk.jfr.*;
@Name("com.example.MyEvent")
@Label("My Event")
@Description("A custom event for monitoring performance.")
class MyEvent extends Event {
@Label("Duration")
@Description("The duration of the operation in milliseconds.")
public long duration;
}
public class CustomEventExample {
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 10; i++) {
long startTime = System.currentTimeMillis();
// 模拟一些耗时操作
Thread.sleep(100);
long endTime = System.currentTimeMillis();
MyEvent event = new MyEvent();
event.duration = endTime - startTime;
event.begin();
event.commit();
}
}
}在这个例子中，我们定义了一个名为MyEvent的自定义事件，用于记录某段代码的执行时间。在代码中，我们创建了一个MyEvent对象，设置了duration属性，然后调用begin()和commit()方法，将事件记录到JFR录制文件中。
通过自定义事件，我们可以更精确地监控特定代码段的性能，从而更好地定位问题。
七、总结：持续监控与优化，保障服务稳定运行
通过以上的讲解，我们了解了CPU飙升的常见原因、定位问题的思路和步骤，以及JFR和火焰图的使用方法。希望大家在实际工作中，能够灵活运用这些知识，快速有效地解决CPU飙升问题，并持续监控和优化系统性能，保障服务的稳定运行。