先看一个每天都在发生的场景：你在工位上写月度总结，领导突然推门进来问你昨天的数据，你放下写了一半的文档，转去回答他的问题，答完再回来接着写。如果不允许被这样“打断”，你就得每隔十分钟主动去问一次领导有没有新指示——这就是最常见的两种东西：中断和轮询。这篇文章想把这些概念彻底讲清楚：中断到底是什么、它为什么能成为整个计算机系统最底层的支柱之一、从硬件信号到操作系统调度它到底走了一条什么样的路，以及我在实际项目中写中断处理程序踩过哪些坑。

这个话题适合所有学计算机基础的学生、刚入行的嵌入式开发者，以及那些写过业务代码但从没认真想过“时间片靠谁推进”“键盘为什么一按就响应”这类问题的工程师。看完之后你再看代码，很多靠“死循环”撑起来的东西，背后其实都是中断在驱动。

1. 中断到底是什么：一次“被外部事件打断”的执行流切换

1.1 你其实每天都在用中断，只是没意识到

打字的时候按下键盘，屏幕立刻出现字符；网卡收到一个数据包，应用进程马上被唤醒；定时器走到设定时刻，系统自动切换下一个进程。这些看起来毫无关系的场景，底层用的都是同一个机制——中断。

中断的定义可以压缩成一句话：CPU暂停当前正在执行的程序，转去处理一个突发的事件，处理完之后再回到原来那个程序继续往下执行。关键在于“暂停”和“恢复”都是硬件级自动完成的，程序本身感知不到自己曾经被中断过。

我说个更生活化的类比。你正在写代码，突然手机响了，你接电话，聊完挂掉，再切回编辑器继续写。代码不会因为你接了个电话而中断——它就是等在那里，你回到编辑器时续写即可。中断做的事情就是“强制让你接电话”的机制，而“谁打来的、优先级多高、要不要接”就对应了中断源、优先级和屏蔽规则。

这个机制的牛之处在于：它让CPU从“主动去查设备有没有事”变成了“设备有事来找CPU”。也就是把CPU从“跑腿的”升级成了“被服务的”。

1.2 中断的三要素：暂停、切换、恢复

要真正理解中断，不能只看表面，得看它背后的三个动作。

第一个动作是暂停。CPU在执行一条指令，假设这条指令还没执行完，那么中断不会立刻发生，要等当前指令执行完毕，CPU才会去检查有没有中断请求。这个“指令级原子性”非常重要，否则一条指令执行了一半就被打断，数据和栈状态全乱了。

第二个动作是切换。CPU发现中断请求后，先把当前状态保存起来（术语叫保护现场），然后跳转到中断处理入口，执行相应的中断服务程序。这个“状态”至少包含程序计数器（PC）、标志寄存器以及相关的通用寄存器，它们被压入内核栈。

第三个动作是恢复。中断处理程序执行完后，CPU从栈中弹出之前保存的状态，程序计数器回到被打断的位置，程序继续运行，仿佛什么都没发生过。这个过程叫恢复现场，由一条专门的返回指令完成，比如x86里的iret。

这三个动作合起来就是一次完整的中断响应。注意一个细节：保护和恢复现场不是由中断服务程序自己写的代码完成的，而是硬件配合操作系统完成。硬件负责压栈和跳转，软件负责保存剩余的寄存器并做真正的处理。

2. 为什么必须引入中断：轮询方案的效率瓶颈与实时性缺陷

2.1 轮询到底有多浪费：一个串口接收的例子

在中断出现之前，软件要处理外部事件只有一个办法——轮询。程序不停循环，每次循环去读设备的状态寄存器，看设备有没有新数据；如果有就处理，没有就继续循环等待。

看起来简单直接，但代价高得吓人。拿单片机串口接收数据的场景来说，波特率9600意味着每个字节约1ms才到达一个。程序如果每100微秒轮询一次串口状态，那么为了接收一个字节，需要执行大约10次检查，而其中9次都是无功而返。CPU在这1ms里本可以执行成千上万条有效指令，却全被浪费在“干等”上了。

