无法直接获取当前线程上下文切换频率，需通过两次读取/proc/self/task/[tid]/status中voluntary_ctxt_switches和nonvoluntary_ctxt_switches字段差分并除以精确时间间隔估算，且必须用syscall(SYS_gettid)获取真实TID、逐行匹配字段开头、stoull提取数值，并处理短生命周期线程导致的ENOENT；getrusage(RUSAGE_THREAD)在多数系统上不可信，/proc/[pid]/stat第42/43字段仅进程级且易解析错误，时间测量须用clock_nanosleep保证精度。
不能直接获取“当前线程的上下文切换频率”，C++ 没有标准 API 返回实时频率值；必须通过两次采样差分再除以时间间隔来估算，且必须明确区分“进程级”和“线程级”数据源——用错层级会导致统计完全失真。
读取 /proc/self/task/[tid]/status 获取线程级精确累计值
这是目前唯一能拿到当前线程真实切换次数的方式，字段 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches 由内核为每个 task 原子维护，无聚合、无延迟。
- 用
syscall(SYS_gettid)获取真实 TID（pthread_self()不行） - 路径必须是
"/proc/self/task/" + std::to_string(tid) + "/status"，/proc/[pid]/status是进程级，会漏掉其他线程的干扰 - 逐行匹配时用
line.rfind("voluntary_ctxt_switches:", 0) == 0，别用find()后截取——开头可能有空格导致匹配失败 - 提取数字时用
std::stoull(line.substr(pos + 1))，冒号后可能有空格，stoull自动跳过前导空白，std::stoi遇空格直接抛异常 - 短生命周期线程（如
std::thread构造后立刻退出）可能导致open()返回ENOENT，需检查 errno 并 fallback
为什么 getrusage(RUSAGE_THREAD, &ru) 在多数场景下不可信
它返回的 ru.ru_nvcsw 和 ru.ru_nivcsw 字段在 glibc 2.31+ 和 kernel 5.4+ 上普遍为 0，不是你代码写错了，而是内核压根没往这个结构体里填线程级数据。
- 该行为未被 POSIX 或内核文档保证，属于未定义实现，不同发行版结果不一致
- 即使某次读到非零值，也不能跨内核版本复现——它依赖未公开的内核补丁状态
-
getrusage(RUSAGE_SELF, &ru)是进程级，对多线程程序毫无意义：主线程切 100 次 + 子线程切 1000 次，你只看到总和，无法定位热点线程 - 返回值为 0 不报错，容易误判为“没切换”，实际是字段未更新
用 /proc/[pid]/stat 第 42/43 字段做高频采样时的陷阱
虽然比 status 解析快，但它是进程级，且字段索引极易出错——尤其新手常把“第 42 个字段”理解成第 42 个字节或从 0 开始计数。
立即学习“C++免费学习笔记（深入）”；
- 字段索引从 1 开始，且第 1 字段是 PID（字符串），第 2 字段是括号包着的 comm 名，数值字段从第 3 个 token 开始算起
- 必须用空格分割全部字段，不能靠
std::string::find找第 n 个空格——comm 名里可能含空格，导致 token 数错 - 解析前先检查总字段数是否 ≥ 43，否则直接跳过，避免
std::stringstream提取失败后用旧值覆盖 - 该方式不支持线程级：
/proc/[pid]/task/[tid]/stat根本不提供这两个字段，想查单个线程只能回退到status
计算频率时最常被忽略的时间精度问题
差分计算频率 = (C₂ − C₁) / (t₂ − t₁)，但 t₂ − t₁ 若用 std::chrono::steady_clock::now() 测得，实际间隔可能远大于预期——尤其当线程被调度器挂起时。
- 不要用
sleep(1)，它不保证休眠整秒，且唤醒后还需重新入队，引入额外延迟 - 推荐用
clock_nanosleep(CLOCK_MONOTONIC, ...)，它基于单调时钟，且可设TIMER_ABSTIME精确控制唤醒点 - 采样间隔不宜低于 100ms：太短则差值常为 0，无法反映趋势；太高则错过突发抖动
- 若发现连续多次采样差值为 0，别急着断言“没切换”，先确认线程是否被绑核（
sched_setaffinity）——跨核迁移本身就会触发切换，但绑定后可能大幅降低
