空闲 CPU 时间占比是判断系统负载压力的重要指标。监控程序、负载均衡策略和自动扩缩容组件经常拿它作为依据。计算这个比值的核心不是读取某个瞬时百分比字段，而是读取操作系统累计的 CPU 时间计数，通过两次采样计算出区间内的空闲比例。下文分别讨论 Windows、Linux 和 macOS 的获取方式，并给出一个可直接用于项目的跨平台 C++ 封装。
一、空闲 CPU 占比为什么需要两次采样
操作系统并不会直接向用户态程序暴露一个不断变化的空闲百分比。无论是 Windows 还是 Linux、macOS，内核维护的都是自系统启动以来的累计 CPU 时间片。用户可以读取这些计数器，但一次读取只能得到从开机到当前时刻的平均值，无法反映最近几秒的真实负载波动。要获得某个时间段内的空闲占比，必须在两个时间点分别采样，然后用差值计算。
具体公式并不复杂：空闲占比 = (空闲时间差 / 总时间差) × 100%。其中总时间差是前后两次总 CPU 时间的差值，空闲时间差是前后两次空闲时间的差值。注意如果总时间差为零，说明两次采样之间没有任何 CPU 时间消耗，此时不能做除法，应当返回一个默认值或直接返回 0。第一次采样通常用来建立基准，第二次采样才能得到有效结果。采样间隔太短会导致分子和分母都很小，结果容易受调度误差影响；一般建议间隔 200 毫秒以上，500 毫秒是比较稳定的折中值。
跨平台实现时有一个容易被忽略的细节：不同 API 返回的时间单位并不相同。Windows 的 GetSystemTimes 返回 FILETIME，单位是 100 纳秒；Linux 的 /proc/stat 返回的是 jiffies，单位与内核的 USER_HZ 有关，常见为 10 毫秒；macOS 的 host_processor_info 返回 tick 计数，单位和平台时钟源相关。好在计算比值时单位会在除法中约去，所以只要同一平台前后两次使用相同的单位和字段口径，最终结果就是可信的。
二、Windows 实现：GetSystemTimes 与 FILETIME 转换
Windows 提供 GetSystemTimes 函数，用来获取整个系统的 CPU 时间统计。它有三个输出参数：空闲时间、内核时间和用户时间。这里有一个容易犯错的地方：内核时间中包含空闲时间，因为 Windows 的空闲任务本身运行在内核模式下。因此计算总 CPU 时间时，应当使用 内核时间 + 用户时间，而不是把空闲时间再加进去。空闲占比就是 空闲时间 / (内核时间 + 用户时间)。如果需要计算繁忙占比，用 1 - 空闲占比 即可，不要从内核时间减去空闲时间后再加用户时间，那样反而会漏掉一部分内核态实际工作时间。
FILETIME 结构由两个 32 位字段组成，需要用 ULARGE_INTEGER 或位移合并成 64 位整数。下面的代码封装了 Windows 平台上的采样函数，返回统一结构体，方便后续跨平台计算。
#include <windows.h>
#include <cstdint>
struct CpuTimes {
std::uint64_t idle;
std::uint64_t total;
};
static std::uint64_t FileTimeToU64(const FILETIME& ft) {
ULARGE_INTEGER uli;
uli.LowPart = ft.dwLowDateTime;
uli.HighPart = ft.dwHighDateTime;
return uli.QuadPart;
}
bool GetWindowsCpuTimes(CpuTimes& times) {
FILETIME idle, kernel, user;
if (!GetSystemTimes(&idle, &kernel, &user)) {
return false;
}
std::uint64_t idleTicks = FileTimeToU64(idle);
std::uint64_t kernelTicks = FileTimeToU64(kernel);
std::uint64_t userTicks = FileTimeToU64(user);
times.idle = idleTicks;
times.total = kernelTicks + userTicks;
return true;
}
在 Windows 上做两次采样时，可以直接使用 Sleep 来间隔一段时间。不过 Sleep 的精度不高，可能偏差几毫秒到十几毫秒，但这对于 CPU 占比的统计完全足够。因为占比计算依赖的是 CPU 时间片而不是墙钟时间，采样间隔只影响区间代表的时间尺度，不会因为 Sleep 不准就改变 CPU 的计数关系。
另一个注意点是 GetSystemTimes 返回的是系统全局数据，已经自动汇总了所有逻辑处理器。即使机器有 128 核，也不需要手动累加。如果你的监控系统只关心某个进程或某个 CPU 核心，则需要使用 GetProcessTimes 或 GetSystemTimeAdjustment 以外的针对性 API，本文讨论的是系统整体空闲占比。
三、Linux 与 macOS：解析 /proc/stat 和 host_processor_info
Linux 下读取系统 CPU 时间最常见的方法是解析 /proc/stat。文件第一行以 cpu 开头，后面的数字依次表示 user、nice、system、idle、iowait、irq、softirq、steal 等时间片。总时间通常取从 user 到 steal 的所有字段之和。空闲时间是否包含 iowait 取决于业务口径：如果认为 CPU 在等待 I/O 时没有任务可执行，就应该把 iowait 计入空闲；如果只要 CPU 不处于 idle 和 iowait 就算繁忙，那么空闲只取 idle 字段。很多监控工具会把 iowait 从空闲中剥离开来单独展示，因此实现时最好把两种口径都留出来。
下面是一个读取 Linux 首行 CPU 时间并计算总时间和空闲时间的函数。函数中 iowait 被计入空闲，读者可以根据自己的需要去掉这一项。
#include <fstream>
#include <sstream>
#include <string>
#include <vector>
#include <cstdint>
struct CpuTimes {
std::uint64_t idle;
std::uint64_t total;
};
bool GetLinuxCpuTimes(CpuTimes& times) {
std::ifstream file("/proc/stat");
if (!file.is_open()) return false;
std::string line;
while (std::getline(file, line)) {
if (line.compare(0, 4, "cpu ") != 0) {
continue;
}
std::istringstream ss(line);
std::string label;
ss >> label;
std::vector<std::uint64_t> fields;
std::uint64_t value = 0;
while (ss >> value) {
fields.push_back(value);
}
if (fields.size() < 8) return false;
std::uint64_t user = fields[0];
std::uint64_t nice = fields[1];
std::uint64_t system = fields[2];
std::uint64_t idle = fields[3];
std::uint64_t iowait = fields[4];
std::uint64_t irq = fields[5];
std::uint64_t softirq = fields[6];
std::uint64_t steal = fields[7];
std::uint64_t total = user + nice + system + idle + iowait + irq + softirq + steal;
times.idle = idle + iowait;
times.total = total;
return true;
}
return false;
}
macOS 的实现思路类似，但 API 完全不同。系统通过 host_statistics 或 host_processor_info 提供 host_cpu_load_info_data_t 结构，其中 cpu_ticks 数组按状态存放累计 tick。常用状态有 CPU_STATE_USER、CPU_STATE_SYSTEM、CPU_STATE_IDLE 和 CPU_STATE_NICE。总时间取这四项之和，空闲时间取 CPU_STATE_IDLE。tick 的具体时长由平台决定，但前后差值在计算比例时会约去，因此不影响最终百分比。
以下代码展示了 macOS 的核心采样过程，返回的仍然是统一的 CpuTimes 结构体。
#include <mach/mach.h>
#include <mach/mach_host.h>
#include <cstdint>
struct CpuTimes {
std::uint64_t idle;
std::uint64_t total;
};
bool GetMacCpuTimes(CpuTimes& times) {
host_cpu_load_info_data_t cpuInfo;
mach_msg_type_number_t count = HOST_CPU_LOAD_INFO_COUNT;
kern_return_t kr = host_statistics(mach_host_self(),
HOST_CPU_LOAD_INFO,
reinterpret_cast<host_info_t>(&cpuInfo),
&count);
if (kr != KERN_SUCCESS) {
return false;
}
std::uint64_t user = cpuInfo.cpu_ticks[CPU_STATE_USER];
std::uint64_t system = cpuInfo.cpu_ticks[CPU_STATE_SYSTEM];
std::uint64_t idle = cpuInfo.cpu_ticks[CPU_STATE_IDLE];
std::uint64_t nice = cpuInfo.cpu_ticks[CPU_STATE_NICE];
times.idle = idle;
times.total = user + system + idle + nice;
return true;
}
macOS 上获取的 tick 数据是逐 CPU 汇总后的整体。如果机器有多个核心，系统返回的数据已经把各核心时间相加。用户不需要自己根据处理器数量做乘法，但要确保链接了对应的系统框架，比如 mach 相关库。
四、跨平台封装与采样策略
有了三个平台的底层采样函数，可以在 C++ 中用一个类封装采样和计算逻辑。类的核心方法是 GetIdleRatio，它先调用一次平台采样作为基准，等待一小段时间后再次采样，然后根据两次差值返回空闲 CPU 时间占比。这样上层调用方不需要关心平台差异，也不需要自己管理第一次采样的状态。
下面是一个跨平台封装示例。编译时通过条件宏选择不同的平台实现，三个底层函数已经在前面小节给出。
#include <chrono>
#include <thread>
#include <cstdint>
struct CpuTimes {
std::uint64_t idle;
std::uint64_t total;
};
#if defined(_WIN32)
bool GetCpuTimes(CpuTimes& times) {
return GetWindowsCpuTimes(times);
}
#elif defined(__APPLE__)
bool GetCpuTimes(CpuTimes& times) {
return GetMacCpuTimes(times);
}
#elif defined(__linux__)
bool GetCpuTimes(CpuTimes& times) {
return GetLinuxCpuTimes(times);
}
#else
bool GetCpuTimes(CpuTimes&) { return false; }
#endif
class CpuIdleMonitor {
public:
double GetIdleRatio(std::uint32_t intervalMs = 500) {
CpuTimes first, second;
if (!GetCpuTimes(first)) {
return -1.0;
}
std::this_thread::sleep_for(std::chrono::milliseconds(intervalMs));
if (!GetCpuTimes(second)) {
return -1.0;
}
std::uint64_t idleDelta = second.idle - first.idle;
std::uint64_t totalDelta = second.total - first.total;
if (totalDelta == 0) {
return 0.0;
}
return static_cast<double>(idleDelta) /
static_cast<double>(totalDelta) * 100.0;
}
};
除了采样函数本身，采样间隔的选择也会影响数据质量。50 毫秒的间隔虽然响应快，但两次采样的 tick 差值较小，容易受调度、时钟精度等噪声影响，百分比波动可能较大。500 毫秒到 1000 毫秒的间隔适合大多数监控场景，既能反映近期负载，又不会因为单次调度抖动产生误报。第一次调用 GetIdleRatio 时内部会自动做二次采样，上层不需要预热，但要注意这个调用本身会阻塞 intervalMs 毫秒。
在实际部署中，如果监控程序长时间运行，建议将采样函数放在独立线程中，不要让主线程频繁陷入 sleep。同时应当缓存上一次的 CpuTimes 数据，使用滑动窗口或固定周期更新，避免多个模块各自独立采样造成不必要的系统调用开销。如果只需要粗略判断，也可以在 intervalMs 中使用略小于目标周期的值，以留出自身计算时间。
五、验证结果与常见误区
要验证封装是否正确，可以写一个简单的 main 函数，在不同负载下分别观察空闲占比变化。例如启动时先调用一次 GetIdleRatio(500)，再开启几路 CPU 密集任务，再次调用。正常情况下空闲占比会从较高值明显下降，任务结束后又会回升。这个变化过程比绝对数值更能说明采集逻辑是否正确。
跨平台 CPU 采集有不少细节容易踩坑。一个常见误区是把 Windows 的 kernel + user + idle 当作总时间，导致分母偏大，空闲占比被低估。另一个误区是在 Linux 解析 /proc/stat 时误把 cpu0、cpu1 这些单核行也计入总计，造成多核机器数据翻倍。还有开发者在使用 FILETIME 时只取低 32 位，溢出后结果完全错误；或者忽略 GetSystemTimes 返回的布尔值，API 调用失败后继续使用未初始化的数据。
macOS 路径同样需要留意 host_statistics 的返回码，忘记检查 KERN_SUCCESS 会导致数组中的内容不可靠。另外 Linux 的 steal 时间在虚拟化环境中经常不为零，它表示被其他虚拟机抢占的 CPU 时间。业务系统通常会把 steal 计入总时间，但不计入空闲，也不是自己的实际繁忙时间，所以如果监控结果一直偏低，可以先检查虚拟化平台是否产生了大量 steal。
总之，系统空闲 CPU 时间占比的本质是累计计数器的区间差值计算。只要抓住这个核心，再注意各平台的字段口径和单位差异，就能实现一个准确、稳定、可维护的跨平台采集模块。