在Linux环境下，想要精确监控自身进程的CPU资源消耗，往往离不开那几个经典的“文件系统”接口。其中包含几个关键指标：每核CPU占用率、实时主频以及上下文切换的波动。这些数据正是判断程序是否健康、是否存在性能瓶颈的重要依据。下面我们就逐一详细拆解，把每一条都讲清楚。

Linux下通过/proc/stat解析每核CPU占用率

要获取每核CPU占用率，最可靠的方法仍然是直接读取/proc/stat文件。这个文件记录了user、nice、system、idle、iowait、irq、softirq等字段的累计时间，单位是jiffies。需要注意的是，文件的第一行是全局汇总数据，后面跟着的cpu0、cpu1……才对应各个物理核心（当然也包括超线程的逻辑核）。

这里有一个关键点：必须进行两次采样，然后计算差值。例如，间隔100到500毫秒后再读取一次，接着用公式(total - idle) / total * 100.0，才能算出该核心当前的利用率百分比。直接使用单次读取的数据是不行的——那是系统自启动以来的累计值，无法反映实时情况。

几个实践中的细节：

• 记得跳过以cpu开头的全局数据行，只处理cpu0、cpu1这些带数字的行。
• 各字段的顺序是固定的，但不同内核版本可能会新增字段（比如steal、guest）。稳妥的做法是按空格切分后，只取前8个字段，这样能避免越界。
• 解析出来的数值是无符号长整型，用std::stoull()或strtoull()来转换。如果用错了类型，数值溢出成负数，就会很尴尬。

实时主频需查询/sys/devices/system/cpu/cpu*/topology/core_cpus

Linux并没有一个统一的接口来直接查询“当前运行频率”。/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq这个文件，返回的是cpufreq驱动上报的当前频率（单位kHz）。但问题是，这个值可能被缓存、延迟更新，甚至在intel_pstate驱动下直接返回0。遇到这种情况，就只能退而求其次，用scaling_max_freq配合负载来估算。

一个更可靠的做法是结合topology信息。首先读取/sys/devices/system/cpu/cpu0/topology/core_id，将逻辑核分组（例如cpu0和cpu1都属于core 0）。然后，针对每个物理核，取它所有隶属逻辑核的scaling_cur_freq最大值——这个值更接近该物理核的实际运行频率。

这里有几个需要注意的坑：

• 某些ARM平台（比如rk3399），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"的结果——那是系统启动时的估算值，根本不反映实时变化。

上下文切换统计必须使用/proc/PID/status + /proc/PID/stat

进程级的上下文切换次数，隐藏在/proc//status文件的voluntary_ctxt_switches和nonvoluntary_ctxt_switches这两个字段里。前者是进程主动sleep或yield导致的，后者则是被抢占或缺页引发强制调度。但要注意，这些都是累计值，想要看到波动，必须做两次采样，然后求差值。

说起来，/proc//stat文件的第42和43个字段也对应这两个数。但问题在于，字段序号会随着内核版本变动（比如5.10版本之后增加了新字段）。相比之下，status文件的结构更稳定，所以优先使用status文件。

几个实践要点：

• 非root进程无法读取其他进程的/proc//status。因此，监控自身进程的话，直接使用getpid()即可。要进行跨进程监控，就需要提升权限。
• 采样间隔不能太短，比如2毫秒，那样会丢失毛刺波动。建议100到200毫秒的间隔比较合适。
• nonvoluntary切换次数大量增加，通常意味着CPU竞争激烈或者锁争用严重。不要只看总数，关键要看单位时间内的增量。

不要用std::this_thread::sleep_for做定时采样

使用std::this_thread::sleep_for来控制采样间隔，会导致误差累积。系统调度延迟、时钟精度以及sleep实际耗时，这些因素都不可控。设定100毫秒的间隔，实际测量下来，可能在95到115毫秒之间波动。对于高频波动分析来说，这种误差足以让结果失真。

正确的做法，是记录下上一次采样的时间戳（使用clock_gettime(CLOCK_MONOTONIC, &ts)）。然后，每次循环时，计算应该等待的时间 = 上次采样时间 + 采样周期 - 当前时间，再把这个值传给nanosleep。这样能够收敛误差，长期保持平均周期的准确性。

其他需要注意的：

• 不要使用std::chrono::steady_clock。虽然它本身是单调的，但sleep_for底层仍然走系统调用，无法补偿调度延迟。
• 如果目标是每秒10帧（100ms间隔），连续采样10次后，如果误差超过5ms，就应该重新校准起始时间，而不是硬等下去。
• 在容器环境里，cgroup的cpu quota会干扰真实的CPU时间流逝。虽然CLOCK_MONOTONIC依然有效，但计算CPU利用率时，需要额外减去cgroup throttling的时间（可以查询/sys/fs/cgroup/cpu/xxx/cpu.stat里的nr_throttled字段）。

归根结底，C++本身并没有跨平台方案能够同时满足这三个指标的精度要求。在Linux环境下，这套基于procfs和sysfs的组合，就是事实上的标准。至于Windows平台，就需要使用PdhAddCounter加PdhCollectQueryData了，但per-core频率和voluntary/nonvoluntary切换的分离，在Windows上基本无法实现，只能接受折中方案。