凌晨3点CPU飙升100%：排查过程与血泪教训

Sun, 26 Mar 2023 00:00:00 +0000

不知你是否经历过这种时刻：手机在凌晨疯狂震动，告警群里全是红色的[CRITICAL]，服务器CPU监控线笔直地拉成一条横线，且居高不下。

我一直信奉"周五不发布"的铁律，但两年前的那次破例，让我结结实实地踩了一个大坑。当时为了赶一个看似简单的"数据同步优化"功能，我在周五傍晚匆忙上了一个补丁。结果当天凌晨3点，负责核心结算的微服务集群CPU全线打满，业务响应时间从20ms飙升到超时。

这不仅是一次事故复盘，更是我对"防御性编程"认知的转折点。在那之前，我以为代码逻辑跑通就行；在那之后，我明白了什么是敬畏生产环境。

拒绝重启，现场保留"作案证据"

面对线上CPU爆表，很多运维或新手的本能反应是——重启试试。

重启确实能暂时止血，但它同时也销毁了"犯罪现场"。如果不知道病因，重启只是把定时炸弹的时间重置了，下一次爆炸会来得更猛烈。

我当时强行按住了想去点重启按钮的手，坚持要先抓取堆栈信息。

这就好比破案，你得先留存指纹。在Linux环境下，定位Java应用CPU高的标准动作其实就那几步，但我发现很多人在紧张时容易乱。

定位进程：top 命令一敲，PID为 18920 的Java进程稳居榜首，CPU占用率达到了惊人的 780%（8核机器）。
定位线程：光知道进程没用，得知道是哪个线程在捣乱。执行 top -Hp 18920，我看到 PID 为 19011 的线程一直占用着单核的99%。
转换进制：将线程ID 19011 转换为16进制 4a43（因为jstack里用的是16进制）。
导出堆栈：执行 jstack 18920 | grep -A 20 4a43。

思考题：如果你的生产环境没有权限执行 jstack 或者 top 命令被阉割了，你们现有的监控系统（如Prometheus, SkyWalking）能直接定位到代码行吗？

这一套组合拳打完，仅仅耗时2分钟。屏幕上清晰地打印出了罪魁祸首的代码行数。看到那个类名的时候，我后背一阵发凉——正是我下午提交的那个"优化"代码。

死循环：隐藏在异常处理里的杀手

堆栈指向了一行看似人畜无害的代码：一个处理Redis消息队列的 while 循环。

在这个案例中，我的初衷是好的。为了保证数据不丢失，我写了一个消费者线程，不断从Redis中拉取数据进行处理。代码逻辑大致如下（简化版）：

// 错误示范：造成CPU 100%的逻辑
while (true) {
    try {
        String msg = redisService.pop(key);
        if (msg != null) {
            process(msg);
        }
    } catch (Exception e) {
        log.error("Redis error", e);
        // 致命疏忽：这里没有做任何休眠或退避
    }
}

问题出在哪里？

当晚凌晨，云服务商的Redis实例发生了一次短暂的内网抖动。redisService.pop(key) 抛出了连接异常。

按照正常的逻辑，异常被捕获，打印日志。但是，由于catch块中没有哪怕1毫秒的 sleep，也没有跳出循环，这个 while(true) 瞬间变成了一个极其紧密的死循环。

线程疯狂地抛出异常 -> 捕获异常 -> 打印日志 -> 再次重试。

JVM在极短时间内进行了数百万次的方法调用和对象创建，日志文件以每秒几百MB的速度疯狂膨胀（导致磁盘IO也跟着报警），CPU直接被吃干抹净。

这是一个典型的"假死循环"。它不是逻辑上的死锁，而是由于缺乏退避机制（Backoff）导致的资源耗尽。

我曾在Code Review中多次强调NPE（空指针）的检查，却忽略了这种在异常态下的资源保护。你是否也曾觉得：“加了try-catch就万事大吉了”？

加上"熔断"与"退避"，才是成熟的代码

定位到问题后，修复方案其实很简单。紧急发布修复包，加上了指数退避策略，服务恢复了平静。

但这件事让我反思了很久：为什么一个中间件的抖动，能搞垮我的核心服务？

这暴露出架构设计上的脆弱性。我们在设计系统时，往往假设依赖服务是永远可靠的，网络是永远通畅的。

针对这次事故，我后续落地了三层防护体系，这套方法我沿用至今：

1. 强制性的退避策略

在任何 while 循环或重试逻辑中，必须包含休眠机制。

// 改进后的逻辑
int retryCount = 0;
while (true) {
    try {
        String msg = redisService.pop(key);
        // ...处理逻辑
        retryCount = 0; // 成功则重置
    } catch (Exception e) {
        log.error("Redis error", e);
        retryCount++;
        // 指数退避：发生错误时，休息时间越来越长，避免把下游打死
        long sleepTime = Math.min(1000 * (1 << retryCount), 60000); 
        Thread.sleep(sleepTime); 
    }
}

2. 引入轻量级熔断

不要盲目自信地一直重试。如果Redis真的挂了，你的应用应该"认怂"。我们引入了 Resilience4j 这样的轻量级库，当异常比例达到阈值（比如50%），直接熔断该功能，降级为记录本地文件或内存队列，等待人工介入或自动恢复。

3. 资源隔离（Bulkhead）

之前那个处理线程直接使用了默认的线程池。一旦死循环，虽然只是单线程，但也可能因为疯狂GC影响整个JVM。后来我们将关键任务分配到独立的线程池中，并限制了最大线程数和队列长度。即使这个池子炸了，也不会拖垮处理HTTP请求的主线程池。

总结与行动指南

那次事故后，我养成了一个习惯：写任何循环（Loop）的时候，先问自己三个问题：

它什么时候结束？
如果内部报错了，它会狂转吗？
它会不会把CPU或内存吃光？

如果你正在经历或想要预防类似的问题，以下是3个可落地的建议：

实战演练定位命令：不要等到故障发生时再去百度"Linux CPU 100% 怎么查"。找一台测试机，写一个死循环程序，亲自用 top 和 jstack 抓一次，形成肌肉记忆。
审查所有 while(true)：利用IDE的全局搜索，检查项目中所有的无限循环和递归调用，确保在 catch 块中有 Thread.sleep 或退出机制。
配置JVM监控告警：不要只看系统级CPU。确保你的Prometheus/Grafana监控了 JVM 的 GC 频率和线程数。很多时候，CPU 100% 并不是死循环，而是因为内存泄漏导致的频繁 Full GC。

最后，留一个问题给各位同行： 在你的项目中，如果数据库或Redis突然断连1分钟，你的服务是会优雅降级，还是会像无头苍蝇一样疯狂报错直到崩溃？

愿你的CPU常年保持在 20% 以下，愿你所有的报警都发生在工作日上班时间。

记一次线上CPU 100%的排查与解决过程 on SelfTechHub