Linux中读取/proc/[pid]/status可获进程累计上下文切换数，voluntary_ctxt_switches和nonvoluntary_ctxt_switches为只读64位计数器，需解析对应行数字；getrusage()仅适用于当前进程自身统计，不支持跨进程查询。
Linux下读取/proc/[pid]/status里的上下文切换计数
Linux内核在/proc/[pid]/status中暴露了进程的累计上下文切换次数，关键字段是voluntary_ctxt_switches和nonvoluntary_ctxt_switches。这两个值从进程创建起累加，只读、无需特权（只要能访问该进程的proc目录）。注意：它们不是实时采样值，也不反映瞬时频率。
实操建议：
- 用
std::ifstream打开/proc/<var>pid</var>/status，逐行读取并匹配以voluntary_ctxt_switches:和nonvoluntary_ctxt_switches:开头的行 - 解析冒号后空格后的数字，推荐用
std::stoull()避免溢出（64位计数器） - 若
open()失败，常见原因是进程已退出，或当前用户无权限（如读其他用户进程需root） - 不要依赖
/proc/[pid]/stat——它不包含上下文切换字段，容易白忙一场
用getrusage()获取当前进程的自愿切换统计
getrusage(RUSAGE_SELF, &ru)能拿到当前进程的ru_nvcsw（非自愿切换）和ru_nivcsw（自愿切换）——但仅限调用方自身，且只统计到调用时刻为止。它不支持指定任意PID，也不能跨进程查询。
实操建议：
- 头文件必须包含
<sys></sys>，链接时无需额外库 - 返回值为0表示成功；-1表示失败，此时检查
errno（如EINVAL说明who参数非法） -
ru_nvcsw和ru_nivcsw是long类型，在glibc中通常为64位，但严格起见应使用static_cast<uint64_t></uint64_t>转存 - 该接口无法获取子进程或其它进程数据，别试图传入别的PID——
RUSAGE_CHILDREN只对已wait过的子进程有效
避免误把线程切换当进程切换
Linux中“进程上下文切换”实际指task切换，而线程（轻量级进程）也计入其中。如果你用ps -eLf看到大量LWP，它们各自的切换都会被单独统计在各自/proc/[tid]/status里，但/proc/[pid]/status显示的是整个线程组（TGID）的汇总值。
实操建议：
- 确认你要的是整个进程（TGID）总量，还是单个线程（TID）——前者看
/proc/[pid]/status，后者看/proc/[tid]/status - 不要用
pthread_self()得到的ID直接拼路径：它返回的是用户态线程ID，而/proc/[tid]需要内核线程ID（可通过syscall(SYS_gettid)获取） - 如果目标进程多线程，
nonvoluntary_ctxt_switches显著高于voluntary_ctxt_switches，大概率是锁竞争或CPU资源争抢，不是代码写法问题
注意/proc文件系统的时间窗口与精度
/proc/[pid]/status是内核动态生成的快照，两次读取之间可能已有成百上千次切换发生。它不提供时间戳，也没有增量接口——你只能靠自己记录前后差值来估算速率。
实操建议：
- 高频率轮询（如每10ms）不仅无效，还会因procfs开销拖慢目标进程；建议间隔不低于100ms
- 差值计算时务必检查前后两次读取是否对应同一进程（PID复用风险），可用
stat("/proc/[pid]", &sb)比对st_ino或st_mtime辅助判断 - 不要期望毫秒级精度：内核更新这些计数器本身就有延迟，且
read()系统调用耗时远大于计数器更新粒度
真正难的不是读哪个文件或调哪个函数，而是理解你拿到的数字到底代表什么——它是累积值、不可回滚、不带时间维度，而且混着线程和中断上下文。想靠它做性能归因，得先确认采集点够稳、时间窗够合理、对比基线够干净。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