更糟糕的是轮询的实时性上限取决于轮询频率。假如外部事件只维持200微秒，而你的轮询周期是400微秒，那你大概率检查不到这个事件，事件就此丢失。中断不存在这个问题：事件发生那一刻，硬件信号直接拉高，CPU下一个指令周期就响应，延迟通常只有几微秒到几十微秒量级。

2.2 中断解放的是CPU，不是设备

中断带来的核心价值有三个。

效率价值：CPU不用再浪费指令去“查岗”，可以把算力全给业务逻辑。设备一个中断信号就把CPU从忙等中解放出来，这叫事件驱动。

实时价值：中断响应时间是由硬件保证的，能对突发事件做到“随叫随到”。这个特性是后面一切实时操作系统的基础。控制电机、读取传感器、处理急停按钮，都必须靠中断而不是轮询。

交互价值：如果没有中断，键盘按下的动作要等到程序自己循环到“检查键盘”那一步才能被发现，CPU一忙起来你的输入就全部丢失。有了中断，操作系统保证每一次按键都能被感知到，哪怕系统已经忙得不可开交。

2.3 轮询并没有被淘汰

有些情况轮询反而更合适。

一是事件发生的频率极高，比如高频率采样传感器数据，每个周期都在变化，那中断的“来回报销”反而成为负担，不如直接同步轮询。二是设备本身不支持中断，比如某些老旧外设只有状态寄存器，没有中断引脚。三是简单的裸机程序，主循环里处理的任务很少，轮询代码更直白，不容易出错。

所以现在工程上的常态是中断+轮询结合：中断负责“提醒有事件”，真正的耗时代理任务由主循环在被提醒之后去处理，这其实就是后面要说的“上半部/下半部”思路的雏形。

3. 一次完整的中断生命周期：从硬件信号到现场还原

3.1 中断请求：外设怎么“开口说话”

中断的第一步是设备向CPU发出信号。这个信号通常是电平变化或边沿跳变，通过CPU的中断引脚传进来，或者通过一个中断控制器汇总。

外部设备不直接连到CPU的中断引脚，而是先连到一个中断控制器上。中断控制器的作用就是“接电话的平台”：多个设备都接在这里，谁来电话了，它记下是谁，然后统一向CPU报告。

CPU收到信号后，在每条指令执行完的边界上检查中断控制器发来的“来电提示”。如果满足响应条件（没有关中断、优先级够高），CPU就会进入响应流程。

3.2 中断向量：CPU怎么知道该找谁

不同设备的中断对应不同的处理函数，CPU不可能自己发明一套查找逻辑，它靠的是一个查找表——中断向量表。

这张表存在内存的固定区域，每一项存放一个中断处理函数的入口地址。设备的中断号决定了表里的下标。比如中断号33的设备触发中断，CPU就跳转到向量表第33项指向的地址。

查表的过程就是一次内存加载加一次跳转，比软件做逻辑判断快得多，这也是向量化中断方案的通用做法。嵌入式设备通常只有几十到上百个中断源，桌面级别的可能上千个，但无论如何，查表都是常数时间。

3.3 保护现场与恢复现场：断点续传的底层实现

既然要被“打断”，就必须保证随时能“接上”。这就是保护现场的意义。

硬件自动压入堆栈的内容通常包括当前程序计数器、标志寄存器，甚至还包括处理器的某些状态。但如果中断服务程序要用到其他通用寄存器，那就得由软件自己保存——一般是在中断入口处压栈，在出口处弹栈。

从程序员角度看，这就像看书时在正读到的一半夹了一张书签。书签记下了页数和行号，回来后从书签处继续读。CPU的“书签”就是栈里保存的那一串寄存器值。

