上下文切换成本核心在于寄存器与PC快照引发的执行环境重置：关键寄存器（10–20个）快照约160–200字节，需内核态完成并触发TLB刷新、缓存失效等副作用；PC快照虽仅单次读写，但决定指令执行起点，偏差将导致逻辑错误；三方面隐性损耗——时间延迟（0.5–3μs/次）、缓存污染（DRAM重加载70ns+）、编译器优化受限。
上下文切换的成本，核心不在变量计算本身，而在于保存和恢复执行状态时对寄存器与程序计数器（PC）的快照操作——它不参与运算，却决定能否继续正确运算。
寄存器快照：不是“全量保存”，而是“关键寄存器快照”
现代 CPU 有数十个通用寄存器，但上下文切换时仅需保存当前函数执行所依赖的活跃寄存器（如 RAX、RBX、RSP、RIP 等），通常为 10–20 个。每个寄存器 8 字节，总开销约 160–200 字节。这远小于线程栈的 MB 级别占用，但关键在于：该操作必须在内核态完成，触发一次完整的特权级切换（user → kernel → user），带来至少数百纳秒延迟。
- 保存动作本身极快（几十纳秒），但伴随 TLB 刷新、缓存行失效、中断禁用等副作用
- 若寄存器中存有未写回内存的临时计算结果（如中间累加值），快照能保证其不丢失；但若程序依赖寄存器别名或编译器优化后的寄存器重用，快照时机不当可能使恢复后逻辑错位
- GDB 调试或协程挂起时，常通过
ucontext_t或getcontext/setcontext捕获寄存器快照，这类用户态快照绕过内核，延迟可压至 50 纳秒内
程序计数器（PC）快照：决定“从哪继续算”，而非“怎么算”
PC 是唯一标识下一条指令地址的寄存器。它的快照成本几乎可以忽略（单次读取+存储），但语义权重极高：一旦 PC 偏移错误，后续所有变量计算都会基于错误上下文展开——比如本该跳转到分支处理逻辑，却因 PC 恢复偏差继续执行主干代码，导致变量被重复赋值或跳过初始化。
- 在中断/系统调用返回时，内核从 task_struct 的 thread.sp 和 thread.ip 中恢复 PC，这个过程受中断屏蔽窗口影响，存在微小但确定的延迟抖动
- 协程中 PC 快照由运行时手动维护（如通过
__builtin_return_address(0)或汇编lea (rsp), %rax获取返回地址），不触发内核介入，但需确保编译器不内联关键挂起点 - 分离栈架构下，PC 属于调用栈帧（StackFrame）的一部分，与数据栈解耦；因此快照 PC 不会拖慢变量序列化，也不会阻塞数据栈异步持久化
对变量计算的实际损耗：隐性，非直接
寄存器与 PC 快照本身不改变变量值，也不触发任何算术运算。所谓“损耗”，体现在三方面：
- 时间损耗：每次切换平均增加 0.5–3 微秒延迟，高并发下累积成毫秒级调度抖动，使变量更新周期不可预测
- 缓存污染：切换导致 L1/L2 缓存中刚加载的变量数据被驱逐，下次访问需重新从 DRAM 加载（70 纳秒起），放大计算延迟
- 编译器约束：为保障快照一致性，编译器可能禁用某些寄存器优化（如将循环变量全程保留在 R12 而不写回栈），间接增加寄存器压力或降低指令级并行度
不复杂但容易忽略：真正拖慢变量计算的，从来不是快照那几十个字节，而是它撬动的整个执行环境重置链路。
