1. 从一次系统卡顿说起：为什么要搞懂“上下文”

先讲个真实经历。有次我帮朋友排查一台 Linux 服务器，配置不算差，32核64G，跑的也就是个普通的 Java 服务，可 CPU 使用率常年压在 70% 以上，偶尔还会出现“假死”几秒的现象。top 一看，用户态占用不高，反而是sy（系统态）占了快一半。当时第一反应是查系统调用、查锁竞争，绕了一大圈，最后用vmstat 1盯了几分钟，发现cs（context switch，上下文切换）那一列的数字高得离谱，每秒三四万次。问题一下就清楚了：不是业务代码不行，而是系统在“切换”这件事上耗掉了大量 CPU。

这就是上下文切换的典型危害——它不像 CPU 飙高、内存溢出那样显眼，但会像慢性病一样拖垮整机性能。而这背后牵扯到 Linux 内核里三个最基础也最容易混淆的概念：上下文、进程上下文、中断上下文。很多新手背面试题时能说出“上下文切换是进程切换时保存恢复现场”，但真要问他“中断上下文和进程上下文有什么本质区别”“为什么中断处理函数里不能睡眠”“一次切换到底要花多少纳秒、这些时间都耗在哪了”，往往就卡壳了。

这篇文章我想把这条线完整捋一遍。不堆砌术语，而是从“CPU 眼里看到的世界”这个角度切入，把什么是上下文、进程上下文和中断上下文分别是什么、上下文切换到底在切什么、切换开销从哪来、又该怎么观察和优化，一层层讲明白。不管是准备面试、排查性能问题，还是纯粹想搞懂操作系统原理，这篇都适合你。

2. 上下文到底是什么：CPU 的“记忆”与“现场”

2.1 一个生活化的类比：厨师换菜

想理解上下文，最直观的方式是类比。假设你是一个厨师，灶台上正在炒一道宫保鸡丁，油温、火候、盐放了多少、花生米什么时候下锅，这些“进行到哪一步了”的信息，就是你的“炒菜上下文”。这时候突然来了个外卖订单要你做一份回锅肉，你不能直接把宫保鸡丁扔了不管，而是得先把火关小、记住当前状态，等回锅肉做完，再回来接着炒宫保鸡丁。这个“记住状态再切走、做完再切回来”的过程，就是一次上下文切换。

CPU 和厨师完全一样。一个 CPU 核心在同一时刻只能执行一条指令流，但操作系统里同时活着几十个进程。为了让它们看起来都在“同时运行”，CPU 必须不断地从一个进程切到另一个进程。问题来了：切走的时候，这个进程刚执行到哪条指令？寄存器里存了什么？栈顶在哪？内存映射是怎样的？这些信息如果不保存，切回来的时候 CPU 根本不知道从哪继续。保存下来的这套“运行状态”，就是上下文。而“保存旧状态 + 加载新状态”这个动作，就是上下文切换。

2.2 寄存器和程序计数器：现场保护的最小集合

从硬件层面看，一次进程切换时 CPU 必须保存和恢复的核心东西包括：

• 程序计数器（PC）：下一条要执行的指令地址。丢了它，切回来就不知道从哪儿继续执行。
• 通用寄存器：eax、ebx、ecx 这些，保存的是当前计算的中间结果。函数参数、局部变量、循环变量都在这。
• 栈指针（SP）和栈帧：指向当前栈顶，栈里存着函数调用链、局部变量、返回地址。
• 状态寄存器（如 EFLAGS）：记录进位标志、零标志、中断开关状态等 CPU 状态。
• 浮点/SIMD 寄存器：做数值计算、多媒体处理时用到的 xmm、ymm 寄存器组。

xtask 之外，还有一层更关键的东西，这在后面讲进程上下文时会展开：虚拟内存的页表基址（CR3 寄存器）。每个进程的地址空间是独立的，切换进程意味着整个地址空间都要换掉，这一项是切换开销的大头之一。