常见的中断返回指令会把栈里保存的PC弹出，CPU直接跳转到被打断那条指令的下一行。整个保护和恢复过程如果做得完美，中断对用户程序的执行结果零影响——除了多花一点时间。

3.4 一个最小示例直观感受全流程

用伪代码描述一次外部中断的完整路径：

// 设备触发中断： // 1. 设备拉高中断请求线 // 2. 中断控制器记录中断号N，向CPU发送INT信号 // CPU响应阶段（硬件自动完成）： // 当前指令执行完毕; // 检查中断标志和优先级; // 压栈PC; // 压栈标志寄存器; // 查中断向量表 -> 跳转到IRQ_N_Handler; // 中断服务程序（ISR）： void IRQ_N_Handler(void) { save_and_disable_interrupts(); // 软件保存通用寄存器 handle_device_event(); // 真正处理设备事件 restore_and_enable_interrupts(); // 恢复通用寄存器 iret_return(); // 弹栈标志寄存器、PC，返回原程序 }

这套流程在不同的CPU架构上细节略有不同，但宏观骨架全世界通用。理解了这个骨架，你再看任何芯片手册的中断章节，会发现都是同一件事换了套名词。

4. 中断家族分类：外部中断、内部异常、陷阱与软中断

很多人以为中断只有“外设触发”这一种，实际上中断是一个大家族，按来源和触发方式可以分出几类。

4.1 外部中断：来自CPU门外的客人

这是最常说的“硬件中断”，由CPU外部设备触发。网卡来包、硬盘读写完成、定时器到期、按键按下，都属于这一类。

外部中断又细分为可屏蔽中断和不可屏蔽中断。可屏蔽中断可以通过软件指令（比如x86的cli/sti）暂时关闭，适合日常设备；不可屏蔽中断（NMI）一旦触发，CPU无论如何都必须响应，专门留给最严重的故障——比如电源异常、内存校验错误这类容不得半点拖延的事件。

4.2 内部异常：程序自己惹出的事

CPU在执行指令的过程中发现不对劲，这种“从内部冒出来的打断”叫异常，也叫内部中断。典型的例子是除零、访问非法内存地址、执行非法指令、缺页（page fault）。

异常的特点是同步发生的——“这一条指令引发的错，就在这条指令处理时被报告”，而不是像外部中断那样随时可能乱入。程序员日常调试看到的segmentation fault，底层就是异常报告上来的。

4.3 陷阱与软中断：主动要求被“打断”

还有一类中断是程序自己故意触发的，叫陷阱或软中断。

程序执行一条特殊指令，比如x86的int n或syscall，CPU会跳转到一个预定处理函数。该函数的入口地址由中断向量表决定，因此一条指令就实现了“用户态到内核态”的切换。操作系统提供给应用层的系统调用，几乎都是靠这个路子实现的——应用程序发起系统调用，底层变成一次软中断，CPU进入内核，执行对应服务，再带着结果返回用户态。

陷阱和异常虽然都属于“内部打断”，但区别在于陷阱是故意为之、一切都在计划内；异常则通常意味着程序出了问题。它们共用同一套中断向量表，只是入口后的处理逻辑完全不同。

5. 多个中断抢CPU时怎么办：优先级、嵌套与屏蔽

5.1 中断多了也要排座次

现实系统里中断源远不止一个。一块网卡可能有接收、发送、链路状态多个中断，加上定时器、磁盘、键盘、鼠标，几十个中断同时请求的情况并不罕见。中断控制器的核心工作就是从一堆请求里挑出最紧急的一个，把它报告给CPU。

每个中断源有一个编号，编号同时隐含了它的优先级。嵌入式MCU的中断控制器里，每个中断源都可以配置抢占优先级和子优先级；桌面级别的中断控制器则在硬件层面就分配好了固定的优先级顺序。

