负载（Load）和 CPU 利用率之间有什么区别？
一则或许对你有用的小广告
欢迎加入小哈的星球，你将获得：专属的实战项目（4个项目都能学） / 1v1 提问 / 简历修改 / Java 学习路线 / 社群讨论 / 学习打卡 / 每月赠书
《Spring AI 项目实战（问答机器人、RAG 智能客服、联网搜索）》已完结，基于
Spring AI + Spring Boot 3.x + JDK 21...，查看介绍《从零手撸：仿小红书（微服务架构）》 已完结，基于
Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，查看介绍；演示链接：http://116.62.199.48:7070/《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接：http://116.62.199.48/
新开坑项目：《从零手撸：秒杀系统高并发优化实战》 正在更新中...，查看介绍
截止目前，星球内专栏累计输出 150w+ 字，讲解图 5110+ 张，还在持续爆肝中.. 后续还会上新更多项目，已有 4700+ 小伙伴加入学习，欢迎点击围观
面试考察点
- 基础概念清晰度：面试官想知道你是不是真明白 Load Average 和 CPU 利用率各代表什么，而不是把这两个数字混为一谈。
- 排查问题的能力：Load 高了，到底是 CPU 瓶颈还是 I/O 瓶颈？能不能通过这两个指标的组合关系快速定位问题方向。
- 运维与系统观：这题考的是你对整个系统的理解深度，而不只是死记硬背某个公式。后端开发、运维、SRE 岗位几乎都会问到。
核心答案
一句话结论：Load 衡量的是系统 “有多少活儿在排队”，CPU 利用率衡量的是 “CPU 这个打工人在多长时间里真的在干活”。
| 对比维度 | 负载（Load Average） | CPU 利用率（CPU Utilization） |
|---|---|---|
| 本质含义 | 运行队列中平均进程数（含等待 CPU 和等待 I/O 的） | CPU 非空闲时间占比 |
| 单位 | 个数（进程/线程数），无量纲 | 百分比（0% ~ 100%） |
| 关注点 | 系统整体繁忙程度 | CPU 资源占用比例 |
| 是否区分多核 | 不区分，是个绝对值，需对照核数看 | 按核统计，单核最高 100% |
| 典型展示 | top / uptime 的三个数字（1/5/15 分钟） |
top 里的 %Cpu(s) 那一行 |
| 健康阈值 | 一般不超 CPU 核数（如 4 核不超过 4） | 长期 100% 说明 CPU 打满 |
关键差别就在这一点：Load 把 “等待磁盘 I/O 的进程” 也算进去了，但 CPU 利用率不算。 这就导致了两者会出现 “Load 很高，CPU 却闲得很” 这种诡异现象。
深度解析
一、Load Average 到底是什么
Load Average 是系统在一段时间内，运行队列（Run Queue）中进程的平均数。运行队列里站着的是这么两类进程：
- 正在 CPU 上跑的（Running）
- 等着 CPU 来跑的（Runnable）
但在 Linux 里还有个关键细节：也包括那些处于 “D 状态”（不可中断睡眠）的进程，这类基本就是在等磁盘 I/O、等网络、等内核锁的。
top 或 uptime 命令会显示三个数字，分别对应 1 分钟、5 分钟、15 分钟的平均值：
load average: 2.50, 1.80, 1.20
读法是：1 分钟内平均 2.5 个进程在排队，5 分钟平均 1.8 个，15 分钟平均 1.2 个。
这里有个特别容易踩的坑：Load 的数值要对照 CPU 核数来看。4 核机器上 Load 为 4，和单核机器上 Load 为 4，完全是两个概念。
- 单核 Load = 4 → 队列里平均排 3 个进程，CPU 已经堵成狗
- 4 核 Load = 4 → 刚好每个核一个进程，健康得很
所以判断 Load 是否过高，真正该看的是 Load / CPU 核数 这个比值。
二、CPU 利用率是什么
CPU 利用率统计的是：在采样周期内，CPU 处于非 idle 状态的时间占比。
top 命令里 %Cpu(s) 那一行能看到细分：
%Cpu(s): 20.0 us, 5.0 sy, 0.0 ni, 73.0 id, 2.0 wa, 0.0 hi, 0.0 si
各个字段的含义：
- us（user）：用户态代码占用
- sy（system）：内核态占用
- id（idle）：CPU 空闲，啥也没干
- wa（iowait）：CPU 在等 I/O 完成
- hi / si：硬中断 / 软中断
CPU 利用率 = 100% - id%。只要 id 不是 100，CPU 就算是在 “工作”，哪怕其中一部分时间其实是在等磁盘。
三、两者的关键差异：一张图看懂
从上面这张图能很清楚地看出差异：
- Load 统计范围更广：P1（在跑）、P2（等 CPU）、P3/P4（等 I/O）全算进去了，Load = 4
- CPU 利用率只盯着 CPU 本身：只统计 P1 真正在 CPU 上执行的那段时间
这就是为什么会出现 “Load 飙升，CPU 却很闲” 的现象。 一堆进程都在等磁盘 I/O（D 状态），运行队列塞满了，Load 自然高，但 CPU 其实大部分时间在 idle，利用率很低。
四、Load 和 CPU 利用率的四种典型组合
排查线上问题时，这俩指标得组合看。记住下面这张表，基本覆盖了 90% 的场景：
| Load | CPU 利用率 | 说明 | 排查方向 |
|---|---|---|---|
| 高 | 高 | CPU 真的打满了 | 死循环、计算密集任务、GC 频繁 |
| 高 | 低 | 大量进程在等 I/O | 磁盘慢、网络阻塞、数据库慢查询 |
| 低 | 高 | 短时 CPU 峰值，采样没抓到 | 业务突发，一般不用太担心 |
| 低 | 低 | 系统很闲 | 正常状态 |
最值得警惕的是第二种：Load 飙到二三十，但 CPU 利用率才 20%。我之前线上出过一次，最后查出来是数据库磁盘 I/O 卡了，Java 服务一堆线程全阻塞在 JDBC 读取上，全是 D 状态，Load 爆表，CPU 反而闲着。这种场景如果你只盯着 CPU 利用率看，会觉得 “系统挺正常的”，结果问题早被你错过了。
五、iowait 这个迷惑项
顺便提一个容易混淆的点：wa（iowait）。
很多人以为 wa 高就是磁盘 I/O 重，其实不完全对。iowait 是 CPU 在 “没事干” 的时间里有进程在等 I/O 的占比。换句话说，它是 idle 的一部分，只是被单独标出来而已。
这就导致一个反直觉的现象：CPU 越闲，iowait 反而可能越高。因为只要 CPU 有别的活儿干，就算有进程在等 I/O，这段时间也不会算进 iowait，而是算进 us/sy。
所以 iowait 高，更准确的解读是：“CPU 很闲，刚好在等 I/O。” 真正要判断 I/O 压力，得看 Load 是不是也跟着飙。
面试高频追问
-
Load 多少算高？
看核数。经验值是 Load ≈ CPU 核数 时算临界点，超过核数说明开始排队。生产环境一般设告警阈值为核数的 1~2 倍。比如 8 核机器，Load 超过 8 就该关注，超过 16 就要紧急处理。
-
Load 高但 CPU 利用率低，怎么排查？
大概率是 I/O 瓶颈。先
top看有没有大量 D 状态进程，再iostat -x 1看磁盘%util和await，iotop找出哪个进程在疯狂读写。常见元凶：数据库慢查询、日志狂刷、大文件读写。 -
D 状态进程是什么？为什么会算进 Load？
D 状态是 “不可中断睡眠”（Uninterruptible Sleep），通常是进程在等磁盘 I/O、NFS、或内核锁。算进 Load 是 Linux 的设计选择，它认为这些进程也是 “想跑但没法跑” 的，理应计入系统负载。
-
多核机器上 Load 是怎么算的？
Load 是全局指标，不分核统计。所以 8 核机器 Load 为 8，平均下来每个核刚好 1 个进程，是健康的。但 Load 为 1 在 8 核机器上意味着 7 个核在空闲，利用率很低。
常见面试变体
- “服务器 Load 高，但 CPU 不高，可能是什么原因？”
- “
top命令里 load average 三个数字怎么看？” - “iowait 高一定是磁盘慢吗？”
- “如何判断系统的 CPU 是否是瓶颈？”
记忆口诀
Load 看排队，利用率看干活；Load 高 CPU 低，去查 I/O。
一句话提炼：Load 是 “排队人数”（含等 I/O 的），CPU 利用率是 “打工人工作比例”，两者组合起来才能判断系统瓶颈到底在哪，是 CPU 密集型还是 I/O 密集型。