线上CPU飙升至100%！3分钟快速定位根因与解决指南

真实案例背景：凌晨2点，监控告警疯狂响起，电商网站访问缓慢，用户投诉激增。服务器CPU使用率飙升至100%，你有3分钟时间找到问题根源，否则将面临巨大的业务损失...

• 02:15 - 监控告警：服务器CPU使用率持续超过95%

• 02:16 - 用户反馈：页面加载超过10秒

• 02:17 - 运营通知：订单量断崖式下跌

• 02:18 - 开始紧急排查...

# 系统负载异常高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使用率排序，实时刷新top -o %CPU
# 输出示例PID    USER   PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND12847  www    20   0  2.2g    1.8g   12m  R  89.5  11.2   145:32 java8934   mysql  20   0  1.6g    800m   32m  S  8.2   5.1    23:45  mysqld3421   nginx  20   0  128m    45m    8m   S  1.2   0.3     2:34  nginx

# 查看Java进程内部线程CPU使用情况top -H -p 12847
# 输出关键信息PID    USER   PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND12851  www    20   0  2.2g   1.8g    12m  R 45.2  11.2   89:23 java12856  www    20   0  2.2g   1.8g    12m  R 44.3  11.2   78:45 java12863  www    20   0  2.2g   1.8g    12m  S  2.1  11.2    5:34 java

# 将线程ID转换为16进制（Java堆栈中使用16进制）printf "0x%x\n" 12851  # 输出：0x3233printf "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.calculateDiscount方法的245行

• 存在锁竞争问题，多个线程在争夺同一个锁资源

• 线程状态显示为RUNNABLE但实际在等待锁

// 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;    }}

• 锁粒度过大：整个方法使用synchronized，导致所有折扣计算串行执行

• 耗时操作在锁内：第三方API调用在锁保护范围内，严重影响并发性能

• 复杂计算逻辑：大量循环计算进一步加剧了锁竞争

@ServicepublicclassOrderService {    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;}

# 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 }}"

• 故障处理时间：从平均30分钟缩短到3分钟

• 用户体验提升：页面响应时间从10秒降至0.5秒

• 业务损失避免：预估避免每小时50万元的订单损失

• 重构了23个类似的同步方法

• 建立了完整的性能监控体系

• 制定了代码review检查清单

# 系统层监控- CPU/Memory/Disk/Network基础指标- Load Average和进程状态
# 应用层监控  - JVM堆内存、GC状况、线程状态- 接口响应时间、错误率、TPS
# 业务层监控- 关键业务指标实时追踪- 用户行为数据异常检测

# CPU问题定位三板斧top → jstack → 代码分析
# 常用命令组合ps aux | grep java           # 找到Java进程top -H -p <pid>             # 查看进程内线程jstack <pid> | grep -A 10   # 分析线程堆栈

• 2分钟：问题确认和初步定位

• 5分钟：实施临时解决方案

• 30分钟：根因分析和永久修复

• 1小时：复盘总结和预防措施