2.3 上下文不是“一个盒子”，而是分层的

这里要强调一个容易误解的点：上下文不是一个单一的东西，它是分层的。

• 硬件层：就是上面说的寄存器现场，CPU 层面的保存和恢复。
• 内核层：进程的内核栈、调度信息、资源统计、信号处理状态等。这部分由内核管理。
• 用户层：进程的虚拟地址空间、打开的文件、环境变量等。

层级之间不是割裂的，一次完整的进程上下文切换，往往要跨越多层。理解了这个分层模型，后面再看“为什么切换那么慢”就顺理成章了。

3. 两种上下文的分野：进程上下文与中断上下文

3.1 进程上下文：一个进程的完整“独立世界”

进程上下文，从概念上讲，就是一个进程从被创建到被销毁期间，为了让它能独立运行所需的全部状态。它包含两部分：

用户态上下文：进程的虚拟地址空间，包括代码段、数据段、堆、栈，以及用户态的寄存器状态。这部分是进程自己“看得见摸得着”的世界。

内核态上下文：当进程发起系统调用、触发异常或中断时，CPU 会切换到内核态执行内核代码。此时进程使用的是自己的内核栈，内核栈里保存着这次陷入内核的现场信息、系统调用参数、返回值等。这部分属于“内核替这个进程干活时用到的工作现场”。

有个很精辟的说法：进程是资源分配的单位，也是调度的单位，进程上下文就是内核为这个单位维护的完整档案。切换到某个进程，就是把这个档案完整加载到 CPU 上，让 CPU 继续替这个“人”干活。

这里必须区分一个高频混淆点：内核态和用户态的切换，不等于上下文切换。

我见过不少人把这两者混为一谈。系统调用，比如 read()，会发生用户态到内核态的切换，这涉及特权级变化和栈切换，但不涉及调度器介入，也就是说不会从进程 A 切到进程 B。这种模式叫“陷入内核再返回用户态”，进程还是同一个进程，只是换了身份。真正的上下文切换，是调度器决定把 CPU 从进程 A 交给进程 B，这是两个完全不同的事件。前者叫 mode switch（模式切换），后者叫 context switch（上下文切换/进程切换），开销也差着数量级。

3.2 中断上下文：打断你正在做的事，然后走人

中断上下文是完全另一套逻辑。中断是硬件（或软件）异步通知 CPU 的机制，比如网卡来了一个包、磁盘完成了 IO、时钟滴答响了。CPU 收到中断信号后，会暂停手头正在干的事，跳转到内核预设的中断处理程序去响应这个事件。

这个“暂停手头正在干的事”时，CPU 当前在什么上下文里，是不确定的——可能在用户态跑进程 A，也可能在内核态跑系统调用，起决定性作用的反而是当前 CPU 上执行的是哪个上下文。但中断处理程序执行期间，它自己处在一种特殊的执行环境里，这个环境就是中断上下文。

中断上下文和进程上写有什么区别？关键有几点：

• 没有“自己的进程”：中断处理程序不代表任何进程运行，它只是“暂时借用了当前被打断者的 CPU 时间”。它不能用当前进程的用户态地址空间，也不能依赖任何进程的资源。
• 不可睡眠：这是中断上下文最硬性的约束。中断处理程序里不能调用会睡眠的函数，比如 mutex_lock、kmalloc(GFP_KERNEL)（可能睡眠）、copy_from_user 等。因为睡眠意味着要调度器介入挂起当前任务，但在中断上下文中没有“当前任务”这个概念，调度器根本无从下手。一旦睡眠，系统直接 oops，严重时直接死锁或崩溃。
• 栈资源极其有限：中断处理程序使用内核栈，而内核栈非常小（通常 x86 上是 8KB 或 16KB），不能大量使用局部变量或深递归。
• 必须尽快完成：中断处理期间，同等级或低级中断可能被屏蔽，拖得越久，系统响应越慢。所以才有了下半部机制（softirq、tasklet、workqueue）来处理不那么紧急的事。

