Linux下用/proc/stat解析每核CPU占用率需两次采样cpu0、cpu1等行,计算(user+nice+system+irq+softirq)/total_time_delta×100;上下文切换次数须从/proc/[pid]/status读取voluntary_ctxt_switches和nonvoluntary_ctxt_switches累计值并做差分。
直接读取 /proc/stat 是唯一稳定获取每核 user、nice、system、idle、iowait、irq、softirq 累计时间(单位:jiffies)的方式。注意第一行是全局汇总,后续 cpu0、cpu1… 才对应物理核心(含超线程逻辑核)。
关键点在于两次采样做差值计算:间隔 100–500ms 再读一次,用公式 (total - idle) / total * 100.0 得到该核利用率百分比。别直接用单次读数——那是自启动以来的累计值,没意义。
cpu 行(全局),只处理 cpu0、cpu1 等带数字的行steal、guest),建议按空格 split 后取前 8 个字段,避免越界std::stoull() 或 strtoull() 解析,否则溢出成负数Linux 不提供“当前运行频率”的统一接口,/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 返回的是 cpufreq 驱动上报的当前频率(单位 kHz),但它可能被缓存、延迟更新,或在 intel_pstate 驱动下返回 0(此时需 fallback 到 scaling_max_freq 和负载估算)。
更可靠的做法是结合 topology 信息:先读 /sys/devices/system/cpu/cpu0/topology/core_id 分组逻辑核(比如 cpu0/cpu1 属于 core 0),再对每个物理核取所有隶属逻辑核的 scaling_cur_freq 最大值——这更接近该物理核实际运行频率。
立即学习“C++免费学习笔记(深入)”;
scaling_cur_freq 恒为 0,只能靠 cpuinfo_cur_freq(需 root)或周期性读 cpuinfo_max_freq + 负载反推/sys/devices/system/cpu/cpu*/topology/physical_package_id 可区分 CPU 插槽,但多路服务器中不能替代 core_id 分组cat /proc/cpuinfo | grep "cpu MHz" ——那是 boot-time 估算值,不反映实时变化进程级上下文切换次数藏在 /proc/<pid>/status</pid> 的 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches 字段里,前者是主动 sleep/yield 导致,后者是被抢占或缺页强制调度。但这是累计值,要波动就得两次采样求差。
注意:/proc/<pid>/stat</pid> 第 42 和 43 字段也对应这两个数,但字段序号易随内核版本变动(比如 5.10+ 增加了新字段),status 文件结构更稳定,优先用它。
/proc/<pid>/status</pid>,所以监控自身用 getpid() 即可,跨进程监控需提权nonvoluntary 切换通常意味着 CPU 竞争激烈或锁争用严重,不是单纯看总数,要看单位时间增量用 std::this_thread::sleep_for 控制采样间隔会导致误差累积——系统调度延迟、时钟精度、以及 sleep 实际耗时都不可控。100ms 设定下,实测间隔可能在 95–115ms 波动,对高频波动分析失真。
正确做法是记录上一次采样时间戳(clock_gettime(CLOCK_MONOTONIC, &ts)),每次循环计算应等待时长 = 上次时间 + 采样周期 - 当前时间,再传给 nanosleep。这样能收敛误差,长期保持平均周期准确。
std::chrono::steady_clock ——虽然单调,但 sleep_for 底层仍走系统调用,无法补偿调度延迟CLOCK_MONOTONIC 依然有效,但利用率计算需额外减去 cgroup throttling 时间(查 /sys/fs/cgroup/cpu/xxx/cpu.stat 的 nr_throttled)C++ 没有跨平台方案能同时满足这三个指标的精度要求,Linux 下这套基于 procfs/sysfs 的组合是事实标准。Windows 需用 PdhAddCounter + PdhCollectQueryData,但 per-core 频率和 voluntary/nonvoluntary 切换无法分离,得接受折中。