Linux上下文切换深度解析：从进程上下文到中断上下文的性能真相

1. 从一次系统卡顿说起为什么要搞懂“上下文”先讲个真实经历。有次我帮朋友排查一台 Linux 服务器配置不算差32核64G跑的也就是个普通的 Java 服务可 CPU 使用率常年压在 70% 以上偶尔还会出现“假死”几秒的现象。top 一看用户态占用不高反而是sy系统态占了快一半。当时第一反应是查系统调用、查锁竞争绕了一大圈最后用vmstat 1盯了几分钟发现cscontext 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 一张表说清两者区别对比项进程上下文中断上下文所属主体有明确的进程/线程归属无进程归属异步打断而来运行空间用户态 内核态系统调用/异常仅内核态代表的事件进程生命周期、系统调用、异常、被动调度硬件中断、异常部分、软中断能否睡眠可以内核态系统调用可睡眠等待绝对禁止栈资源用户栈 内核栈8/16KB复用被打断者的内核栈使用锁可用 mutex只能用 spinlock且临界区不能睡眠生命周期较长跨多次调度极短处理完立即返回典型场景进程被调度运行、进程被抢占、睡眠唤醒网卡收包、磁盘中断、定时器中断这里再补一个细节异常其实要分两类。像缺页异常、系统调用这种“同步异常”它们发生在进程执行指令的过程中所以处理它们时仍然属于进程上下文可以睡眠、可以使用进程资源。而硬件中断异步中断才是真正的中断上下文。Linux 里区分这两者就是看in_interrupt()的返回值还有current宏是否可用。4. 上下文切换全流程从 tick 到 switch_to4.1 谁来触发切换三种调度时机上下文切换不是无缘无故发生的它的源动力是调度器决定“该换人了”。在 Linux 中调度决策主要由以下时机触发时钟中断tick每过一段时间通常是 1ms 到 10ms 不等CPU 会收到一个定时器中断内核会借这个机会检查当前进程的时间片是否耗尽。如果耗尽就标记需要重新调度。这是最常见的抢占式调度源头。进程主动让出睡眠/阻塞进程调用 sleep、wait、mutex_lock 等明确表示“我现在等不到资源不占用 CPU 了”于是主动触发调度。唤醒新进程比如进程 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 0cs高企的同时如果sy系统态 CPU也很高基本可以判定 CPU 时间大量消耗在内核的切换和调度上了。然后定位具体是谁在频繁切换用pidstat -wpidstat -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 javacswch/s是自愿切换主动让出 CPU比如等待 IOnvcswch/s是非自愿切换时间片耗尽被抢占。一个 java 进程每秒自愿切换上万次基本可以断定是线程数过多且大量阻塞造成的。我那次排障最后定位到的原因就是线程池开太大大量线程在竞争锁上睡睡醒醒每次醒过来都是一次切换把这些切掉之后cs从几万直接降到了两三千CPU 使用率也跟着腰斩。如果你想看更详细的调度事件可以用perf schedperf sched record -- sleep 5 perf sched latency它能统计出每个进程的平均切换延迟、等待时间等适合做深层次的调度问题分析。5.3 哪些场景最容易引发高切换线程池过大几十个线程抢 4 个核每个线程都分不到完整时间片频繁被抢占。锁竞争严重多个线程反复争同一把锁拿不到就睡眠拿到就唤醒睡眠唤醒各算一次切换。IO 密集型短请求每个请求都要阻塞等待 IO而请求量又非常大就导致频繁自愿切换。定时器/信号过多大量定时器在很短的周期内触发每次触发都可能唤醒新任务。忙轮询的线程用 while(true) 读数据的线程不停让出 CPU也会制造大量切换。5.4 降低切换开销的套路性能优化有两个方向减少切换次数或者降低单次切换的代价。减少切换次数线程数匹配 CPU 核数避免过度订阅。用线程池时把核心线程数压到和可用核数相当。用无锁或更细粒度锁减少锁竞争导致的睡眠唤醒。用 epoll 代替一个连接一个线程的模型让事件驱动而非线程阻塞。避免高频率定时器尽量合并或延长定时周期。绑核CPU affinity让关键线程固定在某个核上运行减少跨核切换的 TLB 和 Cache 损耗。降低单次切换代价使用更细粒度的虚拟化或容器时尽量开启大页内存HugePages能减少 TLB 冲刷后的重建开销。保持关键数据的局部性和访问模式友好让热缓存能更快重建。考虑使用带硬件线程同步特性的机制不过这是比较进阶的操作了。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为什么中断上下文不能用 mutexmutex 在锁被占用时会调用调度器把当前任务挂起到等待队列这要求“当前任务”是合法的进程实体。中断上下文没有独立的进程归属不能睡眠所以只能选择自旋锁这种不睡眠的锁。Q3如何定位频繁上下文切换的进程pidstat -w 1看每个进程的自愿/非自愿切换vmstat 1看总切换数perf sched latency分析调度延迟和等待时间再用strace -c -p pid看系统调用频率辅助判断。7.5 一个自查这些概念你都能分清吗最后留个小测验如果你能不看资料答出下面这几个问题上下文这块基本就过关了内核线程kworker有没有用户态上下文它被切换时保存什么软中断softirq上下文中current指向什么为什么GFP_ATOMIC分配内存可能失败率更高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列再问一句“系统的时间都去哪了”方向往往就清晰了。