很多人会问：如果我在进程上下文中正拿着某个锁，突然来了中断，中断处理程序里也尝试拿同一个锁，会怎样？答案是死锁。这也是为什么中断处理程序里要么不用锁，要么用 spinlock（自旋锁）并要求持有锁的临界区绝对不能睡眠。spinlock 在等待时会原地自旋，如果持锁者在睡眠中被中断打断，中断里又自旋等锁，就永无出路。

3.3 一张表说清两者区别

这里再补一个细节：异常其实要分两类。像缺页异常、系统调用这种“同步异常”，它们发生在进程执行指令的过程中，所以处理它们时仍然属于进程上下文（可以睡眠、可以使用进程资源）。而硬件中断（异步中断）才是真正的中断上下文。Linux 里区分这两者，就是看in_interrupt()的返回值，还有current宏是否可用。

4. 上下文切换全流程：从 tick 到 switch_to

4.1 谁来触发切换：三种调度时机

上下文切换不是无缘无故发生的，它的源动力是调度器决定“该换人了”。在 Linux 中，调度决策主要由以下时机触发：

1. 时钟中断（tick）：每过一段时间（通常是 1ms 到 10ms 不等），CPU 会收到一个定时器中断，内核会借这个机会检查当前进程的时间片是否耗尽。如果耗尽，就标记需要重新调度。这是最常见的抢占式调度源头。
2. 进程主动让出（睡眠/阻塞）：进程调用 sleep、wait、mutex_lock 等，明确表示“我现在等不到资源，不占用 CPU 了”，于是主动触发调度。
3. 唤醒新进程：比如进程 A 唤醒了一个更高优先级的进程 B，内核会评估是否要马上抢占当前进程，把 CPU 让给 B。

触发时机不同，但最终都汇聚到schedule()函数，它会选出一个“下一个应该运行的进程”，然后执行上下文切换。

4.2 切换的四步曲

一次经典的进程上下文切换可以拆解为四个步骤：

第一步：陷入内核。如果是用户态进程被抢占，CPU 先通过中断或系统调用从用户态切换到内核态。此时硬件会自动保存一部分现场（比如程序计数器、栈指针、EFLAGS）到内核栈。

第二步：保存当前进程的上下文。内核把当前进程的寄存器现场完整保存到它的进程描述符（task_struct）中，同时保存内核栈指针、PC 等。这一步把“当前进程的执行现场”冻结下来。

第三步：选择新进程。调用调度器，按照调度策略（CFS、RT 等）从就绪队列中选出优先级最高或最合适的进程。

第四步：加载新进程的上下文并恢复执行。把新进程之前保存的寄存器、栈指针、PC 恢复，同时刷新页表基址（切换地址空间），使新进程的虚拟内存映射生效。最后用一条返回指令跳回新进程的用户态（或内核态）继续执行。

从代码实现上看，核心是switch_to宏和__switch_to函数。switch_to做的是保存旧进程的寄存器现场、加载新进程的寄存器现场，其中最关键的是变换内核栈——因为每个进程都有自己的内核栈，switch_to会先把栈指针切到新进程的内核栈，再执行后续的恢复操作。有个经典注释：“The trick here is that we use the stack pointer to carry our state through the switch.”——意思就是：切换内核栈的同时，就完成了“从一个进程的世界穿越到另一个进程的世界”这个动作。

4.3 切换的隐藏成本：TLB、Cache、分支预测器

很多讲上下文切换的文章只提到“保存恢复寄存器”，如果只聊到这就停，那还没触及切换开销的核心。真正让上下文切换昂贵的地方，其实是它污染了 CPU 的各种硬件加速结构。

TLB（快表）：CPU 访问内存时要先查页表，为了加速，硬件里有一个叫 TLB 的缓存，记录着最近用过的虚拟地址到物理地址的映射。切换进程后，地址空间变了，TLB 里大部分旧映射不再有效，必须冲刷（flush）。下一次访问内存时，TLB 全部 miss，只能回内存查页表，这是非常慢的。

