线程上下文切换是操作系统保存当前线程状态并加载目标线程状态的过程，涉及寄存器、栈指针、程序计数器等，由内核调度器触发，常见于Sleep、锁等待、I/O完成等场景。
线程上下文切换到底发生了什么
线程上下文切换是操作系统把 CPU 控制权从一个线程交给另一个线程的过程。它不是简单地跳转指令，而是要保存当前线程的完整执行状态（包括 寄存器值、栈指针、程序计数器、FPU/SSE/AVX 寄存器 等），再加载目标线程之前保存的状态。这个过程由内核调度器触发，常见于：线程调用 Thread.Sleep()、等待 Monitor.Enter()、I/O 完成、时间片用尽或发生中断。
一次上下文切换典型开销是多少
在现代 x64 Windows 或 Linux 上，一次完整的上下文切换（用户态 → 内核态 → 用户态）通常消耗 1–5 微秒（μs），但实际影响远不止这个数字：
- CPU 缓存失效：切换后新线程访问的数据大概率不在 L1/L2 缓存中，引发大量缓存缺失（cache miss），可能带来额外几十到上百纳秒延迟
- TLB 刷新：如果两个线程属于不同进程（即不同虚拟地址空间），页表切换会导致 TLB（Translation Lookaside Buffer）大量失效，进一步拖慢内存访问
- 调度器开销：Windows 的
KeSwapContext或 Linux 的__switch_to本身需执行数十条指令，还涉及自旋锁、队列操作等 - 在高并发短任务场景下（如每请求新建线程处理 HTTP 小包），切换开销可能占到总执行时间的 10% 以上
如何观察 C# 中是否频繁发生上下文切换
不能只看 Thread 对象数量——关键看调度行为。推荐以下实测方式：
- 用 Windows 性能监视器（PerfMon）添加计数器：
System\Context Switches/sec，持续高于 5000–10000/sec 通常说明存在压力 - 使用
dotnet-trace录制并分析：dotnet-trace collect --providers Microsoft-Windows-Kernel-Scheduler,Microsoft-DotNETCore-SampleProfiler
，查看Scheduler.Switch事件密度 - 避免误判：
Task.Run(() => Thread.Sleep(1))这类代码会制造“假切换”（线程池线程被阻塞后释放，新任务唤醒另一线程），不代表真实调度压力；真正危险的是同步阻塞 I/O 或lock激烈争用
C# 开发中最容易意外引发高频切换的写法
很多看似无害的写法，在高吞吐场景下会成为上下文切换放大器：
- 在异步方法里写
Thread.Sleep(1)或Task.Delay(1).Wait()—— 强制当前线程挂起，调度器必须切走并后续唤醒 - 密集轮询共享变量：
while (!ready) { Thread.Yield(); }，每次Yield()都是一次轻量级切换请求 - 过度使用
lock (obj) { ... }且临界区较长，导致其他线程反复进入等待队列并被唤醒/挂起 - ASP.NET Core 中用
Task.Run(() => SyncHeavyMethod())包裹本可异步的 I/O 操作，把 I/O 等待变成线程池线程空转
上下文切换本身不可见、不报错，但它的代价会以“CPU 使用率不高却响应变慢”“吞吐上不去但线程数飙升”等形式暴露。最有效的缓解方式不是调优切换逻辑，而是从源头减少阻塞和争用——比如用 await stream.ReadAsync() 替代 stream.Read()，用 Channel 替代手动加锁队列。
