2、中断模式原理：硬件中断机制、中断向量表、中断服务程序（ISR）的执行流程、中断上下文的切换开销
好，咱们接着聊中断模式。上一章我们讲了轮询的痛，这一章就来聊聊它的反面——中断。说白了，中断就是让CPU从“主动问”变成“被动等”。硬件有事了，喊一嗓子，CPU放下手里的活去处理。这个机制，是高性能系统的基石。
2.1 硬件中断机制：谁在喊CPU？
中断的源头，是各种硬件设备。比如网卡收到一个包，磁盘读完一块数据，定时器滴答了一下。这些设备会通过一根专门的物理信号线，向CPU发送一个电信号。这个信号，就是中断请求（IRQ）。
CPU收到这个信号后，会在当前指令执行完毕后，立刻响应。注意，是“当前指令执行完毕”，不是“当前任务执行完毕”。这个粒度非常细，保证了实时性。
我个人习惯把中断机制想象成一个“紧急呼叫铃”。每个硬件设备都有一个自己的铃，按下去，CPU就得过来看看。但问题是，CPU怎么知道按铃的是谁？这就引出了中断向量表。
2.2 中断向量表：CPU的“紧急联络簿”
中断向量表，本质上是一张表格。它存放在内存的固定位置，每个表项对应一个中断号。表项里存的是一个地址——中断服务程序（ISR）的入口地址。
当CPU收到中断请求时，它会根据中断号去查这张表。找到对应的地址，然后跳转过去执行。整个过程非常快，因为查表是硬件完成的，不需要软件干预。
核心要点：中断向量表是硬件和软件之间的桥梁。硬件提供中断号，软件提供处理函数。这张表一旦初始化好，就不能轻易改动，否则系统会崩溃。
我在项目中遇到过一个问题：某个嵌入式系统，中断向量表被意外覆盖了。结果CPU一收到中断，直接跳到了一个非法地址，系统瞬间死机。排查了很久才发现，是某个驱动在初始化时，不小心写错了内存地址。嗯，从那以后，我每次初始化中断向量表，都会加一个写保护。
2.3 中断服务程序（ISR）的执行流程
ISR的执行流程，可以拆成三步：
- 保存上下文：CPU自动把当前正在执行的程序的状态（寄存器、程序计数器等）压入栈中。这一步是硬件完成的，非常快。
- 执行ISR：CPU跳转到中断向量表指定的地址，开始执行我们的中断处理代码。这部分是软件写的，要尽量短小精悍。
- 恢复上下文：ISR执行完毕后，CPU从栈中弹出之前保存的状态，继续执行被中断的程序。
你想想看，这个过程就像你正在写代码，突然有人打电话。你先把当前思路记在便签上（保存上下文），然后接电话（执行ISR），挂掉电话后再看便签继续写（恢复上下文）。
实战建议：ISR里不要做复杂操作。比如网络协议栈的处理，千万别放在ISR里。我一般只在ISR里做两件事：读取硬件状态、发送一个信号量或事件给任务。剩下的工作，交给后台任务去处理。这叫“上半部/下半部”模式，能有效降低中断延迟。
2.4 中断上下文的切换开销
中断不是免费的。每次中断，都有开销。这个开销主要来自上下文切换。
上下文切换，说白了就是保存和恢复CPU的状态。保存哪些东西？寄存器、程序计数器、栈指针、状态寄存器……等等。这些数据量不大，但频率高了，累积起来就很可观。
举个例子：一个千兆网卡，每秒可能产生几万个中断。每个中断的上下文切换开销假设是1微秒，那光切换就占了几十毫秒的CPU时间。这还没算ISR本身的执行时间。
| 中断频率 | 单次切换开销 | 每秒总开销 | CPU占用率 |
|---|---|---|---|
| 1,000次/秒 | 1 μs | 1 ms | 0.1% |
| 10,000次/秒 | 1 μs | 10 ms | 1% |
| 100,000次/秒 | 1 μs | 100 ms | 10% |
看到没？当频率达到10万次/秒时，光上下文切换就吃掉10%的CPU。这还没算ISR里的逻辑。所以，高频率中断场景下，必须做优化。
避坑指南：我曾经在一个高频交易系统里，看到网卡中断频率飙到20万次/秒。结果CPU大部分时间都在做上下文切换，真正处理数据的时间反而很少。后来我们改用了中断合并（Interrupt Coalescing）和NAPI机制，把频率降到了几千次/秒，吞吐量反而上去了。记住：中断不是越频繁越好，要找到平衡点。
2.5 中断模式的核心流程图
下面我用一张SVG图，把整个中断流程串起来。从硬件发起请求，到CPU查表、执行ISR、恢复上下文，一目了然。
这张图把整个流程串起来了。你注意看，从硬件发出请求，到CPU查表跳转，再到ISR执行和恢复，每一步都有明确的硬件或软件动作。理解了这个流程，你就能明白为什么中断模式比轮询高效——因为它让CPU只在有事的时候才干活。
好了，中断模式的原理就讲到这里。下一章我们会聊聊中断模式在实际系统中的优化技巧，比如中断合并、亲和性绑定、以及如何避免中断风暴。这些都是在高并发场景下必须掌握的技能。
公众号:蓝海资料掘金营，微信deep3321