一次 context switch 究竟花费什么，为什么这很重要？

Question

IT Interview Practice · Accepted Answer

一次 **context switch**（上下文切换）是 kernel 保存当前运行线程的 CPU 状态（寄存器、program counter、stack pointer）并恢复另一个线程的状态，从而让单个 core 能多路复用许多线程。它在每次 scheduler 抢占、阻塞 syscall 或 interrupt 时发生——而且它并不免费。

## 成本藏在哪里

```text
DIRECT cost (visible, ~1–5 µs):
  save/restore registers · run scheduler logic · switch kernel stacks
  if PROCESS switch: also swap page tables (CR3) → FLUSHES the TLB

INDIRECT cost (often much larger):
  cold CPU CACHES → the new thread's data isn't in L1/L2/L3 → cache misses to RAM
  cold TLB        → address translations must be re-walked
  lost pipeline / branch-predictor state
```

**直接**成本是几微秒。**间接**成本——切换后冷掉的 cache 和 TLB——常常是更大的那一击：新进来的线程会慢跑一阵，因为它要从主存重新预热自己的 cache（每次 miss 几十到几百个 cycle）。

## 线程切换 vs 进程切换

在**同一进程的线程之间**切换更便宜：它们共享一个地址空间，所以 page table（以及在没有 tagged TLB / PCID 的硬件上的 TLB）无需改变。切换**进程**还要额外重新装载 page-table 基址寄存器，并且传统上会 flush TLB——这就是为什么它代价更高。

## 为什么它在实践中重要

- **线程太多** → scheduler 抖动（thrash），把 cycle 花在切换而非工作上；超过某个点，线程比 core 多反而*降低*吞吐量。
- 这是支持 **async / event-loop** 模型（Node、nginx、`io_uring`）和 **goroutine / green thread** 的核心论据：用很少的 OS 线程处理许多连接，避免每个请求一次切换。
- 这是为什么 **CPU pinning / affinity** 对延迟敏感的 service 有帮助——把一个线程固定在一个 core 上以保住它温热的 cache。
- 高的非自愿（involuntary）context-switch 计数（在 `vmstat`、`pidstat` 中可见）是 lock contention 或 CPU 超额订阅的经典症状。

## 为什么这很重要

这是一个 senior 级别的问题，因为它把知道这个*术语*的人与理解*为什么*它昂贵的人区分开来——而真正的答案（cache/TLB 污染，而不仅是保存寄存器）驱动着架构决策：用 async I/O 代替 thread-per-request、按 core 数量合理调整线程池大小、以及使用 affinity。它把 scheduling、虚拟内存和 CPU cache 串成一个性能故事。

成本藏在哪里

线程切换 vs 进程切换

为什么它在实践中重要

为什么这很重要

相关问题