应使用clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &)获取进程级精确CPU时间，它返回用户态与内核态实际执行时间之和，纳秒级精度，需链接-lrt，两次采样差值才反映真实CPU开销。
Linux 下用 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) 获取进程精确 CPU 时间
这是最直接、开销最小的方式，返回的是进程自启动以来在用户态 + 内核态实际消耗的 CPU 时间（非 wall-clock），精度可达纳秒级。它不依赖 /proc 文件系统解析，也不受调度延迟干扰。
注意：CLOCK_PROCESS_CPUTIME_ID 在 Linux 上从 2.6.12 开始支持，glibc 2.4+ 可用；必须链接 -lrt（部分旧构建环境需显式指定）。
- 调用前需声明
struct timespec ts，传入地址即可，无需初始化 - 返回值为
0表示成功，-1 表示失败（errno可查具体原因，常见是未定义宏或内核不支持） - 两次调用差值即为该时间段内真实 CPU 占用时长，可用于计算 CPU 使用率（需配合
getrusage()或/proc/self/stat获取总运行时间作分母）
#include <time.h>
#include <stdio.h>
<p>struct timespec ts;
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) == 0) {
long long ns = ts.tv_sec * 1000000000LL + ts.tv_nsec;
printf("CPU time: %lld ns\n", ns);
}
为什么不用 getrusage(RUSAGE_SELF, ...)？
getrusage 返回的 ru_utime 和 ru_stime 是微秒精度，且在某些内核版本或容器环境中会因 cgroup 限制、tickless 模式导致统计滞后或截断（例如始终显示 0 或固定值）。它本质依赖内核的 rusage 更新机制，不是实时采样。
- 适用于粗略估算或兼容老系统，但无法满足“精确时间片”需求
-
ru_stime确实反映内核态时间，但和clock_gettime的CLOCK_PROCESS_CPUTIME_ID并不完全等价：前者含部分系统调用等待时间（如阻塞 I/O），后者只计真正执行的 CPU 周期 - 在启用了
CONFIG_TASK_DELAY_ACCT的内核上，getrusage才更可靠；默认发行版不一定开启
监控内核空间时间单独拆分：必须读 /proc/self/stat 的第 14、15 字段
如果真要区分用户态 vs 内核态的精确时间（单位：jiffies），clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) 给的是总和，而 /proc/self/stat 第 14 字段（utime）和第 15 字段（stime）分别对应用户态和内核态的 jiffies 数。这是目前唯一能稳定获取内核空间独立耗时的用户态接口。
立即学习“C++免费学习笔记（深入）”；
- jiffies 需换算成秒：除以
sysconf(_SC_CLK_TCK)（通常为 100），不是 HZ 宏——后者可能被编译时覆盖，sysconf才是运行时真实值 - 字段顺序严格，空格分隔，第 1 个是 pid，第 2 个是 comm，中间有括号，解析时务必跳过第 2 字段的右括号再数字段（常见错误是把 comm 当成第 2 字段后直接数，导致错位）
- 该文件每行只有一条记录，但频繁读取有性能开销（每次触发 procfs inode 查找），建议缓存
sysconf(_SC_CLK_TCK)结果，避免重复调用
容易被忽略的关键点
很多人以为 clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) 能替代进程级统计，但它只返回当前线程的 CPU 时间，多线程程序中所有线程的时间不会自动累加；而 CLOCK_PROCESS_CPUTIME_ID 是全进程（所有线程）总和。
- 容器环境下（如 Docker、Kubernetes），cgroup v2 默认启用
cpu.stat，但那是调度器层面的统计，不含内核函数执行细节，也不能反推单个进程的内核态时间 - perf_event_open 可以抓内核栈，但属于采样而非精确累计，且需要 CAP_SYS_ADMIN 权限，不适合常规监控
- 如果你看到的
stime增长远快于预期，检查是否在做大量系统调用（如频繁read()/write()小数据块），这会显著抬高内核态时间
