如何通过调度器策略实战获取并展示线程CPU时间片配额？

本文共计1051个文字，预计阅读时间需要5分钟。

C++标准库不提供CPU时间片配额这一概念——这是调度器内部的动态决策结果，用户级程序无法直接访问。但你可以通过以下方式获取接近已使用配额的值：

关键点：CLOCK_THREAD_CPUTIME_ID是POSIX线程级时钟，只在Linux和部分类Unix系统支持，Windows不可用；需链接-lrt（某些旧glibc环境）。

• 必须在目标线程内调用，跨线程读不到对方的CLOCK_THREAD_CPUTIME_ID
• 返回的是struct timespec，含秒+纳秒字段，别直接当整数打印
• 两次调用差值才是“这段代码跑了多少CPU时间”，单次值本身意义不大

#include <time.h> #include <iostream> struct timespec ts; if (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts) == 0) { std::cout << "CPU time: " << ts.tv_sec << "." << ts.tv_nsec << "s\n"; }

用sched_getscheduler()和sched_getparam()查线程调度策略与优先级

时间片配额由调度器策略（SCHED_FIFO、SCHED_RR、SCHED_OTHER）和nice值共同影响，但Linux的CFS（SCHED_OTHER默认）根本不固定分配时间片，而是基于虚拟运行时间动态调度。所以“配额”在这里是统计意义上的平均值，不是硬限制。

想看当前线程被设了什么策略和参数，得组合两个系统调用：

立即学习“C++免费学习笔记（深入）”；

• sched_getscheduler(0)：传0表示查当前线程，返回SCHED_OTHER/SCHED_FIFO等宏
• sched_getparam(0, &param)：填入struct sched_param，其中param.sched_priority对SCHED_FIFO/SCHED_RR有效，对SCHED_OTHER恒为0
• 普通用户进程默认是SCHED_OTHER + nice=0，此时sched_priority无意义，别误以为它是“时间片长度”

#include <sched.h> int policy = sched_getscheduler(0); struct sched_param param; sched_getparam(0, &param); std::cout << "Policy: " << policy << ", Priority: " << param.sched_priority << "\n";

为什么getrusage(RUSAGE_SELF, ...)里的ru_stime/ru_utime不够准

getrusage返回的ru_utime（用户态时间）和ru_stime（内核态时间）是进程级、低精度（通常微秒级）、且只在进程退出或显式调用时更新缓存——它不反映线程粒度，也不保证实时性。在多线程程序里，这些值是所有线程累加的结果，无法分离出单个线程的消耗。

• 如果你在主线程里调用getrusage，看到的是整个进程从启动到此刻的总CPU时间，包括所有已结束线程
• 它不会告诉你当前线程“还剩多少配额”，因为根本不存在这个状态量
• 相比clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...)，精度差1–2个数量级，且无法用于性能热点定位

真正影响“感觉上时间片短”的其实是CFS的sysctl kernel.sched_latency_ns

Linux CFS没有传统意义的时间片，但有个全局调度周期（默认6ms），它会把这周期按权重分给就绪态线程。一个线程能分到多少，取决于task_struct->se.load.weight，而这个权重又由nice值映射而来——所以调setpriority(PRIO_PROCESS, 0, -5)会让线程“抢”到更多CPU时间，但不是固定配额变大，而是调度器给它更高权重。

• 修改/proc/sys/kernel/sched_latency_ns会影响所有CFS任务的调度粒度，但需root权限，生产环境慎改
• 普通应用不该试图“获取配额”，而应关注自身CPU时间增长是否异常（用clock_gettime打点对比）
• 如果你在写实时程序，必须用SCHED_FIFO/SCHED_RR并锁定内存（mlockall），否则即使策略设了，缺页也会导致调度延迟

真正难的不是读哪个值，而是理解“时间片配额”在现代Linux里是个过时的抽象——CFS用的是完全公平调度模型，你看到的每个数字背后都是权重、虚拟时间、红黑树插入位置共同作用的结果。别信文档里“默认100ms时间片”这种说法，那是2.4内核的老黄历。