Linux下读取/proc/[pid]/status可获取精确的自愿和非自愿上下文切换次数，但多线程程序需遍历/proc/[pid]/task/[tid]/status汇总各线程值；getrusage(RUSAGE_THREAD)虽快但非POSIX标准且不支持musl。
Linux 下读取 /proc/[pid]/status 获取线程级上下文切换统计
Linux 内核从 2.6.23 起在 /proc/[pid]/status 中暴露了 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches 两个字段，它们分别代表自愿（如等待 I/O、锁）和非自愿（如时间片耗尽被抢占）的上下文切换次数。这是目前最轻量、最精确的进程级统计来源，无需 root 权限，也不依赖 perf 或 eBPF。
实操要点：
- 必须读取目标进程每个线程的
/proc/[pid]/task/[tid]/status—— 因为/proc/[pid]/status只显示主线程（即pid == tid）的值，多线程程序的总切换次数是所有线程之和 - 字段解析需逐行扫描，不能靠固定偏移；匹配正则
^voluntary_ctxt_switches:[[:space:]]+(\d+)更可靠 - 注意
/proc/[pid]/task/目录可能在读取过程中动态变化（线程创建/退出），建议先readdir()收集全部tid字符串，再逐个打开status，避免ENOENT - 两次采样间隔建议 ≥100ms，否则
nonvoluntary_ctxt_switches可能为 0 —— 时间片调度精度通常为 1–15ms，太短抓不到抢占事件
用 getrusage(RUSAGE_THREAD) 获取当前线程的自愿切换数（仅限本线程）
getrusage(RUSAGE_THREAD, &ru) 在较新 glibc（≥2.27）中会填充 ru.ru_nvcsw（自愿）和 ru.ru_nivcsw（非自愿），但仅反映调用时刻该线程自启动以来的累计值，且 RUSAGE_THREAD 并非 POSIX 标准，glibc 以外的实现（如 musl）不支持。
适用场景与限制：
立即学习“C++免费学习笔记（深入）”；
- 适合监控单线程程序或只关心主线程行为的场景；多线程下无法汇总，因为
ru_nvcsw不包含其他线程数据 - 返回值是整型，无溢出检查；若进程运行超数天且频繁切换，
ru_nivcsw可能溢出（32 位系统上约 42 亿次后归零） - 该接口开销极低（内核态直接拷贝 task_struct 字段），比反复读 proc 文件快一个数量级，适合高频采样（如每 10ms 一次）
- 注意：
getrusage(RUSAGE_SELF)返回的是进程所有线程的总和（Linux 实现），但标准未保证此行为，不可依赖
警惕 /proc/[pid]/stat 的 cutime/cstime 误用
不少文章把 /proc/[pid]/stat 第 15–16 项（cutime 和 cstime）当作上下文切换指标，这是典型误解——它们实际表示子进程（已终止）消耗的用户态/内核态 CPU 时间（单位：clock ticks），与上下文切换完全无关。
真正相关的字段是第 42 项（num_threads）、第 43 项（itrealvalue）之后的扩展字段，但 Linux 内核并未在 stat 中导出切换计数；强行按位置读取会导致越界或解析错误。
常见错误现象：
- 用 Python 的
psutil.Process().cpu_times().children_user拿到的值，本质就是cutime，不是切换次数 - 写脚本按空格分割
/proc/[pid]/stat并取第 42 项，结果得到的是线程数而非切换数，造成监控曲线完全失真 - 误将
cstime增长速率当作调度压力指标，实际上它只反映子进程历史开销，对当前进程无实时意义
C++ 封装采样逻辑时必须处理的三个边界条件
直接裸读 proc 文件或调用 getrusage 容易在线上环境崩溃或返回脏数据。关键防御点：
- proc 文件路径拼接前，必须用
std::to_string(pid)而非std::sprintf或字符串流 —— 若pid为负（如传入错误句柄），前者抛异常，后者生成非法路径如/proc/-1/status，导致open()返回ENOENT而非更明确的错误 - 读
/proc/[pid]/task/目录时，readdir()返回的d_name可能含非数字字符（如.、..、status），必须用std::all_of(d_name, ::isdigit)过滤，否则open("/proc/123/task/status/status")会静默失败 - 两次采样间若进程退出，
/proc/[pid]目录消失，stat()返回ESRCH；此时应立即停止该 PID 的监控任务，而不是重试或忽略 —— 否则后续所有读取都无效
真实生产环境中，nonvoluntary_ctxt_switches 突增往往意味着 CPU 资源争抢或调度延迟，但它的数值本身没有绝对阈值；必须结合同进程的 voluntary_ctxt_switches 比例、CPU 利用率、以及线程栈深度一起看，单独看一个数容易误判。
