Linux下clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...)获取的是线程自启动以来实际占用的CPU时间总和（纳秒级），非剩余时间片额度；Windows需用GetThreadTimes()获取内核态与用户态时间总和（单位100纳秒），二者均只提供累计值，不暴露调度器剩余配额。
Linux 下用 clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) 获取线程已消耗的 CPU 时间
严格来说，C++ 标准库不提供“CPU 时间切片额度”这种调度层面的实时配额查询接口——操作系统不暴露剩余配额，只允许读取已用时间。真正能拿到的是该线程自启动以来**实际占用的 CPU 时间总和**（即线程级的 CPU_TIME），单位是纳秒。
在 Linux 上，这是最接近你需求的可行方案：
-
CLOCK_THREAD_CPUTIME_ID是 POSIX 线程专属时钟，返回值仅计入当前线程执行时间，不受睡眠、阻塞影响 - 需链接
-lrt（glibc 要求），且内核需支持CONFIG_POSIX_TIMERS（现代发行版默认开启） - 调用前确保线程已进入可调度状态（例如主线程或
std::thread启动后）
<pre class="brush:php;toolbar:false;">#include <time.h>
#include <stdio.h>
<p>struct timespec ts;
if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts) == 0) {
long nanos = ts.tv_sec * 1000000000L + ts.tv_nsec;
printf("Thread CPU time: %ld ns\n", nanos);
}</p>Windows 上用 GetThreadTimes() 替代
Windows 没有等价的 CLOCK_THREAD_CPUTIME_ID，但 GetThreadTimes() 可以获取线程的内核态 + 用户态 CPU 时间总和（单位为 100 纳秒）。
注意几个关键点：
立即学习“C++免费学习笔记（深入）”；
windows-shell
下载
Windows 命令行编码与兼容规范。涵盖 GBK/UTF-8 编码、PowerShell/pwsh 互操作、Python/Node.js、Git 配置及代码生成规则。适用于 Windows 10/11 + MSYS2/Git Bash 环境下的所有命令行操作。
- 必须传入目标线程的
HANDLE，不能用GetCurrentThread()返回的伪句柄（它不保证稳定），应使用OpenThread(THREAD_QUERY_INFORMATION, ...)或从std::thread::native_handle()转换 - 返回的
FILETIME是 64 位整数，需转为纳秒再合并：(kernel + user) * 100 - 该值同样不含“剩余配额”，只是历史累计值；Windows 调度器也不对外暴露时间片余额
无法直接查“剩余时间片额度”的原因
这不是 C++ 或 API 的限制，而是操作系统调度器的设计选择：
- Linux CFS 调度器按虚拟运行时间
vruntime调度，没有固定“时间片”概念；所谓 10ms 片只是典型值，实际取决于sysctl kernel.sched_latency_ns和就绪队列长度 - 即使启用了 SCHED_FIFO/SCHED_RR，
sched_rr_get_interval()只能返回理论时间片长度（如 100ms），但无法告诉你当前周期还剩多少——内核不维护这个状态 - 所有主流 OS 都把调度决策视为黑盒，应用层只能观测已用时间，不能预测或查询剩余配额
想监控线程是否被频繁抢占？试试 /proc/[pid]/stat 的 utime 和 stime
如果你的真实意图是判断线程是否因时间片耗尽而被调度器强制切换，可以定期读取 /proc/self/stat 中的第 14 字段（utime）和第 15 字段（stime），它们分别是用户态和内核态的 jiffies 累计值。
差值变化速率突然变缓，可能意味着线程进入等待或被高优先级任务抢占；但要注意：
- jiffies 分辨率低（通常 10ms），不适合高频采样
- 该文件每行只有一组快照，需自己做两次读取+差分计算
- 跨进程读取需权限，且
/proc/[pid]/stat中的字段顺序依赖内核版本（建议用libprocps封装）
真要定位调度延迟问题，perf sched record -g 或 trace-cmd record -e sched:sched_switch 这类内核跟踪工具比轮询更可靠。