当多个中断同时到来，CPU会选择优先级别最高的先响应。这很像急诊室的护士分诊——每个病人都有编号，但危重病人永远排在前面。

5.2 高优先级打断低优先级：中断嵌套

优先级不只用于排队，还用于“插队”。如果一个低优先级中断正在处理，高优先级中断突然到来，在允许嵌套的前提下，高优先级中断会打断正在执行的中断服务程序，处理器先响应高优先级，处理完了再回来继续低优先级的处理。

这个过程很像接了一个重要电话，旁边又进来一个更急的电话，你只能说声“稍等”然后切走。中断嵌套保证了高实时性系统不会因为处理低优先级事件而错过最紧急的事。

嵌套带来的代价是栈空间消耗：每嵌套一层，就要多压入一份现场。如果中断源设计得层级很多、堆栈空间又不够，系统会在毫无预兆的情况下溢出。所以裸机上写中断服务程序一定要关注栈大小，否则系统会跑着跑着突然“死机”却又查不出哪行代码有问题。

5.3 关中断与临界区：保护共享数据的手段

中断可以开，就可以关。用指令临时关掉可屏蔽中断，在此期间任何外部中断都进不来，这段代码就叫临界区。

临界区通常用来保护共享数据。如果一个全局变量既被主程序读写，又在中断服务程序里被修改，那么主程序在读取该变量的过程中如果被中断打断，就可能读到中间状态——典型的竞态条件。解决办法就是“读之前关中断，读完开中断”，保证这个读写过程是原子的。

