一、面试官的 “小心机”，你看透了吗？

在面试中，当被问到 “CPU 100% 如何处理” 这样的问题时，你可千万别小瞧它，这背后藏着面试官满满的 “小心机”。一方面，这是在考察你对计算机系统底层运作机制的理解深度，从 CPU 的工作原理、进程线程的调度，到内存管理等多方面知识，一个都不放过；另一方面，更重要的是检验你的问题排查与解决实战能力，面对突发的系统故障，看你能否迅速理清思路、精准定位问题，并且高效给出解决方案。

要想漂亮地回答这个问题，关键就在于展现出清晰的排查思路与扎实的技术功底。接下来，咱们就一步步揭开这道题的 “神秘面纱”，看看如何在面试中让面试官为你的回答点赞。

二、原因大起底，“病根” 先找准！

（一）代码 “黑洞”：死循环、死锁与冗余

首先，来看看代码层面可能出现的问题。死循环堪称 “CPU 杀手”，就像下面这段代码：

while (true) {
 // 执行一些无意义的操作，比如不断累加一个变量
 int num = 0;
 num++;
}

由于循环条件永远为真，CPU 就会像个不知疲倦的陀螺，一直疯狂运转。这往往是因为程序员粗心，在条件判断时逻辑出错，或者忘记更新循环变量，让程序陷入了这个 “无底洞”。

死锁也是一大 “元凶”。当多个线程相互争夺资源，又各自握住对方所需资源不放手时，就会出现死锁。想象两个线程，一个持有锁 A 等待锁 B，另一个持有锁 B 等待锁 A，它们就这么僵持着，CPU 资源也被白白消耗。例如：

import java.util.concurrent.locks.ReentrantLock;
public class DeadlockExample {
 private static final ReentrantLock lock1 = new ReentrantLock();
 private static final ReentrantLock lock2 = new ReentrantLock();
 public static void main(String[] args) {
 Thread thread1 = new Thread(() -> {
 lock1.lock();
 try {
 Thread.sleep(100);
 lock2.lock();
 // 执行一些需要同时持有两把锁的操作
 } catch (InterruptedException e) {
 e.printStackTrace();
 } finally {
 lock2.unlock();
 lock1.unlock();
 }
 });
 Thread thread2 = new Thread(() -> {
 lock2.lock();
 try {
 Thread.sleep(100);
 lock1.lock();
 // 执行一些需要同时持有两把锁的操作
 } catch (InterruptedException e) {
 e.printStackTrace();
 } finally {
 lock1.unlock();
 lock2.unlock();
 }
 });
 thread1.start();
 thread2.start();
 }
}

在这段代码中，thread1 先获取了 lock1，然后休眠 100 毫秒，此时 thread2 获取了 lock2，接着它们都试图获取对方持有的锁，于是死锁就发生了，CPU 占用率会飙升。

还有那些不必要的同步块，就像在通畅道路上设置的减速带。有些代码明明不需要同步，却加了synchronized关键字，导致线程频繁地争抢锁资源，无谓地消耗 CPU。比如：

public class UnnecessarySyncExample {
 public synchronized void unnecessarySyncMethod() {
 // 这里只是进行一些简单的读取操作，不需要同步
 int value = 10;
 System.out.println(value);
 }
}

在这个例子中，unnecessarySyncMethod方法只是简单地读取并打印一个变量，不存在资源竞争问题，使用synchronized关键字只会增加线程上下文切换的开销，使 CPU 负担加重。

（二）并发 “乱象”：密集计算、线程暴走与切换过载

接着聊聊并发引发的问题。大量计算密集型任务一股脑儿地涌上来，CPU 可就吃不消了。比如说在进行大数据分析、复杂的数学建模或者图形渲染时，如果没有合理安排任务，让多个高负荷计算任务同时争抢 CPU 时间片，CPU 使用率瞬间就会拉满。像下面这个简单的矩阵乘法计算示例，若多个大矩阵同时进行乘法运算：

public class MatrixMultiplication {
 public static void multiplyMatrices(int[][] matrix1, int[][] matrix2) {
 int rows1 = matrix1.length;
 int cols1 = matrix1[0].length;
 int cols2 = matrix2[0].length;
 int[][] result = new int[rows1][cols2];
 for (int i = 0; i < rows1; i++) {
 for (int j = 0; j < cols2; j++) {
 int sum = 0;
 for (int k = 0; k < cols1; k++) {
 sum += matrix1[i][k] * matrix2[k][j];
 }
 result[i][j] = sum;
 }
 }
 // 这里只是简单打印结果矩阵的维度，实际应用中可能会对结果有更多处理
 System.out.println("Result matrix dimensions: " + result.length + "x" + result[0].length);
 }
}

如果有多个大尺寸矩阵同时调用这个multiplyMatrices方法，CPU 核心就会忙于处理这些复杂的乘法和累加运算，占用率急剧攀升。

过多的并发线程也会搅得 CPU 不得安宁。系统创建大量线程，每个线程都需要 CPU 分配时间片来运行，频繁的上下文切换就成了 CPU 的沉重负担。比如一个 Web 服务器，面对高并发请求时，为每个请求都创建一个新线程，线程数量远超 CPU 核心数，CPU 就会在这些线程之间疲于奔命，不断切换执行上下文，大量时间浪费在保存和恢复线程状态上，有效计算时间大幅减少，整体性能反而下降。

（三）内存 “雷区”：不足、泄漏与 GC 频发

再把目光投向内存相关的问题。内存不足时，系统不得不启用虚拟内存，将磁盘空间当作 “救兵”。但磁盘的读写速度可比内存慢太多了，大量时间花在数据的换入换出上，CPU 只能干等着数据就绪，占用率自然居高不下。就像一个小程序试图加载一个超大文件到内存：

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
public class MemoryCrunchExample {
 public static void main(String[] args) {
 try {
 byte[] largeData = Files.readAllBytes(Paths.get("hugeFile.txt"));
 // 后续可能对largeData进行处理，但这里先关注加载导致的内存问题
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
}

如果这个 “hugeFile.txt” 文件大到超出物理内存容量，系统就会陷入虚拟内存的 “泥潭”，CPU 占用率飙升。

内存泄漏更是一颗 “定时炸弹”。程序中一些对象被创建后，由于错误的引用关系，无法被垃圾回收器识别回收，久而久之，可用内存越来越少。垃圾回收器（GC）不得不频繁出动，试图清理这些 “垃圾”，而 GC 过程本身就需要消耗大量 CPU 资源。例如：

import java.util.ArrayList;
import java.util.List;
public class MemoryLeakExample {
 private static List