作为一名有着8年运维经验的老司机，我经历过无数次深夜被电话叫醒的"惊喜"。今天分享一次典型的CPU 100%故障处理全过程，希望能帮你在关键时刻快速定位问题。
故障现象：用户体验急剧下降
时间线回顾：
关键指标异常：
# 系统负载异常高
load average: 8.5, 7.2, 6.8 # 正常应该在2以下
# CPU使用率
%Cpu(s): 98.2 us, 1.2 sy, 0.0 ni, 0.6 id
# 内存使用正常
KiB Mem : 16GB total, 2GB free
第一步：快速定位CPU消耗大户（30秒内）
使用top命令进行初步排查
# 按CPU使用率排序，实时刷新
top -o %CPU
# 输出示例
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12847 www 20 0 2.2g 1.8g 12m R 89.5 11.2 145:32 java
8934 mysql 20 0 1.6g 800m 32m S 8.2 5.1 23:45 mysqld
3421 nginx 20 0 128m 45m 8m S 1.2 0.3 2:34 nginx
关键发现：Java进程（PID 12847）占用89.5%的CPU！
深入分析Java进程内部线程
# 查看Java进程内部线程CPU使用情况
top -H -p 12847
# 输出关键信息
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12851 www 20 0 2.2g 1.8g 12m R 45.2 11.2 89:23 java
12856 www 20 0 2.2g 1.8g 12m R 44.3 11.2 78:45 java
12863 www 20 0 2.2g 1.8g 12m S 2.1 11.2 5:34 java
重要线索：两个线程（12851、12856）消耗了近90%的CPU资源！
第二步：精确定位问题代码（2分钟内）
获取Java线程堆栈信息
# 将线程ID转换为16进制（Java堆栈中使用16进制）
printf "0x%x\n" 12851 # 输出：0x3233
printf "0x%x\n" 12856 # 输出：0x3238
# 获取Java进程完整堆栈
jstack 12847 > /tmp/java_stack.txt
# 在堆栈中查找对应线程
grep -A 20 "0x3233" /tmp/java_stack.txt
堆栈分析结果
"pool-2-thread-1"
#23
prio=5 os_prio=0 tid=0x... nid=0x3233 runnable
java.lang.Thread.State: RUNNABLE
at com.company.service.OrderService.calculateDiscount(OrderService.java:245)
at com.company.service.OrderService.processOrder(OrderService.java:189)
at com.company.controller.OrderController.submitOrder(OrderController.java:67)
- locked <0x000000076ab62208> (a java.lang.Object)
"pool-2-thread-2" #24 prio=5 os_prio=0 tid=0x... nid=0x3238 runnable
java.lang.Thread.State: RUNNABLE
at com.company.service.OrderService.calculateDiscount(OrderService.java:245)
- waiting to lock <0x000000076ab62208> (a java.lang.Object)
关键发现：
第三步：代码层面问题分析
查看问题代码
// OrderService.java 第245行附近
publicsynchronized BigDecimal calculateDiscount(Order order) {
// 问题代码：在同步方法中执行了耗时的外部API调用
try {
// 调用第三方优惠券验证API - 耗时3-5秒
CouponValidationResultresult= thirdPartyApi.validateCoupon(order.getCouponCode());
// 复杂的折扣计算逻辑
for(inti=0; i < 1000000; i++) { // 模拟复杂计算
// 大量计算操作
}
return calculateFinalDiscount(result, order);
} catch (Exception e) {
log.error("折扣计算失败", e);
return BigDecimal.ZERO;
}
}
问题根因分析：
第四步：紧急处理方案（1分钟内执行）
临时解决方案：限流 + 缓存
# 1. 紧急重启应用（如果可接受短暂中断）
systemctl restart your-app
# 2. 开启Nginx限流（降低并发压力）
# /etc/nginx/conf.d/rate-limit.conf
limit_req_zone $binary_remote_addr zone=order:10m rate=10r/s;
location /api/order {
limit_req zone=order burst=20 nodelay;
proxy_pass http://backend;
}
# 重载Nginx配置
nginx -s reload
# 3. 临时禁用优惠券功能（业务降级）
# 在配置中心快速切换feature flag
curl -X PUT http://config-center/api/features/coupon-validation \
-d '{"enabled": false}'
第五步：根本性修复方案
代码重构：异步化 + 细粒度锁
@Service
publicclassOrderService {
privatefinal RedisTemplate<String, Object> redisTemplate;
privatefinal CouponValidationService couponService;
// 移除synchronized，改为细粒度锁控制
public CompletableFuture<BigDecimal> calculateDiscountAsync(Order order) {
return CompletableFuture.supplyAsync(() -> {
StringlockKey="discount_calc_" + order.getUserId();
// 使用Redis分布式锁，避免单机锁竞争
return redisTemplate.execute(newRedisCallback<BigDecimal>() {
@Override
public BigDecimal doInRedis(RedisConnection connection) {
try {
// 尝试获取锁，超时时间1秒
BooleanlockAcquired= connection.setNX(
lockKey.getBytes(), "1".getBytes()
);
connection.expire(lockKey.getBytes(), 5); // 5秒过期
if (lockAcquired) {
return doCalculateDiscount(order);
} else {
// 获取锁失败，返回默认折扣
return getDefaultDiscount(order);
}
} finally {
connection.del(lockKey.getBytes());
}
}
});
});
}
private BigDecimal doCalculateDiscount(Order order) {
// 1. 先检查缓存
StringcacheKey="discount_" + order.getCouponCode();
BigDecimalcachedDiscount= (BigDecimal) redisTemplate.opsForValue().get(cacheKey);
if (cachedDiscount != null) {
return cachedDiscount;
}
// 2. 异步调用第三方API，设置超时时间
CompletableFuture<CouponValidationResult> apiCall =
couponService.validateCouponAsync(order.getCouponCode())
.orTimeout(2, TimeUnit.SECONDS) // 2秒超时
.exceptionally(ex -> {
log.warn("优惠券验证超时，使用默认策略", ex);
return CouponValidationResult.defaultResult();
});
try {
CouponValidationResultresult= apiCall.get();
BigDecimaldiscount= calculateFinalDiscount(result, order);
// 3. 缓存结果，避免重复计算
redisTemplate.opsForValue().set(cacheKey, discount, Duration.ofMinutes(10));
return discount;
} catch (Exception e) {
log.error("折扣计算异常", e);
return getDefaultDiscount(order);
}
}
}
性能监控改进
// 添加方法级别的性能监控
@Around("@annotation(Timed)")
public Object logExecutionTime(ProceedingJoinPoint joinPoint)throws Throwable {
longstart= System.currentTimeMillis();
Objectproceed= joinPoint.proceed();
longexecutionTime= System.currentTimeMillis() - start;
// 超过1秒的方法记录告警
if (executionTime > 1000) {
log.warn("方法执行时间过长: {} ms, 方法: {}",
executionTime, joinPoint.getSignature());
}
return proceed;
}
第六步：效果验证与长期监控
修复前后对比
|
指标 |
修复前 |
修复后 |
改善幅度 |
|
CPU使用率 |
98% |
25% |
↓ 73% |
|
响应时间 |
8-12秒 |
200-500ms |
↓ 95% |
|
并发处理能力 |
10 TPS |
200 TPS |
↑ 1900% |
|
系统负载 |
8.5 |
1.2 |
↓ 86% |
建立预警机制
# Prometheus告警规则
groups:
- name: cpu_alerts
rules:
- alert: HighCPUUsage
expr: cpu_usage_percent > 80
for: 2m
annotations:
summary: "服务器CPU使用率过高"
description: "CPU使用率已达到{{ $value }}%，持续超过2分钟"
- alert: JavaThreadBlocked
expr: jvm_threads_blocked_count > 10
for: 1m
annotations:
summary: "Java线程阻塞数量异常"
description: "阻塞线程数量：{{ $value }}"
业务影响与价值总结
直接收益
技术债务清理
经验总结：运维老司机的5个黄金法则
1、建立分层监控体系
# 系统层监控
- CPU/Memory/Disk/Network基础指标
- Load Average和进程状态
# 应用层监控
- JVM堆内存、GC状况、线程状态
- 接口响应时间、错误率、TPS
# 业务层监控
- 关键业务指标实时追踪
- 用户行为数据异常检测
2、掌握快速定位工具链
# CPU问题定位三板斧
top → jstack → 代码分析
# 常用命令组合
ps aux | grep java # 找到Java进程
top -H -p <pid> # 查看进程内线程
jstack <pid> | grep -A 10 # 分析线程堆栈
3、制定标准化应急预案
4、重视代码性能review
• 锁使用原则：锁粒度最小化，锁持有时间最短化
• 异步化改造：耗时操作必须异步化处理
• 缓存策略：合理使用多级缓存避免重复计算
5、建立知识库和工具箱
每次故障处理后都要沉淀：
写在最后
作为运维工程师，我们就是系统的"医生"。面对CPU 100%这样的"急症"，需要的不仅是技术能力，更重要的是冷静的分析思路和系统性的解决方案。
希望这篇实战分享能帮助你在遇到类似问题时，能够快速定位、精准处理。记住，每一次故障都是系统优化的机会，每一次深夜的告警都是技术成长的催化剂。
如果这篇文章对你有帮助，请点赞、收藏并分享给更多的运维同仁。也欢迎在评论区分享你遇到的有趣故障案例，让我们一起成长！
来源丨公众号：马哥Linux运维（ID：magedu-Linux）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
如果字段的最大可能长度超过255字节，那么长度值可能…
只能说作者太用心了，优秀
感谢详解
一般干个7-8年（即30岁左右），能做到年入40w-50w；有…
230721