void updater(void) { cli(); // 关中断 shared_counter++; // 临界区操作 sti(); // 开中断 }

关中断是把双刃剑：时间太长会导致真实的中断得不到及时响应，整个系统的实时性就毁在你这几行代码上。所以临界区要越短越好，只保护真正需要保护的变量。我见过有人为了省事，在中断处理函数的入口把所有中断都关掉，直接造成定时器中断丢失、系统时钟跑偏的惨案。关中断的粒度要和业务实时性要求严格匹配，不要图省事。

6. 中断在操作系统中的三重使命：系统调用、调度器与“上半部/下半部”

6.1 系统调用本质上就是一次软中断

操作系统内核运行在内核态，普通程序运行在用户态。用户程序读写文件、创建进程、申请内存时，不能直接操作硬件和内核数据结构，只能请求内核代办。这个“请求代办”的动作就是系统调用，而它的实现方式之一就是触发一次软中断。

程序把系统调用号放在指定寄存器中，执行syscall指令（老一些的用的是int 0x80，这在老旧的32位系统上很常见），CPU自动切换到内核态，根据中断号去查中断向量表，找到系统调用分发函数，再按系统调用号做次级分发。

整个机制里，软中断承担了“从用户态安全进入内核态”的桥梁作用。没有中断，操作系统的隔离和保护设计就得推翻重来。

6.2 时间片轮转靠定时器中断驱动

操作系统的进程调度有一个基础前提：“CPU时间片到了，该切下一个进程了”。这个“时间片到了”是谁说的？是定时器中断。

操作系统初始化时会配置一个定时器，让它周期性发送中断。每次时钟中断到来，操作系统就认为当前进程用完了一个时间片，于是触发调度器，保存当前进程上下文、选择下一个进程、恢复其上下文并继续执行。这个过程就是上下文切换。

你以为程序是一口气跑完的？实际上任何一个多任务系统里，每个进程都是被定时器中断“切”成一个个小片段的。你上网冲浪时看着流畅的页面，背后其实是你的浏览器进程被高频中断切进来切进去几千次的结果。定时器中断堪称操作系统的心跳。

6.3 为什么ISR里不能为所欲为：中断上下文与延迟工作

中断处理程序运行在“中断上下文”，这意味它不属于任何进程，不能睡眠、不能长时间占用CPU、不能调用可能阻塞的函数。

原因很直接：如果你在中断服务程序里睡眠，等于让CPU停下所有任务等一个不知何时才会回来的事件，整个系统直接卡死。内核里大量并发控制手段（比如信号量）在中断上下文里也是不能用的，因为它们涉及调度和睡眠。

为了解决“ISR必须块但事件处理又很耗时间”的矛盾，现代操作系统普遍采用“上半部/下半部”机制。上半部就是真正的ISR，只做最简单的事——记录事件、屏蔽自己的中断源、关闭设备中断，然后立刻退出；下半部则把这件耗时的处理挂到后续的软中断、工作队列或tasklet里，等系统有空时再执行。

我写过一版网卡驱动，最初把所有数据处理都放在ISR里，一收包就是几十微秒的CPU占用，在高负载下直接把系统的定时器中断饿死了。后来改成“ISR只做收包标记，具体协议解析放到工作队列里”，系统负担立刻降下来。记住，ISR的黄金准则是“快进快出”。

7. 实战经验：ISR怎么写才不出事，中断问题怎么排查

7.1 中断处理函数里的“黑名单操作”

代码层面的雷区，我总结一个黑名单：

中断服务程序里绝不该出现的操作包括：打印调试信息（printf/日志，非常慢且可能加锁）；调用malloc等动态内存分配函数（分配器内部有锁，还可能在锁里睡眠）；运行可能阻塞的系统调用（读磁盘、等待信号量）；做复杂运算或大数据复制。

这些操作的共同特点是耗时长或可能睡眠。正常的中断服务程序应当控制在几微秒到几十微秒内，超过100微秒就要怀疑是不是把不该放的东西放进来了。

7.2 volatile、共享变量与竞态

ISR和主程序共享一个变量，而主程序可能在任意时刻被ISR打断。如果你在ISR里修改了变量而在主程序里读取时不加任何防护，轻则读到旧值，重则因为编译器优化读取了缓存在寄存器里的值，导致逻辑出错。

被中断修改的全局变量，声明时要用volatile修饰，告诉编译器“每次读取都去内存取，不要缓存到寄存器”。但volatile只能解决“编译器层面的缓存”，解决不了“两个写入交叉执行”的问题——后者仍然需要临界区或原子操作来保证。

7.3 中断故障排查的经典思路

中断类问题排查，我总结为三步走。

第一步，确认中断有没有发生。在ISR入口置一个全局标记或在调试器里打断点，看它会不会进来。不会的话，查中断使能位、外设状态位、硬件连线，绝大多数“中断不触发”都是因为某个使能标志没置位。

第二步，确认中断是不是频率过高。用一个计数器变量，在ISR里自增，主循环里定时打印，就能算出中断频率。如果远高于预期，很可能外设没有把中断状态位清除，导致中断反复触发。这种“每隔几微秒进一次ISR”的bug会让系统看起来像死机一样。

第三步，确认ISR耗时。在ISR入口翻转一个GPIO引脚，用示波器或逻辑分析仪看高电平宽度，就知道ISR实际执行时间。如果把不该放的东西放进去了，这个宽度会明显超标，甚至可以复现“某中断持续执行导致其他中断丢失”的现象。

在嵌入式开发中，中断引发的问题往往表现得很诡异——系统随机跑飞、主循环时快时慢。但只要按这三步排查链路走一遍，十有八九能在半小时内定位到根因。

我这些年写过太多中断相关的代码，从GPIO按键到DMA接收，从定时器调度到网卡驱动，最深的一个体会是：中断不是“一个功能”，而是一套系统级的协作机制。硬件负责快速切进去，软件负责快速切出来，中间的每一环——向量表、优先级、临界区、共享变量——都像一个齿轮，任何一个卡住，整台机器都会抖一下。理解它不需要炫技，只需要把机制层面的逻辑梳理清楚，然后多按“ISR要短、临界区要小、共享数据要保护”这三条纪律写代码，基本能避开绝大多数中断引起的诡异问题。