无法直接获取“当前占用的精确CPU内核时间片”，C++标准库不提供该能力，必须依赖操作系统API；Linux用clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...)获取线程累计CPU时间（纳秒级，含内核态），Windows用GetThreadTimes获取内核+用户态时间（100纳秒单位），二者均返回自启动以来总耗时，非瞬时片长；现代调度器（如Linux CFS、Windows Scheduler）动态分配时间片，不对外暴露固定片长，实践中应通过周期采样计算ΔCPU时间/ΔWall时间来评估真实负载。
无法直接获取“当前占用的精确CPU内核时间片”——C++标准库不提供该能力，必须依赖操作系统API；Linux下用clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...)最接近需求，Windows下用GetThreadTimes，但二者返回的都不是“时间片”，而是累计内核态+用户态CPU时间（纳秒/100纳秒级），且无法反映调度器分配的瞬时片长。
Linux：用clock_gettime获取线程级CPU时间（含内核态）
Linux内核为每个线程维护独立的CPU时间计数器，CLOCK_THREAD_CPUTIME_ID可读取该值，精度通常达纳秒级，且包含线程在内核态执行的时间（如系统调用、中断处理等）。
常见错误是误用CLOCK_PROCESS_CPUTIME_ID——它返回整个进程所有线程的CPU时间总和，无法定位到当前线程的实际消耗。
- 必须在目标线程内调用，跨线程读取无意义
- 需链接
-lrt（部分旧glibc环境需要） - 返回值是自线程启动以来的总CPU时间，不是“当前片剩余多少”
- 示例：
struct timespec ts;<br>if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts) == 0) {<br> uint64_t nanos = ts.tv_sec * 1000000000ULL + ts.tv_nsec;<br>}
Windows：用GetThreadTimes获取内核+用户时间
Windows不暴露调度时间片长度，GetThreadTimes返回的是线程自创建起在内核态和用户态分别消耗的100纳秒单位时间（FILETIME），两者相加即为总CPU时间，与Linux的clock_gettime语义一致。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑是直接把dwCreationTime等字段当CPU时间用——那些是线程生命周期时间戳，和CPU占用无关。
- 传入当前线程句柄：
GetCurrentThread()（注意该句柄需DUPLICATE_SAME_ACCESS权限才能被GetThreadTimes接受，通常直接用即可） - 返回的
lpKernelTime即为内核态CPU时间，单位是100纳秒 - 需手动转换为纳秒：
*(uint64_t*)lpKernelTime * 100 - 不能用于其他进程的线程，除非有
THREAD_QUERY_INFORMATION权限且已打开句柄
为什么你拿不到“当前时间片长度”？
现代操作系统（Linux CFS、Windows Scheduler）基本不固定时间片长度：CFS按权重动态分配虚拟运行时间，Windows使用基于优先级的可变量子（quantum），且会根据线程行为（如是否I/O等待）实时调整。所谓“时间片”是调度器内部瞬时决策结果，未对外暴露接口。
监控实践中真正可用的是“单位时间内的CPU时间增量”，例如每100ms采样一次clock_gettime，差值即为该周期内真实占用的CPU时间——这才是压测、限频、异常检测的可靠依据。
- 试图轮询
sched_rr_get_interval或GetProcessTimes来推断片长，结果必然是误导性的 - 内核模块或eBPF能跟踪调度事件（如
sched_switch），但已超出用户态C++范畴 - 高精度采样本身会引入干扰：频繁调用
clock_gettime可能触发VDSO回退到syscall，增加开销
真正要监控CPU资源争用，别纠结“片”，盯住“两次采样间的CPU时间差 / 采样间隔”这个比值——它直接反映线程实际负载密度，且跨平台语义一致。其余都是调度器黑盒里的幻影。