L1/L2/L3 Cache：进程切换意味着指令流和数据流都换了，之前辛苦加载进 Cache 的数据大概率用不上了，Cache 命中率断崖式下降。新进程重新热缓存需要时间，这段“冷启动”成本同样不可忽视。

分支预测器：现代 CPU 依赖分支预测来提前取指执行。切换进程后，分支预测表的上下文也失效了，误预测率暂时升高，流水线被迫冲刷。

结论就是：一次上下文切换的实际开销，远不止寄存器保存恢复那几百纳秒，把 TLB 刷新、Cache 变冷、流水线冲刷算进去，整体代价可以用“微秒级”来计量。在频繁切换的场景下，CPU 大量时间在“切换→热缓存→再切换→再热缓存”的循环里空转，真正的业务吞吐被大幅压低。

5. 性能视角：如何量化切换代价与观测切换频率

5.1 量级参考：知道大概要花多少钱

测量上下文切换开销有很多方法，社区里有种比较经典的 benchmark 叫mimimal context switch benchmark，用两个进程通过管道互发消息来测量一次进程切换的时间。在不同硬件和内核版本上结果差异很大，但大致量级可以给个参考。

• 同进程内用户态到内核态的 mode switch：约 0.1~0.5 微秒
• 同 CPU 上的进程上下文切换：约 1~4 微秒
• 跨 CPU 的进程上下文切换：更高，可能到 5~10 微秒，因为涉及跨核通信和缓存同步

注意，这只是单次切换的“裸代价”，还没算上新进程缓存冷启动带来的业务性能下降。实际业务场景里，切换开销会被放大数倍。

5.2 观测工具：vmstat 和 pidstat 怎么用

排查问题时，我通常按以下顺序来观测。

先用vmstat 1看整体情况，重点看cs（每秒上下文切换次数）和in（每秒中断次数）。如果cs经常上万甚至好几万，就要开始找根源了。

vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 2048576 12345 654321 0 0 0 5 800 5000 30 40 30 0 0

cs高企的同时，如果sy（系统态 CPU）也很高，基本可以判定 CPU 时间大量消耗在内核的切换和调度上了。

然后定位具体是谁在频繁切换，用pidstat -w：

pidstat -w 1 5 Linux 5.15.0 (myserver) 07/12/2024 _x86_64_ (32 CPU) 10:00:01 UID PID cswch/s nvcswch/s Command 10:00:01 0 1234 320.00 0.00 kworker 10:00:01 1000 5678 12000.00 0.00 java 10:00:01 1000 5679 11800.00 0.00 java

cswch/s是自愿切换（主动让出 CPU，比如等待 IO），nvcswch/s是非自愿切换（时间片耗尽被抢占）。一个 java 进程每秒自愿切换上万次，基本可以断定是线程数过多且大量阻塞造成的。我那次排障，最后定位到的原因就是线程池开太大，大量线程在竞争锁上睡睡醒醒，每次醒过来都是一次切换，把这些切掉之后cs从几万直接降到了两三千，CPU 使用率也跟着腰斩。

如果你想看更详细的调度事件，可以用perf sched：

perf sched record -- sleep 5 perf sched latency

它能统计出每个进程的平均切换延迟、等待时间等，适合做深层次的调度问题分析。

5.3 哪些场景最容易引发高切换

• 线程池过大：几十个线程抢 4 个核，每个线程都分不到完整时间片，频繁被抢占。
• 锁竞争严重：多个线程反复争同一把锁，拿不到就睡眠，拿到就唤醒，睡眠唤醒各算一次切换。
• IO 密集型短请求：每个请求都要阻塞等待 IO，而请求量又非常大，就导致频繁自愿切换。
• 定时器/信号过多：大量定时器在很短的周期内触发，每次触发都可能唤醒新任务。
• 忙轮询的线程：用 while(true) 读数据的线程，不停让出 CPU，也会制造大量切换。

