生产环境Java与MySQL CPU飙升900%排查定位与优化实战

场景概述：CPU飙升900%的典型生产场景

在生产环境的性能监控中，CPU使用率飙升到200%甚至900%是一个需要紧急处理的严重问题。通常，这指向了应用程序或底层服务存在性能瓶颈或设计缺陷。

场景一：MySQL进程CPU占用率异常

在使用MySQL数据库时，经常会遇到CPU使用率突然飙升至异常水平的情况。当数据库执行大量查询或数据修改操作，尤其是SQL语句性能低下（如未使用索引）时，系统需要消耗巨大的CPU资源来维护数据一致性和处理请求。在高并发场景下，这极易导致CPU快速飙升，若此时还开启了慢查询日志记录，更是雪上加霜。

场景二：Java应用进程CPU占用率异常

通常，Java应用进程若不进行大量CPU密集型运算，其CPU占用率会维持在较合理的范围。然而，在高并发场景下，如果程序逻辑陷入死循环，或因为创建大量对象而触发频繁的垃圾回收（GC），就很可能出现CPU占用率飙升到900%的情况。

场景一深度解析：MySQL进程CPU飙升900%的处理流程

问题定位步骤

1. 使用 top 命令观察系统整体资源使用情况，确认是否是 mysqld 进程导致的CPU过高。
2. 如果是MySQL导致，则连接数据库，执行 SHOW PROCESSLIST; 命令，查看当前所有会话状态，识别是否存在执行时间过长或资源消耗巨大的SQL语句。
3. 分析这些高消耗的SQL语句，检查其执行计划是否合理，是否由于缺少索引、表数据量过大或存在锁竞争等问题导致性能低下。

问题处理与优化

1. 紧急处置：临时 KILL 掉问题会话（同时观察CPU使用率是否随之下降），为后续优化争取时间。
2. 根本优化：针对定位到的SQL进行优化，常见的措施包括：
   • 添加合适索引：这是提升查询效率最直接有效的手段之一。
   • 重构SQL语句：优化查询逻辑，避免全表扫描、不必要的联表或子查询。
   • 调整数据库参数：根据实际情况优化如缓冲池大小等内存参数。
   • 限制连接数：如果是因为瞬间涌入大量连接导致，需与应用开发团队协作，分析连接激增原因并实施限流。
3. 引入缓存：对于实时性要求不高的查询，考虑使用 Redis 等缓存中间件来减轻数据库压力。
4. 审慎开启慢日志：在CPU已过高时，开启慢查询日志会引入额外的磁盘I/O，可能加剧性能恶化，建议在系统负载相对较低时进行。

优化是一个持续迭代的过程，通常需要“实施优化->观察效果->再次优化”的循环。

真实案例参考：一次SQL索引缺失引发的CPU风暴

某线上系统MySQL的CPU使用率曾一度超过900%。排查过程如下：

1. 通过 SHOW PROCESSLIST 发现大量相同SQL处于执行状态：SELECT id FROM user WHERE user_code = 'xxxxx';。
2. 检查表结构 (SHOW INDEX FROM user;) 后，确认 user_code 字段未建立索引。
3. 为 user_code 字段添加索引后，该SQL执行效率大幅提升，CPU降至300%左右。
4. 进一步分析，发现系统在CPU高压下仍开启了慢查询日志，关闭后性能有所改善。
5. 最终，将部分频繁查询的非实时数据改由缓存提供服务，系统CPU使用率最终稳定在70%~80%。

场景二深度解析：Java进程CPU飙升900%的处理流程

问题定位步骤

1. 定位问题进程：使用 top 命令，找出CPU占用率异常的Java进程PID。
2. 定位问题线程：使用 top -Hp [PID] 命令，查看该进程内所有线程的CPU占用情况，找到消耗最高的线程TID。
3. 转换线程ID：将十进制的线程TID转换为十六进制，以便在堆栈日志中查找。命令：printf "%x\n" [TID]。
4. 获取线程堆栈：使用 jstack -l [PID] > jstack_result.txt 命令导出线程快照。
5. 定位问题代码：在 jstack_result.txt 文件中，根据十六进制线程ID（格式如 nid=0x[十六进制值]）搜索，找到对应的线程堆栈信息，从而定位到具体的Java类和方法。

常见原因与解决方案

1. 空循环或空自旋：在循环条件中未进行有效的阻塞或等待。解决方案：在循环体内加入 Thread.sleep() 或使用锁机制让线程适时等待。
2. 频繁创建对象引发大量GC：例如，单次从数据库查询出百万级数据并转换为对象列表。解决方案：优化逻辑，减少不必要的对象创建；考虑分页查询；对于可重用对象，评估使用对象池的可能性。
3. 其他特定场景：如网络编程中 Selector 的空轮询。解决方案：参考成熟框架（如Netty）的处理方式，在检测到一定次数的无效事件后，重建 Selector。

真实案例参考：阻塞队列空轮询导致的CPU飙升

某Java应用上线后CPU占用率持续高达700%。通过上述定位步骤，发现一个名为 ImageConverter.run() 的线程消耗了绝大部分CPU。

其核心代码如下：

while (isRunning) {
    if (dataQueue.isEmpty()) { // 队列为空时，进入空循环
        continue;
    }
    byte[] buffer = device.getMinicap().dataQueue.poll();
    // ... 后续处理
}

问题分析：当 dataQueue 这个 LinkedBlockingQueue 长时间为空时，while 循环将不断执行 if 判断和 continue，导致空转，CPU占用率极高。

解决方案：将非阻塞的 poll() 方法改为阻塞的 take() 方法。当队列为空时，调用线程会自然阻塞等待，直到有新元素入队或被中断，从而释放CPU资源。

while (isRunning) {
    try {
        byte[] buffer = device.getMinicap().dataQueue.take(); // 使用take()方法
        // ... 后续处理
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

优化后，该应用的CPU使用率下降并稳定在10%以下。