直接读/proc/[pid]/stat的utime和stime不够用，因二者是累计时钟周期而非百分比，需两次采样差值并归一化到系统总可用时间片（Δutime+Δstime)/(Δtotal_jiffies×num_cpus)×100%。
为什么直接读 /proc/[pid]/stat 的 utime 和 stime 不够用
因为这两个值是进程累计消耗的用户态/内核态时钟周期（单位是 CLK_TCK，通常是 100），不是百分比。想转成 CPU 利用率，必须做时间窗口内的差值计算，并归一化到系统总可用时间片上。跳过这一步直接相减再除以采样间隔，结果会严重失真——尤其在多核机器上，100% 可能被算成 400%。
核心公式：两步差值 + 归一化
真实 CPU 使用率 = (Δutime + Δstime) / (Δtotal_jiffies * num_cpus) × 100%
-
Δutime、Δstime：两次采样间/proc/[pid]/stat第 14、15 字段的差值 -
Δtotal_jiffies：两次采样时间间隔（秒）×sysconf(_SC_CLK_TCK)，即该时间段内系统理论上可分配的最大时间片数 -
num_cpus：用sysconf(_SC_NPROCESSORS_ONLN)获取在线 CPU 核心数，不能硬编码为 1 或 4
注意：/proc/[pid]/stat 中第 22 字段 cutime/cstime 是子进程数据，实时监控单进程时不要混入。
代码里怎么安全读取并解析 /proc/[pid]/stat
字段数量不固定（因命令行参数含空格），不能靠 sscanf 简单按位置取。必须逐字符跳过前 13 个字段（用空格/制表符分隔），再读第 14、15 字段：
char path[64];
snprintf(path, sizeof(path), "/proc/%d/stat", pid);
FILE* f = fopen(path, "r");
if (!f) return -1;
char buf[4096];
if (!fgets(buf, sizeof(buf), f)) { fclose(f); return -1; }
fclose(f);
<p>// 跳过前 13 个字段（从第 1 字段开始数，第 14 是 utime）
char* p = buf;
for (int i = 0; i </p>
常见错误：用 strtok 处理含括号的第 2 字段（进程名），会导致字段错位；或没检查 fgets 是否截断，导致后续解析全偏移。
两次采样之间必须 sleep 精确间隔吗？
不必。关键不是“睡够 X 秒”，而是记录**真实经过的 wall-clock 时间**（用 clock_gettime(CLOCK_MONOTONIC, ...)），再换算成对应 jiffies 数。sleep 本身有调度延迟，实际间隔可能偏差几十毫秒——这对 1 秒采样影响小，但对 100ms 采样就是致命误差。
- 第一次采样后调用
clock_gettime记下t0 - 第二次采样后再记下
t1，用(t1.tv_sec - t0.tv_sec) * CLOCKS_PER_SEC + (t1.tv_nsec - t0.tv_nsec) / 1e9得真实秒数 - 再乘
sysconf(_SC_CLK_TCK)得Δtotal_jiffies
忽略这个细节，高负载下测出的利用率会系统性偏低——因为进程在 sleep 期间也被计入了“系统总可用时间”。
实际部署时最容易被绕过去的是 num_cpus 动态变化（热插拔 CPU、容器限制 cgroups.cpu.cfs_quota_us）。如果进程长期运行，建议每次采样都重查 sysconf(_SC_NPROCESSORS_ONLN)，而不是只查一次。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