5.4 降低切换开销的套路

性能优化有两个方向：减少切换次数，或者降低单次切换的代价。

减少切换次数：

1. 线程数匹配 CPU 核数，避免过度订阅。用线程池时，把核心线程数压到和可用核数相当。
2. 用无锁或更细粒度锁，减少锁竞争导致的睡眠唤醒。
3. 用 epoll 代替一个连接一个线程的模型，让事件驱动而非线程阻塞。
4. 避免高频率定时器，尽量合并或延长定时周期。
5. 绑核（CPU affinity），让关键线程固定在某个核上运行，减少跨核切换的 TLB 和 Cache 损耗。

降低单次切换代价：

1. 使用更细粒度的虚拟化或容器时，尽量开启大页内存（HugePages），能减少 TLB 冲刷后的重建开销。
2. 保持关键数据的局部性和访问模式友好，让热缓存能更快重建。
3. 考虑使用带硬件线程同步特性的机制，不过这是比较进阶的操作了。

6. 中断上下文的实战细节：为什么不能睡眠、能用什么锁

6.1 中断处理必须遵守的“军规”

前面反复提到中断上下文不能睡眠，这里展开说说原理和后果。

中断处理程序运行在一个“无家可归”的状态：它不属于任何进程，current宏在这种情况下指向的是被中断打断的进程，但实际上这个进程和中断处理程序没有归属关系。如果中断处理程序睡眠了，调度器不知道要把 CPU 切给谁——它面对的是一个“谁都不是”的实体，无法把它挂起到某个进程的等待队列上。此时内核会调用schedule()，但调度逻辑基于current进程进行操作，会出现无法预料的混乱，最终直接 BUG_ON 或者死锁。

具体到代码层面，你在中断上下文里调用这两个函数类型就要特别小心：

• mutex_lock / down_interruptible：会睡眠等待，禁止。
• kmalloc(size, GFP_KERNEL)：GFP_KERNEL 允许睡眠以回收内存，禁止。要用GFP_ATOMIC，它保证不会睡眠，代价是分配成功率可能更低。
• copy_from_user / copy_to_user：访问用户态内存可能引发缺页，缺页处理需要睡眠，所以禁止。
• schedule() / wait_event：禁止，想都不用想。

那中断处理程序里要用锁怎么办？只能用spin_lock/spin_lock_irqsave这类自旋锁。自旋锁的语义是：如果锁被占，就原地忙等（自旋），不会睡眠。对于中断上下文这种“必须尽快结束”的环境，忙等虽然浪费 CPU，但至少是可控的。

不过用自旋锁还有个经典的坑：如果进程上下文持有自旋锁的临界区里发生了中断，而中断处理程序也来抢同一把锁，就死锁了——进程在等中断结束，中断在等锁释放。解决方案是：在临界区里用spin_lock_irqsave保存并关闭本地中断。它会先把当前中断状态保存下来，关中断，再拿锁。这样就杜绝了“持锁期间被同核中断打断”的可能。

6.2 下半部机制：把该干的活往后挪

中断处理强调短快，但很多设备驱动确实有大量工作要做，比如网卡一次收到几百个包要逐包处理。如果全部放在硬中断里，系统会被卡死。

Linux 的解法是“上半部 + 下半部”：

• 上半部（hardirq）：只做最紧急的事，比如告诉硬件“我知道了，你继续工作”，然后快速返回。
• 下半部：把不紧急但必须做的事推迟到稍后执行。常见有三种：
  • softirq：软件中断，在硬中断返回后立即执行，软中断上下文里可以重新开中断，但仍不能睡眠。
  • tasklet：基于 softirq 实现的机制，运行在软中断上下文，通常用于驱动的下半部。
  • workqueue：工作者线程，运行在真正的进程上下文里，可以睡眠。适合做更重、可能需要阻塞等待的活。

