Linux下最可靠方式是读取/proc/self/stat第15字段stime（内核态jiffies），除以sysconf(_SC_CLK_TCK)换算为秒；该值仅反映当前进程纯内核态CPU时间，不含子进程，且需正确解析字段避免comm含空格导致错位。
Linux下用clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)获取内核态CPU时间
直接读取进程累计的内核态CPU时间，最可靠的方式是调用clock_gettime并传入CLOCK_PROCESS_CPUTIME_ID。这个时钟返回的是当前进程在用户态 + 内核态总共消耗的CPU时间（即“进程CPU时间”），但注意：它不单独拆分用户态和内核态——Linux内核没有提供标准POSIX接口直接分离二者。
如果你看到某些资料提到CLOCK_THREAD_CPUTIME_ID或/proc/[pid]/stat中的utime/stime字段，那是更接近的方案，但需手动解析：
-
/proc/self/stat第14字段（utime）是用户态jiffies，第15字段（stime）是内核态jiffies，单位是HZ（通常为100或1000），需除以sysconf(_SC_CLK_TCK)转为秒 - 必须用
std::ifstream按空格/制表符分割读取，不能依赖固定列宽——comm字段含空格，会导致错位 - 读取
/proc/self/stat是轻量级系统调用，但频繁调用（如每毫秒）会带来I/O开销，建议采样间隔≥10ms
从/proc/self/stat提取stime并转换为秒
这是目前C++中唯一能稳定拿到纯内核态CPU时间的方法。关键不是“怎么读文件”，而是“怎么正确解析字段”：
#include <fstream>
#include <vector>
#include <string>
#include <unistd.h>
double get_kernel_cpu_time_seconds() {
std::ifstream proc_stat("/proc/self/stat");
std::vector<std::string> fields;
std::string field;
while (proc_stat >> field) fields.push_back(field);
if (fields.size() < 15) return 0.0;
long stime = std::stol(fields[14]); // 注意：索引从0开始，第15个字段是stime
long clk_tck = sysconf(_SC_CLK_TCK);
return static_cast<double>(stime) / clk_tck;
}
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
- 字段索引错误：很多文档写“第14个字段是stime”，但实际是第15个（因第一个字段是pid，且
comm字段被括号包围、可能含空格，导致>>操作符跳过多个token） - 没检查
fields.size()就访问fields[14]，程序崩溃 - 忽略
sysconf(_SC_CLK_TCK)而硬编码除以100，导致在某些容器或新内核上结果偏差10倍
多次采样做趋势分析时要注意时间精度与抖动
单纯获取单次stime没意义，趋势需要至少两次测量。但两次读取之间，进程可能被调度出去、发生中断或软中断处理，这些都会计入stime——所以观测到的“增长”未必反映你代码的真实内核开销。
实操建议：
- 每次采样间隔设为50–200ms，太短则
stime增量常为0（尤其低负载时）；太长则丢失细节 - 避免在信号处理函数、锁竞争激烈路径中高频采样，否则自身测量行为会放大内核态时间（比如触发更多上下文切换）
- 如果想排除中断影响，可对比
/proc/stat中cpu行的intr列变化，但这已超出单进程范畴
Windows下没有等价的轻量接口，别硬搬GetProcessTimes
GetProcessTimes返回的KernelTime字段看似对应，但它包含线程在内核中执行的所有时间——包括等待I/O完成、等待互斥体、甚至部分驱动操作。而且Windows没有/proc那样的实时进程统计视图，采样延迟更高（通常≥15ms）。
跨平台代码若真需要趋势，建议：
- Linux走
/proc/self/stat路径，Windows走GetProcessTimes+ 高精度计时器对齐时间戳 - 不要试图把两者数值直接对比，它们统计口径不同：Linux的
stime只计实际执行的内核代码时间，Windows的KernelTime包含更多等待态时间 - 若项目允许依赖第三方库，
libstatgrab或gperftools的CPUProfiler会更鲁棒，但引入了额外构建复杂度
真正难的不是读一个数字，而是判断这个数字里有多少是你触发的系统调用、有多少是调度器或中断处理的“噪音”。采样点选在哪，比怎么读更重要。
