Linux下clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)返回用户态与内核态CPU时间总和，无法直接获取纯内核态时间；需解析/proc/self/stat第15字段stime并结合sysconf(_SC_CLK_TCK)换算。
Linux下用clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)获取内核态CPU时间
Linux提供CLOCK_PROCESS_CPUTIME_ID时钟，它返回当前进程自启动以来的**总CPU时间（用户态 + 内核态之和）**，但不单独拆分内核态。要拿到纯内核态时间，必须配合/proc/[pid]/stat解析——这是唯一可靠、无需特权、且能分离内核态的方案。
关键点：clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)返回的是wall-clock等效的CPU消耗总和，不是内核态专用值；别误以为它能直接拆出stime。
-
/proc/self/stat第14个字段（索引从1开始）是utime（用户态jiffies），第15个是stime（内核态jiffies） - jiffies需转换为秒：除以
sysconf(_SC_CLK_TCK)（通常是100） - 该文件每行刷新一次，读取开销极低，适合高频采样（如每100ms）
解析/proc/self/stat提取stime的C++实操
直接fopen("/proc/self/stat", "r")并按空格/制表符分割容易出错——字段含空格（如进程名在括号里），必须按“第1~13个字段跳过、第14个起计数”方式定位。
推荐用std::ifstream逐字符读取+状态机，或更稳妥地用std::stringstream配合ignore()跳过前13个字段：
立即学习“C++免费学习笔记（深入）”；
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
long long get_kernel_cpu_time_ms() {
std::ifstream f("/proc/self/stat");
if (!f.is_open()) return -1;
long long utime, stime;
// 跳过前13个字段（含可能含空格的comm字段）
for (int i = 0; i < 13; ++i) f.ignore(std::numeric_limits<std::streamsize>::max(), ' ');
f >> utime >> stime; // 第14、15个字段
long clk_tck = sysconf(_SC_CLK_TCK);
return stime * 1000 / clk_tck; // 转毫秒
}
注意：stime单位是jiffies，不是微秒；不同内核版本字段位置一致，但务必验证man 5 proc确认第15项定义未变。
为什么不用getrusage(RUSAGE_SELF, ...)
getrusage返回的ru_stime.tv_sec/tv_usec确实是内核态时间，但它**只在调用时刻快照，无法反映趋势**——两次调用之间若进程被调度器抢占、休眠或切换CPU核心，差值会丢失精度；尤其在多核系统上，ru_stime更新非原子，高频采样可能得到乱序值。
-
getrusage适合单次诊断，不适合趋势监控 -
/proc/self/stat由内核实时更新，每次读取都是最新原子快照 - glibc对
getrusage有缓存优化，实际读取可能延迟，而/proc是直通内核数据结构
采样频率与精度陷阱
内核每HZ（通常100Hz）更新stime，意味着最小分辨率为10ms。如果每1ms采样一次，90%的读数会重复——不仅浪费IO，还让趋势图出现平台效应。
- 建议采样间隔 ≥ 50ms；若需更高精度，需改用eBPF（如
bpf_get_current_task()读取task_struct->stime），但复杂度陡增 - 不要用
std::chrono::steady_clock对齐采样时间点——stime本身不连续，对齐反而放大抖动 - 监控长期趋势时，记录绝对值而非差值；差值易受进程短暂挂起影响（如等待锁），导致负增量（虽然罕见但可能）
真正难的是把离散jiffies映射到真实时间轴——内核不保证stime严格单调，尤其在CPU频率缩放或虚拟化环境下，得靠外部时钟锚定，而不是相信两次读数的差值一定正比于真实流逝时间。