这里有个容易混淆的点：softirq 和 tasklet 运行在什么上下文？

严格来说，它们运行在“软中断上下文”，继承自硬中断打断现场，使用被中断者的内核栈，所以依然不能睡眠。但如果它们是在进程上下文主动调用的（比如local_bh_enable时触发的软中断），那睡不睡就要看具体上下文了。但内核开发规范一般还是把它们视为“不能睡眠”的上下文来处理，以免出问题。

而 workqueue 是真正的进程上下文，current指向 worker 内核线程，可以睡眠、可以拿 mutex。所以当你的驱动要做耗时的 IO 操作时，正确姿势是把工作丢给 workqueue，而不是在 tasklet 里硬扛。

6.3 迁移到用户态：信号与 epoll 的边界

中断上下文还有一个容易忽略的影响：它不能直接通知用户态进程。用户态进程感知硬件事件（比如网络包来了）通常是通过信号或 IO 事件机制，而这些机制的底层支撑其实依赖内核在合适的时机唤醒等待中的进程。这个过程发生在退出中断上下文、回到进程上下文之后，由内核的唤醒路径和调调度器完成。

明白这条链路，排查一些问题会清晰很多。比如你写了个 epoll 服务，发现某个 fd 明明有数据，但 epoll_wait 一直不返回，很可能不是因为中断没触发，而是中断处理程序里标记的事件没有正确唤醒等待队列。知道中断上下文不能做这种事，就能理解为什么驱动代码里，从硬中断到唤醒进程之间，中间必定有一层“推迟机制”在做桥梁。

7. 关于上下文切换的几个高频误区与面试题

7.1 误区一：系统调用也算上下文切换

这个前面提过，但还是值得单列。系统调用是用户态到内核态的 mode switch，不换进程。判断标准很简单：切换后current是否变了。没变，就不是上下文切换。

7.2 误区二：上下文切换越少越好

这是个反直觉的问题。在高并发服务器里，适当的切换是必要的、健康的。比如一个 web 服务器同时有 1000 个连接，但只有 16 个核，那必然要频繁切换才能照顾所有连接。真正的问题不是“切得太多”，而是“无效切换太多”——比如大量线程在等锁、等 IO，醒了发现没资源又睡回去，这种切换对业务毫无贡献。判断切换是否有害，要结合r（运行队列长度）和 CPU 使用率一起看，不能只看cs数字。

7.3 误区三：中断上下文用的是独立的中断栈

这要看架构和配置。x86 上，Linux 为中断处理单独分配了每 CPU 的中断栈（一般是 16KB），硬中断处理时会切换到 interrupt stack。但软中断（softirq）处理则复用在被打断者的内核栈上。所以在 softirq 里更要节省栈空间，因为它是“借住”在别人家里的。ARM64 上有不同的实现细节，但思路类似。

7.4 面试题高频三问

Q1：进程 A 在用户态执行中发生时钟中断，调度器切到进程 B，完整过程是怎样的？

先硬件自动保存用户态现场到内核栈，CPU 切到内核态；进入时钟中断处理程序；中断处理中判断时间片耗尽，标记need_resched；中断返回路径上检查到该标记，调用schedule()；schedule()选出 B，通过switch_to保存 A 的内核上下文、加载 B 的内核上下文，包括切换内核栈和 CR3；最后从 B 的内核栈恢复用户态现场，CPU 回到 B 的用户态继续执行。

Q2：为什么中断上下文不能用 mutex？

mutex 在锁被占用时会调用调度器把当前任务挂起到等待队列，这要求“当前任务”是合法的进程实体。中断上下文没有独立的进程归属，不能睡眠，所以只能选择自旋锁这种不睡眠的锁。

Q3：如何定位频繁上下文切换的进程？

pidstat -w 1看每个进程的自愿/非自愿切换；vmstat 1看总切换数；perf sched latency分析调度延迟和等待时间；再用strace -c -p <pid>看系统调用频率辅助判断。

