上下文切换开销无法消除，但可通过控制线程数量、改用协程、避免阻塞调用、绑定cpu亲和性显著降低；std::thread创建/销毁因分配内核栈、注册调度实体等加重间接开销；fiber切换仅12–18ns，比pthread切换快两个数量级。
直接结论：上下文切换开销无法消除，但可通过控制线程数量、改用协程、避免阻塞调用、绑定 CPU 亲和性这四类手段显著压低——尤其在高频交易、实时音视频或微服务网关等对延迟敏感的场景中，单次切换从微秒级降到纳秒级是可行的。
为什么 std::thread 创建/销毁会放大切换开销
每次调用 std::thread 构造函数，操作系统都要分配内核栈（通常 1–8 MB）、注册调度实体、初始化 TLS；销毁时还要回收资源、触发调度器重平衡。这些操作本身不直接等于上下文切换，但会间接抬高后续切换频率和缓存失效概率。
- 线程数超过 CPU 核心数（尤其是 >2×core）后，调度器被迫频繁抢占，
context_switch次数呈非线性增长 - 不同线程访问同一缓存行（false sharing）会导致 L1/L2 缓存反复失效，实际延迟可能比寄存器保存恢复还高
- 默认线程栈过大（Linux 下
pthread默认 8 MB），大量线程驻留内存会挤占 TLB 和页表缓存
boost::context::fiber 切换比 std::thread 快多少
实测数据（x86-64, Intel Xeon Gold 6330）：一次 fiber::resume() 平均耗时约 12–18 ns，而 pthread_yield() 或被抢占式切换平均 1.2–3.5 μs —— 差两个数量级。关键在于 fiber 切换完全在用户态完成，不陷入内核，也不触碰调度队列。
- 寄存器保存/恢复仅涉及 16 个通用寄存器 + RSP/RIP，由 hand-written assembly 实现，无函数调用开销
- 上下文数据存在 stack memory 上，若 fiber 栈未跨 NUMA 节点，L1 cache hit rate >95%，
tmem可控在 - 注意：
fiber不提供并发执行能力，纯协作式，必须配合线程池或 I/O 多路复用才能利用多核
哪些阻塞点会隐式触发上下文切换
不是所有“等待”都等价。以下操作只要发生，当前线程大概率被调度器挂起，引发完整上下文切换：
- 调用
std::mutex::lock()且锁已被占用（即使只等几纳秒，内核仍需将其标记为 TASK_UNINTERRUPTIBLE） - 读写文件描述符（如
read()/write()）未设O_NONBLOCK，且底层设备未就绪 - 使用
std::condition_variable::wait()，哪怕超时设为 1ns，内部仍走 futex 等待路径 - 调用
std::this_thread::sleep_for()，无论时长多小，都会进入内核定时器队列
替代方案：用 std::atomic_flag::test_and_set() 自旋（适合短等待），或改用 io_uring / epoll + 协程做真正异步 I/O。
CPU 亲和性设置不当反而增加切换开销
用 pthread_setaffinity_np() 或 taskset 把线程绑到固定核心，本意是减少 cache miss，但如果没考虑 NUMA topology 或中断分布，效果可能适得其反：
- 若绑定的核心正被网卡 IRQ 占满，你的线程会被频繁打断，每次中断返回都伴随一次 mini-context-switch
- 多个高优先级线程绑在同一 core，竞争导致
sched_latency_ns被反复压缩，调度器更激进地 preempt - 协程调度器若运行在线程绑定的 core 上，但其 fiber 的栈内存分配在远端 NUMA node，每次切换都触发跨节点内存访问（延迟 ≈ 100 ns）
建议先用 lscpu 和 cat /proc/interrupts 查清物理拓扑，再用 numactl --cpunodebind=0 --membind=0 同时约束 CPU 和内存域。
真正难的是权衡：协程省切换但不并行，线程能并行但切换贵，异步 I/O 减少阻塞但编程模型复杂。没有银弹，只有根据吞吐、延迟、可维护性三者取舍后的具体实现。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
