Linux用clock_gettime(CLOCK_PROCESS_CPUTIME_ID)获取纳秒级进程CPU时间（用户态+内核态），不包含子进程；Windows用GetProcessTimes()精度仅约15.6ms且易抖动；跨平台统计口径不同，不可直接对比绝对值。
Linux 下用 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) 获取进程精确 CPU 时间
这是最直接、开销最小的方案，返回的是进程自启动以来在用户态 + 内核态实际消耗的 CPU 时间（非 wall-clock），精度通常达纳秒级。注意它不包含子进程时间，只统计当前进程。
常见错误是误用 CLOCK_MONOTONIC 或 CLOCK_REALTIME —— 它们返回的是挂钟时间，受系统休眠、NTP 调整影响，完全不能反映 CPU 占用。
实操要点：
- 需定义
_GNU_SOURCE或_POSIX_C_SOURCE >= 199309L才能使用CLOCK_PROCESS_CPUTIME_ID - 必须检查
clock_gettime()返回值：-1 表示失败（如内核不支持该 clock ID） - 两次调用差值才是“时间段内 CPU 消耗”，建议用
struct timespec手动做减法，避免浮点转换误差
Windows 上用 GetProcessTimes() 替代方案及精度陷阱
Windows 没有等价的纳秒级进程 CPU 时间接口。GetProcessTimes() 返回的是 FILETIME（100 纳秒为单位），但实际分辨率取决于系统时钟粒度（通常 15.6ms），且内核会批量更新，导致短时间多次调用结果不变。
立即学习“C++免费学习笔记（深入）”；
这意味着：如果你每 10ms 调用一次，很可能连续几十次读到同一个值，算出的“CPU 使用率”会剧烈抖动甚至为 0。
能做的妥协：
- 改用 500ms 以上采样间隔，降低抖动影响
- 结合
QueryPerformanceCounter()做 wall-clock 对齐，至少能判断是否真卡死 - 若需高频监控，必须走 ETW（Event Tracing for Windows）——但那是驱动级埋点，不属于进程自身可调用 API
跨平台封装要注意的内核统计口径差异
Linux 的 CLOCK_PROCESS_CPUTIME_ID 和 Windows 的 GetProcessTimes() 都包含用户态 + 内核态时间，但“内核态”范围不同：Linux 统计所有系统调用陷入内核的时间；Windows 不统计某些内核线程代为执行的后台工作（如 APC 处理、延迟过程调用 DPC）。
这会导致同一段代码在两平台上报的 CPU 时间不一致，尤其在大量小文件 I/O 或频繁信号处理时更明显。
关键提醒：
- 不要直接对比两平台的绝对值，只用于同平台趋势分析
- 若需归一化，建议以“单位 wall-clock 时间内的 CPU 时间占比”为指标（即传统 CPU 利用率），而非原始纳秒数
- glibc 2.17+ 的
clock_gettime在容器中可能受 cgroup cpu.max 限频影响，返回时间会变慢——这不是 bug，是内核主动 throttle 的体现
为什么 /proc/[pid]/stat 的 utime/stime 不推荐用于实时监控
虽然 /proc/[pid]/stat 第 14、15 字段（utime、stime）也表示用户/内核态 jiffies，但它有三个硬伤：
- 每次读取需打开文件、解析文本，IO 开销远高于系统调用
- 字段位置易受内核版本变动影响（比如新增字段会整体右移）
- jiffies 是固定频率计数（通常 100Hz 或 250Hz），精度上限就是 10ms 级，无法满足“精确时间片”需求
它适合离线分析或低频巡检，但写进高频采样循环里，反而会成为性能瓶颈本身。
真正难的不是拿到数字，而是理解每个数字背后内核到底统计了什么、没统计什么。同一行代码，在 cgroup v1/v2、容器、WSL、hyper-v 里跑出来的时间都可能差 10% 以上——别怪工具不准，先看清楚你在量哪一层的“CPU”。