7.5 一个自查：这些概念你都能分清吗

最后留个小测验，如果你能不看资料答出下面这几个问题，上下文这块基本就过关了：

1. 内核线程（kworker）有没有用户态上下文？它被切换时保存什么？
2. 软中断（softirq）上下文中current指向什么？
3. 为什么GFP_ATOMIC分配内存可能失败率更高？
4. schedule()函数能不能在硬中断处理程序里被调用？

第 1 题的答案是内核线程没有用户态地址空间，切换它不需要切换 CR3（可以复用之前的用户空间页表，但要小心安全性），只需要切换内核态寄存器上下文和内核栈。第 2 题中 softirq 的current指向被中断打断时正在执行的进程，但这个进程和 softirq 没有任何关系，所以不要依赖它。第 3 题是因为GFP_ATOMIC不使用回收内存等可能睡眠的路径，只能从现存空闲页里直接分配，内存紧张时很容易失败。第 4 题显然不行，硬中断处理程序里不允许调用schedule()，这会导致内核崩溃。

8. 观察实践：亲手做一次上下文切换实验

纸上谈兵没意思，给你留一个可以在自己机器上复现的实验。

8.1 实验一：感受切换开销的存在

用taskset把两个进程绑到同一个 CPU 核上，再用管道传递简单消息，对比绑不同核的开销差异。

# 终端1 taskset -c 0 ./pipe_bench # 终端2 taskset -c 0,1 ./pipe_bench

自己写个简单的管道乒乓测试（两个进程互发消息 10 万次，统计耗时），你会发现绑同核和跨核的耗时差异非常明显。同核切换省去了跨核同步的开销，但依然要付出 TLB/Cache 冷却的代价。

8.2 实验二：经典 fork 炸弹的教训（别真跑）

如果你真想直观体验大量上下文切换的杀伤力，可以在容器里临时开一堆进程（注意：不要在生产环境玩这个），然后用vmstat 1盯cs列。进程数一多，cs数值会像过山车一样飙升，CPU 的sy也会被拉高，整个系统会变得迟钝。这背后的机制就是“大量进程争夺少量 CPU，调度器疲于奔命”。

8.3 实验三：观察内核栈的使用量

调试中断上下文栈溢出问题时，可以打开内核的栈使用统计：

echo 1 > /proc/sys/kernel/stack_tracer_enabled cat /proc/stack_tracer

它会列出内核栈剩余最多的函数调用链，帮你定位那些“栈吃得很凶”的路径。对驱动开发者尤其有用。

另外一个很实用的工具是/proc/<pid>/status里的voluntary_ctxt_switches和nonvoluntary_ctxt_switches字段，可以看某个特定进程的累计切换次数：

grep ctxt /proc/1234/status voluntary_ctxt_switches: 44183 nonvoluntary_ctxt_switches: 9122

配合前后两次采样做差值，就能算出某一时段的切换速率。想实时看，pidstat -w更顺手。

9. 结束语：上下文问题，本质是系统资源的调度艺术

个人在实际排查和开发中一个很深的体会：上下文切换这个看似基础的概念，其实是连接硬件、内核、应用三层世界的枢纽。硬件通过寄存器和缓存提供算力，内核通过调度决定谁用算力，应用通过合理的并发模型决定自己要不要频繁“进场出场”。大多数性能问题追到深处，都会遇到它。

所以我在写并发代码时，会一直盯着几个问题：线程是不是比核多太多了？锁的粒度是不是粗了？是不是有大量线程在空等？这些问题的本质，都是在问：我的程序制造了太多无意义的上下文切换吗？

这个概念本身不难，难的是把它内化成判断系统问题的直觉。下次遇到 CPU 高、吞吐低、不知道从哪里下手时，先看一眼vmstat的cs列，再问一句“系统的时间都去哪了”，方向往往就清晰了。