CPU 使用率就是 CPU 非空闲态运行的时间占比，它反映了 CPU 的繁忙程度。

比如，单核 CPU 1s 内非空闲态运行时间为 0.8s，那么它的 CPU 使用率就是 80%；双核 CPU 1s 内非空闲态运行时间分别为 0.4s 和 0.6s，那么，总体 CPU 使用率就是 (0.4s + 0.6s) / (1s * 2) = 50%，其中 2 表示 CPU 核数，多核 CPU 同理。

在 Linux 系统下，使用 top 命令查看 CPU 使用情况，可以得到如下信息：

因为 CPU 有多种非空闲态，所以CPU 使用率计算公式可以总结为： CPU 使用率 = (1 - 空闲态运行时间/总运行时间) * 100%。

根据经验法则， 建议生产系统的 CPU 总使用率不要超过 70%。

平均负载（Load Average）是指单位时间内，系统处于 可运行状态（Running / Runnable） 和 不可中断态 的平均进程数，也就是 平均活跃进程数。

可运行态进程包括正在使用 CPU 或者等待 CPU 的进程；不可中断态进程是指处于内核态关键流程中的进程，并且该流程不可被打断。 比如当进程向磁盘写数据时，如果被打断，就可能出现磁盘数据与进程数据不一致。不可中断态，本质上是系统对进程和硬件设备的一种保护机制。

在 Linux 系统下，使用 top 命令查看平均负载，可以得到如下信息：

这 3 个数字分别表示 1分钟、5分钟、15分钟内系统的平均负载。 该值越小，表示系统工作量越少，负荷越低；反之负荷越高。

平均负载为多少更合理？

理想情况下，每个 CPU 应该满负荷工作，并且没有等待进程，此时，平均负载 = CPU 逻辑核数。 但是，在实际生产系统中，不建议系统满负荷运行。 通用的经验法则是：平均负载 = 0.7 * CPU 逻辑核数。

除了关注平均负载值本身，我们也应关注平均负载的变化趋势，这包含两层含义： 一是 load1、load5、load15 之间的变化趋势； 二是历史的变化趋势。

当 load1、load5、load15 三个值非常接近，表明短期内系统负载比较平稳。此时，应该将其与昨天或上周同时段的历史负载进行比对，观察是否有显著上升。

当 load1 远小于 load5 或 load15 时，表明系统最近 1 分钟的负载在降低，而过去 5 分钟或 15 分钟的平均负载却很高。

当 load1 远大于 load5 或 load15 时，表明系统负载在急剧升高，如果不是临时性抖动，而是持续升高，特别是当 load5 都已超过 0.7 * CPU 逻辑核数 时，应调查原因，降低系统负载。

无论是 CPU 使用率，还是平均负载，都只是反映系统健康状态的度量指标，而不是问题的根因。

因此，它们的价值主要体现在两个方面：

一是综合反映当前系统的健康程度，结合监控告警产品，实现快速响应； 二是初步定位问题方向，缩小排查范围，降低故障恢复时间。

比如当 CPU iowait 高时，应优先排查磁盘 I/O；当 CPU steal 高时，就优先排查宿主机状态。

CPU 涵盖的问题场景有很多，限于篇幅限制，下面以最常见的用户态 CPU 使用率高为例，介绍下 Java 应用的排查思路，其他场景留待后续分享，推荐阅读 《如何迅速分析出系统CPU的瓶颈在哪里？》。

如何排查用户态 CPU 使用率高？

用户态 CPU 使用率反映了应用程序的繁忙程度，通常与我们自己写的代码息息相关。 因此，当你在做应用发布、配置变更或性能优化时，如果想定位消耗 CPU 最多的 Java 代码，可以遵循如下思路：

上述方法是目前业界最常用的诊断流程，如果是非 Java 应用，可以将 jstack 替换为 perf，推荐阅读 《Perf — Linux下的系统性能调优工具》。

然而，上述方法有两个显著缺陷，一是操作流程复杂，而且往往一次 jstack 还不足以定位根因，需要执行多次；二是只能用于诊断在线问题，如果问题已经发生，无法复现的话，往往只能不了了之。

生产系统推荐使用 APM 产品，比如阿里云的 ARMS，可以自动记录每类线程的 CPU 耗时和方法栈，开箱即用，自动保留问题现场。

CPU 平均负载为多少更合理？ https://blog.csdn.net/Dongguabai/article/details/113846330

服务器CPU负载过高，如何定位问题 https://www.jianshu.com/p/45c6bcb85934

如何正确理解 CPU 使用率和平均负载的关系？ https://blog.csdn.net/wwwwww33/article/details/108378406