2026/9/2 6:55:34
FEATURED · 精选文章 
最近在排查线上服务性能问题时又遇到了一个典型的“磕脚CPU”场景——某个核心服务进程的CPU使用率间歇性飙高到90%以上导致接口响应变慢告警频发。这种问题就像鞋里进了石子虽然不致命但持续影响系统稳定性和用户体验。敢于接手并彻底解决这类问题确实需要一些“胆子肥”的耐心和系统性方法。本文将基于一次完整的实战排查梳理一套从监控告警到根因定位再到优化验证的闭环解决方案涵盖Linux性能工具链的使用、Java应用 profiling 技巧以及常见的性能陷阱无论是运维同学还是后端开发者都能从中获得可直接复用的排查思路和命令集。1. 性能问题背景与核心概念当我们在监控系统如Zabbix、Prometheus或云平台控制台上看到某个服务的CPU使用率长时间居高不下或出现规律的尖峰时就遇到了所谓的“CPU飙高”或“磕脚CPU”问题。它指的是CPU资源被非预期地、过度地占用导致系统整体吞吐量下降其他进程响应延迟。CPU使用率的本质在Linux系统中我们通常所说的CPU使用率指的是在单位时间内CPU用于执行非空闲任务即用户态和内核态的时间占比。一个健康的系统CPU使用率应该是有波动的与请求量成正相关并且留有一定的空闲余量Idle以应对突发流量。“磕脚CPU”的典型特征持续性高负载CPU使用率持续高于80%甚至跑满而非短暂的峰值。伴随性能劣化接口平均响应时间RT增长吞吐量QPS/TPS下降。特定进程导致往往是某一个或某几个特定的进程如Java应用导致的而非系统整体繁忙。为什么必须解决资源浪费高昂的云服务器成本未能产生应有的业务价值。稳定性风险容易触发系统的负载保护机制如熔断或导致同一宿主机上的其他服务受影响。用户体验差直接导致前端页面加载慢、操作卡顿。排查成本高此类问题通常隐藏较深需要综合性的技术能力进行定位。2. 环境准备与排查工具箱在开始排查之前需要确保你具备相应的环境访问权限并准备好一系列命令行工具。本次排查基于一个典型的Linux服务器和Java应用环境。操作系统与环境操作系统CentOS 7.9 或 Ubuntu 20.04 LTS权限要求需要具有目标服务器的root或具有sudo权限的账号。目标应用一个基于 Spring Boot 2.7.x 的 Java Web 应用运行在 JDK 11 上。必备性能分析工具链 以下工具通常系统已预装或可轻松安装它们是排查CPU问题的“瑞士军刀”。系统全局监控top/htop: 实时查看系统整体负载和进程资源占用。vmstat/mpstat: 查看CPU、内存、IO等系统维度的统计信息。dstat: 功能更强的综合监控工具。进程级深度分析ps: 查看进程快照。pidstat: 监控特定进程的CPU、内存、IO等详细指标。Java应用专项工具jps: 列出当前系统中的Java进程。jstack: 获取Java进程的线程堆栈快照用于分析线程状态。jstat: 监控JVM内存、GC等统计信息。jmapMAT: 用于堆内存Dump和分析如果怀疑是内存问题间接引起CPU高。Arthas: 阿里巴巴开源的Java诊断利器支持动态跟踪方法调用、监控性能等。性能剖析Profiling工具perf(Linux): 系统级性能剖析工具可以定位到热点函数。async-profiler: 对Java应用非常友好的低开销采样分析器可以生成火焰图。检查工具是否就位# 检查系统命令 which top vmstat mpstat pidstat ps # 检查Java命令需配置JAVA_HOME which jps jstack jstat # 安装async-profiler示例 wget https://github.com/jvm-profiling-tools/async-profiler/releases/download/v2.9/async-profiler-2.9-linux-x64.tar.gz tar -xzf async-profiler-2.9-linux-x64.tar.gz -C /opt/3. 系统性排查流程与原理拆解盲目地使用工具只会事倍功半。一个高效的排查流程应该像侦探破案一样从宏观到微观层层递进。3.1 第一步确认问题现象与范围首先需要精确地描述问题。通过监控系统或基础命令回答以下几个问题哪个哪些进程CPU高使用top命令按P大写根据CPU使用率排序。CPU高的模式是什么是持续性的还是周期性的周期是多长影响范围有多大是单个实例还是整个集群是否伴随其他指标异常如内存、GC、磁盘IO、网络操作示例# 1. 使用top命令观察进程列表 top -c # 在top界面可以看到 COMMAND 列找到CPU占用最高的Java进程记下其PID第一列。 # 2. 使用更直观的htop如果已安装 htop # 3. 使用pidstat细粒度观察某个进程 # 每2秒采样一次共采样5次监控PID为12345的进程 pidstat -p 12345 2 5关键指标解读%usr: 进程在用户态运行的时间百分比。%system: 进程在内核态运行的时间百分比。%CPU: 进程总的CPU使用率%usr %system。%wait: 进程等待IO的时间百分比。如果这个值很高可能是磁盘或网络IO瓶颈而不是CPU计算瓶颈。3.2 第二步定位CPU高的具体线程一个Java进程内部有多个线程。CPU高一定是某个或某几个线程在疯狂执行。我们需要找到这些“罪魁祸首”。使用top查看线程# 1. 找到目标Java进程的PID假设为 12345 # 2. 查看该进程下的线程CPU占用情况 top -H -p 12345同样按P排序。你会看到一系列线程其PID是线程IDTID十进制。记录下CPU占用最高的几个线程的TID。将十进制的TID转换为十六进制jstack输出的线程栈中的nid是线程ID的十六进制表示。# 假设最高的TID是 12346 printf %x\n 12346 # 输出303a记下这个十六进制值0x303a。3.3 第三步获取线程堆栈并分析获取进程的线程堆栈快照并在其中搜索上一步得到的十六进制线程ID。使用jstack获取堆栈# 获取一次堆栈快照输出到文件 jstack -l 12345 /tmp/jstack_12345_$(date %s).log # 或者为了更精准地抓到高CPU瞬间的状态可以连续抓取几次 for i in {1..5}; do jstack -l 12345 /tmp/jstack_12345_$i.log; sleep 2; done分析堆栈文件 用vim,cat或grep命令在堆栈文件中搜索nid0x303a。grep -A 20 -B 5 nid0x303a /tmp/jstack_12345_1.log-A 20和-B 5表示打印匹配行及之后20行、之前5行的内容这通常足以看到完整的线程栈。分析堆栈信息 查看该线程正在执行的方法。常见的CPU高场景的线程栈特征计算密集型任务栈顶是业务逻辑方法可能处于复杂的循环、递归或算法计算中。死循环栈顶方法固定且栈深度较浅反复出现在多次抓取的堆栈中。频繁的GC如果看到GC task thread#0 (ParallelGC)等GC线程占用高则是内存问题。锁竞争线程状态为BLOCKED或WAITING且在等待锁如waiting on 0x0000000712345678。虽然此时线程不消耗CPU但大量线程阻塞可能迫使少数线程拼命工作从整体上看CPU利用率不均。3.4 第四步使用高级工具进行性能剖析如果通过线程堆栈无法直观看出问题例如栈顶是java.lang.Thread.run或sun.misc.Unsafe.park这种通用方法或者想量化各个方法的CPU耗时占比就需要使用性能剖析工具生成火焰图。使用 async-profiler 生成CPU火焰图# 进入async-profiler安装目录 cd /opt/async-profiler-2.9-linux-x64 # 对PID为12345的Java进程进行30秒的CPU采样分析结果生成火焰图HTML ./profiler.sh -d 30 -f /tmp/flamegraph_12345.html 12345火焰图解读X轴表示采样到的调用栈数量总和即CPU时间。条块越宽表示该方法占用的CPU时间越多。Y轴表示调用栈深度。最底层是入口越往上越具体。如何看从最宽的条块开始向上看找到最顶层的、属于你自己业务代码的方法。那就是热点中的热点。火焰图能非常直观地将CPU时间的花费可视化让你一眼找到“最烫”的方法。4. 完整实战案例排查一个循环计算导致的CPU飙高假设我们有一个Spring Boot服务提供了一个简单的素数计算接口。4.1 问题复现与监控我们编写一个存在性能问题的接口。// 文件路径src/main/java/com/example/demo/controller/PrimeController.java package com.example.demo.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class PrimeController { /** * 判断一个数是否为素数 (存在性能问题的版本) * param number 要判断的数字 * return 是否为素数 */ GetMapping(/isPrime) public String isPrime(RequestParam(number) long number) { long start System.currentTimeMillis(); boolean result isPrimeBad(number); long cost System.currentTimeMillis() - start; return String.format(Number %d is prime? %s. Cost: %d ms, number, result, cost); } // 低效的素数判断算法 O(n) private boolean isPrimeBad(long n) { if (n 1) return false; // 问题点这里使用了低效的遍历判断 for (long i 2; i n; i) { // 应该优化为 i * i n if (n % i 0) { return false; } } return true; } }启动应用后使用压测工具如ab,wrk,jmeter或简单循环请求来模拟高并发访问这个接口传入一个较大的数如1000000007。# 简单使用curl循环调用 for i in {1..100}; do curl http://localhost:8080/isPrime?number1000000007 done很快通过top命令就能观察到该Java进程的CPU使用率接近100%。4.2 定位热点线程与方法步骤1使用top找到进程和线程top -c # 找到我们的Java进程假设PID是 8888 top -H -p 8888 # 观察到某个线程假设TID8899CPU持续在50%以上。 # 转换TID为十六进制 printf %x\n 8899 得到 22c3步骤2使用jstack分析线程jstack -l 8888 /tmp/jstack_8888.log grep -n -A 30 -B 5 nid0x22c3 /tmp/jstack_8888.log在输出中你可能会看到类似以下的堆栈http-nio-8080-exec-1 #32 daemon prio5 os_prio0 tid0x00007f8b3820b800 nid0x22c3 runnable [0x00007f8b1f7f9000] java.lang.Thread.State: RUNNABLE at com.example.demo.controller.PrimeController.isPrimeBad(PrimeController.java:27) at com.example.demo.controller.PrimeController.isPrime(PrimeController.java:18) at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205) ... (Spring MVC调用链)清晰可见线程正在PrimeController.isPrimeBad的第27行即for循环内疯狂执行。这就是CPU热点。4.3 使用 async-profiler 生成火焰图验证cd /opt/async-profiler ./profiler.sh -d 20 -f /tmp/flamegraph_prime.html 8888将生成的HTML文件下载到本地浏览器打开可以看到isPrimeBad方法占据了最宽的条块确认了我们的判断。4.4 修复与优化定位到问题后修复就相对简单了。优化素数判断算法。// 文件路径src/main/java/com/example/demo/controller/PrimeController.java (优化后) /** * 判断一个数是否为素数 (优化版本) O(sqrt(n)) */ private boolean isPrimeOptimized(long n) { if (n 1) return false; if (n 3) return true; if (n % 2 0 || n % 3 0) return false; // 只需检查到 sqrt(n) 即可且步进为6 for (long i 5; i * i n; i 6) { if (n % i 0 || n % (i 2) 0) { return false; } } return true; } GetMapping(/isPrimeGood) public String isPrimeGood(RequestParam(number) long number) { long start System.currentTimeMillis(); boolean result isPrimeOptimized(number); long cost System.currentTimeMillis() - start; return String.format(Number %d is prime? %s. Cost: %d ms (Optimized), number, result, cost); }重新压测优化后的接口CPU使用率会显著下降接口耗时也从秒级降到毫秒甚至微秒级。5. 常见问题与排查思路清单在实际排查中CPU高的原因远不止低效算法一种。下面是一个常见问题排查清单。问题现象可能原因排查思路与工具单个Java线程CPU持续100%1. 存在死循环或无限递归。2. 执行非常耗时的计算如大文件加解密、复杂算法。1.top -H找线程。2.jstack查线程栈看栈顶业务方法。3.async-profiler生成火焰图定位热点方法。多个线程CPU都较高总和超过100%1. 线程池配置过大大量线程并发执行。2. 存在“惊群效应”或锁竞争导致大量线程在用户态空转。1.jstack查看线程池状态和线程数。2. 检查线程池配置ThreadPoolExecutor。3. 分析堆栈中是否有大量BLOCKED或WAITING线程用jstack查看锁持有者。GC线程CPU高 (Gang worker#0)1. 频繁Full GC。2. 堆内存不足或存在内存泄漏。1.jstat -gcutil PID 1000 10观察GC频率和耗时。2.jmap -histo:live PID查看对象直方图。3. 使用jmap或MAT分析堆内存快照。系统CPU (%sys) 占用高1. 系统调用频繁如大量线程上下文切换、锁竞争激烈。2. 文件IO或网络IO非常频繁。1.vmstat 1查看cs(上下文切换) 和in(中断) 指标。2.pidstat -w -p PID 1查看进程的上下文切换情况。3. 使用perf分析内核态热点。CPU使用率周期性尖峰1. 定时任务触发。2. 缓存定期失效重建。3. 监控/日志采集任务。1. 核对业务系统的定时任务配置Scheduled, Quartz。2. 检查中间件如Redis的监控和日志。3. 在尖峰时刻立即抓取jstack和火焰图。CPU使用率随流量上涨1. 接口本身逻辑复杂QPS增长导致CPU线性增长。2. 存在循环依赖或N1查询等放大效应。1. 使用压测工具模拟不同QPS观察CPU曲线。2. 结合APM工具如SkyWalking, Pinpoint分析调用链找到最耗时的链路。6. 最佳实践与工程建议解决一次CPU问题后更重要的是建立预防和快速响应的机制。1. 编码阶段预防算法与数据结构对核心逻辑进行复杂度分析避免在循环中嵌套复杂操作或低效算法。合理使用缓存对计算结果稳定、访问频繁的数据进行缓存避免重复计算。避免过度同步缩小同步代码块的范围优先使用并发工具类如ConcurrentHashMap而非synchronized。谨慎使用递归明确递归终止条件对于深度可能较大的递归考虑改为迭代。2. 配置与部署优化线程池调优根据业务类型CPU密集型、IO密集型合理设置核心线程数、最大线程数和队列容量。避免无界队列导致内存溢出或线程过多导致上下文切换开销激增。JVM参数调优根据应用特点选择合适的GC算法如G1设置合理的堆大小-Xms,-Xmx和新生代/老年代比例减少GC频率和停顿时间。限流与降级在网关或应用层对非核心、耗资源的接口进行限流防止异常流量打满CPU。3. 监控与告警体系建设分层监控基础层监控服务器的CPU、内存、磁盘IO、网络IO。中间件层监控数据库连接池、Redis、MQ等。应用层监控JVMGC次数、时间、堆内存使用率、接口QPS/RT/错误率。业务层监控核心业务指标。告警智能化不要只对CPU使用率绝对值告警。建议结合同比/环比异常当前CPU使用率比昨天同一时间或上周同一时间上涨超过50%。持续时间CPU持续高于阈值如80%超过5分钟。关联告警CPU高的同时接口RT也上涨错误率升高则触发更高级别的告警。4. 排查流程标准化建立团队内部的《性能问题排查手册》将上述工具命令和流程固化下来。在测试环境和预发环境定期进行压力测试提前发现性能瓶颈。推广使用性能剖析工具如Arthas, async-profiler并将其集成到CI/CD流程或线上诊断平台中。5. 复盘与知识沉淀每次解决线上性能问题后进行简要复盘。将问题根因、排查步骤、解决方案记录到内部Wiki。思考是否有共性模式能否通过代码规范、架构优化或工具建设来避免同类问题再次发生。敢于接手并解决“磕脚CPU”这类棘手问题是工程师成长的重要阶梯。它考验的不仅是技术工具的熟练度更是系统性思维和逻辑推理能力。从宏观监控到微观代码从现象到根因每一步都需要耐心和细致。希望本文提供的这套从工具使用到实战案例再到方法论总结的完整指南能成为你工具箱中的利器当下次监控告警再次响起时你能从容地说“这个CPU问题我来搞定。”
Java应用CPU飙高排查实战：从工具使用到根因定位的完整指南
最近在排查线上服务性能问题时又遇到了一个典型的“磕脚CPU”场景——某个核心服务进程的CPU使用率间歇性飙高到90%以上导致接口响应变慢告警频发。这种问题就像鞋里进了石子虽然不致命但持续影响系统稳定性和用户体验。敢于接手并彻底解决这类问题确实需要一些“胆子肥”的耐心和系统性方法。本文将基于一次完整的实战排查梳理一套从监控告警到根因定位再到优化验证的闭环解决方案涵盖Linux性能工具链的使用、Java应用 profiling 技巧以及常见的性能陷阱无论是运维同学还是后端开发者都能从中获得可直接复用的排查思路和命令集。1. 性能问题背景与核心概念当我们在监控系统如Zabbix、Prometheus或云平台控制台上看到某个服务的CPU使用率长时间居高不下或出现规律的尖峰时就遇到了所谓的“CPU飙高”或“磕脚CPU”问题。它指的是CPU资源被非预期地、过度地占用导致系统整体吞吐量下降其他进程响应延迟。CPU使用率的本质在Linux系统中我们通常所说的CPU使用率指的是在单位时间内CPU用于执行非空闲任务即用户态和内核态的时间占比。一个健康的系统CPU使用率应该是有波动的与请求量成正相关并且留有一定的空闲余量Idle以应对突发流量。“磕脚CPU”的典型特征持续性高负载CPU使用率持续高于80%甚至跑满而非短暂的峰值。伴随性能劣化接口平均响应时间RT增长吞吐量QPS/TPS下降。特定进程导致往往是某一个或某几个特定的进程如Java应用导致的而非系统整体繁忙。为什么必须解决资源浪费高昂的云服务器成本未能产生应有的业务价值。稳定性风险容易触发系统的负载保护机制如熔断或导致同一宿主机上的其他服务受影响。用户体验差直接导致前端页面加载慢、操作卡顿。排查成本高此类问题通常隐藏较深需要综合性的技术能力进行定位。2. 环境准备与排查工具箱在开始排查之前需要确保你具备相应的环境访问权限并准备好一系列命令行工具。本次排查基于一个典型的Linux服务器和Java应用环境。操作系统与环境操作系统CentOS 7.9 或 Ubuntu 20.04 LTS权限要求需要具有目标服务器的root或具有sudo权限的账号。目标应用一个基于 Spring Boot 2.7.x 的 Java Web 应用运行在 JDK 11 上。必备性能分析工具链 以下工具通常系统已预装或可轻松安装它们是排查CPU问题的“瑞士军刀”。系统全局监控top/htop: 实时查看系统整体负载和进程资源占用。vmstat/mpstat: 查看CPU、内存、IO等系统维度的统计信息。dstat: 功能更强的综合监控工具。进程级深度分析ps: 查看进程快照。pidstat: 监控特定进程的CPU、内存、IO等详细指标。Java应用专项工具jps: 列出当前系统中的Java进程。jstack: 获取Java进程的线程堆栈快照用于分析线程状态。jstat: 监控JVM内存、GC等统计信息。jmapMAT: 用于堆内存Dump和分析如果怀疑是内存问题间接引起CPU高。Arthas: 阿里巴巴开源的Java诊断利器支持动态跟踪方法调用、监控性能等。性能剖析Profiling工具perf(Linux): 系统级性能剖析工具可以定位到热点函数。async-profiler: 对Java应用非常友好的低开销采样分析器可以生成火焰图。检查工具是否就位# 检查系统命令 which top vmstat mpstat pidstat ps # 检查Java命令需配置JAVA_HOME which jps jstack jstat # 安装async-profiler示例 wget https://github.com/jvm-profiling-tools/async-profiler/releases/download/v2.9/async-profiler-2.9-linux-x64.tar.gz tar -xzf async-profiler-2.9-linux-x64.tar.gz -C /opt/3. 系统性排查流程与原理拆解盲目地使用工具只会事倍功半。一个高效的排查流程应该像侦探破案一样从宏观到微观层层递进。3.1 第一步确认问题现象与范围首先需要精确地描述问题。通过监控系统或基础命令回答以下几个问题哪个哪些进程CPU高使用top命令按P大写根据CPU使用率排序。CPU高的模式是什么是持续性的还是周期性的周期是多长影响范围有多大是单个实例还是整个集群是否伴随其他指标异常如内存、GC、磁盘IO、网络操作示例# 1. 使用top命令观察进程列表 top -c # 在top界面可以看到 COMMAND 列找到CPU占用最高的Java进程记下其PID第一列。 # 2. 使用更直观的htop如果已安装 htop # 3. 使用pidstat细粒度观察某个进程 # 每2秒采样一次共采样5次监控PID为12345的进程 pidstat -p 12345 2 5关键指标解读%usr: 进程在用户态运行的时间百分比。%system: 进程在内核态运行的时间百分比。%CPU: 进程总的CPU使用率%usr %system。%wait: 进程等待IO的时间百分比。如果这个值很高可能是磁盘或网络IO瓶颈而不是CPU计算瓶颈。3.2 第二步定位CPU高的具体线程一个Java进程内部有多个线程。CPU高一定是某个或某几个线程在疯狂执行。我们需要找到这些“罪魁祸首”。使用top查看线程# 1. 找到目标Java进程的PID假设为 12345 # 2. 查看该进程下的线程CPU占用情况 top -H -p 12345同样按P排序。你会看到一系列线程其PID是线程IDTID十进制。记录下CPU占用最高的几个线程的TID。将十进制的TID转换为十六进制jstack输出的线程栈中的nid是线程ID的十六进制表示。# 假设最高的TID是 12346 printf %x\n 12346 # 输出303a记下这个十六进制值0x303a。3.3 第三步获取线程堆栈并分析获取进程的线程堆栈快照并在其中搜索上一步得到的十六进制线程ID。使用jstack获取堆栈# 获取一次堆栈快照输出到文件 jstack -l 12345 /tmp/jstack_12345_$(date %s).log # 或者为了更精准地抓到高CPU瞬间的状态可以连续抓取几次 for i in {1..5}; do jstack -l 12345 /tmp/jstack_12345_$i.log; sleep 2; done分析堆栈文件 用vim,cat或grep命令在堆栈文件中搜索nid0x303a。grep -A 20 -B 5 nid0x303a /tmp/jstack_12345_1.log-A 20和-B 5表示打印匹配行及之后20行、之前5行的内容这通常足以看到完整的线程栈。分析堆栈信息 查看该线程正在执行的方法。常见的CPU高场景的线程栈特征计算密集型任务栈顶是业务逻辑方法可能处于复杂的循环、递归或算法计算中。死循环栈顶方法固定且栈深度较浅反复出现在多次抓取的堆栈中。频繁的GC如果看到GC task thread#0 (ParallelGC)等GC线程占用高则是内存问题。锁竞争线程状态为BLOCKED或WAITING且在等待锁如waiting on 0x0000000712345678。虽然此时线程不消耗CPU但大量线程阻塞可能迫使少数线程拼命工作从整体上看CPU利用率不均。3.4 第四步使用高级工具进行性能剖析如果通过线程堆栈无法直观看出问题例如栈顶是java.lang.Thread.run或sun.misc.Unsafe.park这种通用方法或者想量化各个方法的CPU耗时占比就需要使用性能剖析工具生成火焰图。使用 async-profiler 生成CPU火焰图# 进入async-profiler安装目录 cd /opt/async-profiler-2.9-linux-x64 # 对PID为12345的Java进程进行30秒的CPU采样分析结果生成火焰图HTML ./profiler.sh -d 30 -f /tmp/flamegraph_12345.html 12345火焰图解读X轴表示采样到的调用栈数量总和即CPU时间。条块越宽表示该方法占用的CPU时间越多。Y轴表示调用栈深度。最底层是入口越往上越具体。如何看从最宽的条块开始向上看找到最顶层的、属于你自己业务代码的方法。那就是热点中的热点。火焰图能非常直观地将CPU时间的花费可视化让你一眼找到“最烫”的方法。4. 完整实战案例排查一个循环计算导致的CPU飙高假设我们有一个Spring Boot服务提供了一个简单的素数计算接口。4.1 问题复现与监控我们编写一个存在性能问题的接口。// 文件路径src/main/java/com/example/demo/controller/PrimeController.java package com.example.demo.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class PrimeController { /** * 判断一个数是否为素数 (存在性能问题的版本) * param number 要判断的数字 * return 是否为素数 */ GetMapping(/isPrime) public String isPrime(RequestParam(number) long number) { long start System.currentTimeMillis(); boolean result isPrimeBad(number); long cost System.currentTimeMillis() - start; return String.format(Number %d is prime? %s. Cost: %d ms, number, result, cost); } // 低效的素数判断算法 O(n) private boolean isPrimeBad(long n) { if (n 1) return false; // 问题点这里使用了低效的遍历判断 for (long i 2; i n; i) { // 应该优化为 i * i n if (n % i 0) { return false; } } return true; } }启动应用后使用压测工具如ab,wrk,jmeter或简单循环请求来模拟高并发访问这个接口传入一个较大的数如1000000007。# 简单使用curl循环调用 for i in {1..100}; do curl http://localhost:8080/isPrime?number1000000007 done很快通过top命令就能观察到该Java进程的CPU使用率接近100%。4.2 定位热点线程与方法步骤1使用top找到进程和线程top -c # 找到我们的Java进程假设PID是 8888 top -H -p 8888 # 观察到某个线程假设TID8899CPU持续在50%以上。 # 转换TID为十六进制 printf %x\n 8899 得到 22c3步骤2使用jstack分析线程jstack -l 8888 /tmp/jstack_8888.log grep -n -A 30 -B 5 nid0x22c3 /tmp/jstack_8888.log在输出中你可能会看到类似以下的堆栈http-nio-8080-exec-1 #32 daemon prio5 os_prio0 tid0x00007f8b3820b800 nid0x22c3 runnable [0x00007f8b1f7f9000] java.lang.Thread.State: RUNNABLE at com.example.demo.controller.PrimeController.isPrimeBad(PrimeController.java:27) at com.example.demo.controller.PrimeController.isPrime(PrimeController.java:18) at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205) ... (Spring MVC调用链)清晰可见线程正在PrimeController.isPrimeBad的第27行即for循环内疯狂执行。这就是CPU热点。4.3 使用 async-profiler 生成火焰图验证cd /opt/async-profiler ./profiler.sh -d 20 -f /tmp/flamegraph_prime.html 8888将生成的HTML文件下载到本地浏览器打开可以看到isPrimeBad方法占据了最宽的条块确认了我们的判断。4.4 修复与优化定位到问题后修复就相对简单了。优化素数判断算法。// 文件路径src/main/java/com/example/demo/controller/PrimeController.java (优化后) /** * 判断一个数是否为素数 (优化版本) O(sqrt(n)) */ private boolean isPrimeOptimized(long n) { if (n 1) return false; if (n 3) return true; if (n % 2 0 || n % 3 0) return false; // 只需检查到 sqrt(n) 即可且步进为6 for (long i 5; i * i n; i 6) { if (n % i 0 || n % (i 2) 0) { return false; } } return true; } GetMapping(/isPrimeGood) public String isPrimeGood(RequestParam(number) long number) { long start System.currentTimeMillis(); boolean result isPrimeOptimized(number); long cost System.currentTimeMillis() - start; return String.format(Number %d is prime? %s. Cost: %d ms (Optimized), number, result, cost); }重新压测优化后的接口CPU使用率会显著下降接口耗时也从秒级降到毫秒甚至微秒级。5. 常见问题与排查思路清单在实际排查中CPU高的原因远不止低效算法一种。下面是一个常见问题排查清单。问题现象可能原因排查思路与工具单个Java线程CPU持续100%1. 存在死循环或无限递归。2. 执行非常耗时的计算如大文件加解密、复杂算法。1.top -H找线程。2.jstack查线程栈看栈顶业务方法。3.async-profiler生成火焰图定位热点方法。多个线程CPU都较高总和超过100%1. 线程池配置过大大量线程并发执行。2. 存在“惊群效应”或锁竞争导致大量线程在用户态空转。1.jstack查看线程池状态和线程数。2. 检查线程池配置ThreadPoolExecutor。3. 分析堆栈中是否有大量BLOCKED或WAITING线程用jstack查看锁持有者。GC线程CPU高 (Gang worker#0)1. 频繁Full GC。2. 堆内存不足或存在内存泄漏。1.jstat -gcutil PID 1000 10观察GC频率和耗时。2.jmap -histo:live PID查看对象直方图。3. 使用jmap或MAT分析堆内存快照。系统CPU (%sys) 占用高1. 系统调用频繁如大量线程上下文切换、锁竞争激烈。2. 文件IO或网络IO非常频繁。1.vmstat 1查看cs(上下文切换) 和in(中断) 指标。2.pidstat -w -p PID 1查看进程的上下文切换情况。3. 使用perf分析内核态热点。CPU使用率周期性尖峰1. 定时任务触发。2. 缓存定期失效重建。3. 监控/日志采集任务。1. 核对业务系统的定时任务配置Scheduled, Quartz。2. 检查中间件如Redis的监控和日志。3. 在尖峰时刻立即抓取jstack和火焰图。CPU使用率随流量上涨1. 接口本身逻辑复杂QPS增长导致CPU线性增长。2. 存在循环依赖或N1查询等放大效应。1. 使用压测工具模拟不同QPS观察CPU曲线。2. 结合APM工具如SkyWalking, Pinpoint分析调用链找到最耗时的链路。6. 最佳实践与工程建议解决一次CPU问题后更重要的是建立预防和快速响应的机制。1. 编码阶段预防算法与数据结构对核心逻辑进行复杂度分析避免在循环中嵌套复杂操作或低效算法。合理使用缓存对计算结果稳定、访问频繁的数据进行缓存避免重复计算。避免过度同步缩小同步代码块的范围优先使用并发工具类如ConcurrentHashMap而非synchronized。谨慎使用递归明确递归终止条件对于深度可能较大的递归考虑改为迭代。2. 配置与部署优化线程池调优根据业务类型CPU密集型、IO密集型合理设置核心线程数、最大线程数和队列容量。避免无界队列导致内存溢出或线程过多导致上下文切换开销激增。JVM参数调优根据应用特点选择合适的GC算法如G1设置合理的堆大小-Xms,-Xmx和新生代/老年代比例减少GC频率和停顿时间。限流与降级在网关或应用层对非核心、耗资源的接口进行限流防止异常流量打满CPU。3. 监控与告警体系建设分层监控基础层监控服务器的CPU、内存、磁盘IO、网络IO。中间件层监控数据库连接池、Redis、MQ等。应用层监控JVMGC次数、时间、堆内存使用率、接口QPS/RT/错误率。业务层监控核心业务指标。告警智能化不要只对CPU使用率绝对值告警。建议结合同比/环比异常当前CPU使用率比昨天同一时间或上周同一时间上涨超过50%。持续时间CPU持续高于阈值如80%超过5分钟。关联告警CPU高的同时接口RT也上涨错误率升高则触发更高级别的告警。4. 排查流程标准化建立团队内部的《性能问题排查手册》将上述工具命令和流程固化下来。在测试环境和预发环境定期进行压力测试提前发现性能瓶颈。推广使用性能剖析工具如Arthas, async-profiler并将其集成到CI/CD流程或线上诊断平台中。5. 复盘与知识沉淀每次解决线上性能问题后进行简要复盘。将问题根因、排查步骤、解决方案记录到内部Wiki。思考是否有共性模式能否通过代码规范、架构优化或工具建设来避免同类问题再次发生。敢于接手并解决“磕脚CPU”这类棘手问题是工程师成长的重要阶梯。它考验的不仅是技术工具的熟练度更是系统性思维和逻辑推理能力。从宏观监控到微观代码从现象到根因每一步都需要耐心和细致。希望本文提供的这套从工具使用到实战案例再到方法论总结的完整指南能成为你工具箱中的利器当下次监控告警再次响起时你能从容地说“这个CPU问题我来搞定。” 
