Linux下C++程序无法获取线程CPU时间片配额，因CFS调度器基于vruntime和权重动态调度，已弃用固定时间片；sched_rr_get_interval()仅适用于SCHED_RR实时策略，getrusage()返回已消耗CPU时间总量，二者均不反映配额。
Linux 下 C++ 程序无法直接“获取线程的 CPU 时间片配额”——因为现代调度器（如 CFS）根本**不按固定时间片分配 CPU**，而是基于虚拟运行时间（vruntime）和权重（se.weight）动态调度。所谓“时间片”是历史概念（如 O(1) 调度器），CFS 已弃用它。
为什么 sched_rr_get_interval() 和 getrusage() 都不适用
这两个函数常被误认为能查“配额”，但实际用途完全不符：
-
sched_rr_get_interval()仅对SCHED_RR实时策略有意义，返回的是该策略下**单次轮转的最大执行时长**（毫秒级），与普通线程（SCHED_OTHER）无关；调用它对默认调度策略会返回 0 或 -1 +EINVAL -
getrusage(RUSAGE_THREAD, &ru)中的ru.ru_stime/ru.ru_utime是**已消耗的 CPU 时间总量**（wall-clock 累计值），不是剩余配额，也无法预测下次调度行为 - 试图用
/proc/[pid]/sched解析se.vruntime或se.sum_exec_runtime只能得到快照，不能推导“配额”——CFS 没有配额概念，只有当前负载下的公平性保障
真正可监控的调度相关指标：从 /proc/[tid]/stat 和 cgroup v2 入手
若目标是感知线程是否被节流、是否频繁失调度、或是否受 cgroup 限制，应转向以下真实可观测字段：
- 读取
/proc/self/stat（或/proc/[tid]/stat）第 14 字段（utime）和第 15 字段（stime）：它们是该线程自启动以来在用户态/内核态消耗的**jiffies 数**，两次采样差值可换算为毫秒级 CPU 时间增量 - 检查
/proc/[tid]/status中的voluntary_ctxt_switches和nonvoluntary_ctxt_switches：后者大幅增长说明线程频繁因时间片耗尽或资源等待被抢占，是调度压力的直接信号 - 若线程运行在 cgroup v2 的
cpu.max限制下（如10000 100000表示 10ms/100ms），可通过读取/sys/fs/cgroup/[path]/cpu.stat中的nr_throttled和throttled_usec判断是否已被节流
示例：监控自身线程每 100ms 的用户态 CPU 增量
立即学习“C++免费学习笔记（深入）”；
#include <fstream>
#include <chrono>
#include <thread>
#include <iostream>
<p>long read_utime() {
std::ifstream f("/proc/self/stat");
long utime = 0;
if (f.is_open()) {
for (int i = 1; i <= 14; ++i) {
long dummy;
if (i == 14) f >> utime;
else f >> dummy;
}
}
return utime;
}</p><p>int main() {
auto last = read_utime();
while (true) {
std::this_thread::sleep_for(std::chrono::milliseconds(100));
auto now = read_utime();
// jiffies → ms: assume USER_HZ = 100 (common on x86_64)
std::cout << "CPU delta (ms): " << (now - last) << "\n";
last = now;
}
}</p>用 perf_event_open() 监控调度事件（需 root 或 perf_events 权限）
这是最贴近“实时调度行为”的方式，能捕获线程被调度入/出 CPU 的精确时刻：
- 使用
PERF_TYPE_SOFTWARE+PERF_COUNT_SW_CONTEXT_SWITCHES可统计切换次数，但无法区分进出 - 更实用的是
PERF_TYPE_TRACEPOINT绑定sched:sched_switch：每次触发时可拿到 prev_pid/next_pid，若 next_pid == 当前线程 tid，即表示“刚被调度上 CPU” - 注意：tracepoint 事件开销显著，长期开启会影响被监控线程自身行为；建议仅用于诊断，而非生产环境持续采集
- 必须通过
perf_event_attr设置sample_type = PERF_SAMPLE_TID | PERF_SAMPLE_TIME才能关联到具体线程和时间戳
CPU 时间片配额是个过时的思维惯性。CFS 的本质是“保证每个任务在一段时间窗口内获得与其权重成比例的 CPU 时间”，而不是发固定票券。真正影响响应的，是 cgroup 限频、系统负载、以及线程自身的阻塞行为——盯着“配额”不如盯住 nonvoluntary_ctxt_switches 和 cpu.stat 中的 throttled 状态。这些字段藏得浅，但解读错一次，就可能把调度延迟归因为“配额用完”，而实际是锁竞争或 I/O 卡住了。
