操作系统中断、关中断与开中断：STM32/Linux实战优化

1. 先把中断这件事说透：它到底解决了什么问题

很多人学操作系统，第一章看进程调度、第二章看内存管理，看到中断这块就直接跳过去了，觉得不就是"打断一下 CPU"嘛。但真到写驱动、调 RTOS、优化串口丢包的时候，才发现所有问题的根子都在中断上。我自己第一次接触这个概念是在一块 STM32F103 上，串口用轮询收数据，波特率一上到 115200 就开始丢字节，改成中断接收立刻就稳了——那一刻我才算真正理解了操作系统中断存在的意义。

这篇文章想聊的是操作系统中断，以及和它绑在一起的两个动作：关中断和开中断。它适合三类人看：正在学计算机操作系统、被中断向量表和 ISR 绕晕的学生；写嵌入式驱动、调 STM32 或者国产操作系统下面外设的工程师；还有做性能优化、发现系统抖动大却找不到原因的人。关键词会围绕操作系统、中断、关中断、开中断、中断服务函数、中断优化这些展开，穿插一些我在 Linux 和裸机两边的实际踩坑记录。

我打算按这个顺序讲：先说清中断解决的是什么问题，再说关中断这个动作到底作用在哪一层，然后讲中断控制器怎么和屏蔽机制配合，接着落到内核里自旋锁、临界区、底半部这些真实用法，最后给两套能直接上手的实操流程和一张排查速查表。

1.1 从一次按键说起：轮询为什么不够用

设想一个最原始的场景：你按了一下键盘上的 A 键，这个动作需要在屏幕上显示出来。CPU 怎么知道按键发生了？最笨的办法是轮询——CPU 不停地去读键盘控制器的一个状态寄存器，看第 0 位是不是 1，是 1 说明有新按键，读出来处理掉，然后继续循环读。这个方法逻辑简单，但代价惊人：假设你把这个循环写成忙等，CPU 会被 100% 占满去做"看一眼有没有按键"这件事，其他什么活都干不了。

更现实的问题还不是占用率，而是时机。如果 CPU 正在执行一个耗时几毫秒的任务，中间没空去看状态寄存器，而人在这段时间里按了两下键，键盘控制器内部只有一个字节的缓冲，第二下按键就把第一下的数据覆盖了——这就是丢失事件。轮询的采样频率必须高于事件发生的最快频率，一旦事件来得比采样快，必丢。

中断的思路完全反过来：让外设主动"喊"CPU。键盘控制器检测到按键后，拉高一根物理连线，送到 CPU 的中断引脚，CPU 在当前指令执行完毕、下一条指令取指之前，插入一段处理逻辑。**CPU 不需要知道事件什么时候来，它只需要事先告诉外设"有事就喊我"。**这个转变把"主动查询"变成了"被动响应"，CPU 的利用率从 100% 忙等降到几乎为零，同时响应延迟只取决于硬件信号到 CPU 的那几个时钟周期。

这个模型放到现代计算机上依然成立。网卡收到一个数据包，是中断通知 CPU；硬盘完成一次读操作，是中断通知 CPU；定时器数到点，也是中断。整个操作系统的 I/O 子系统，本质上就是围绕"谁在什么时候打断我"搭建起来的。

1.2 硬件中断、软件中断和异常，三者别混着谈

我见过太多人把这三个词混着用，结果讨论问题的时候各说各的。它们确实都属于"打断当前执行流"这件事，但来源和处理方式差别很大。

硬件中断（也叫外中断）来自 CPU 外部，是真正的物理信号。它经过中断控制器（PC 上经典的 8259A、ARM 上的 GIC、MCU 里的 NVIC）仲裁后送到 CPU 的中断请求引脚。按键、网卡收包、定时器溢出都属于这一类。硬件中断是异步的——你完全无法预测它下一秒会不会来。

软件中断是程序自己主动触发的，最典型的就是 x86 的int n指令。它同步、可预测，执行到那条指令就一定进中断。早期 Linux 的系统调用就是用int 0x80实现的，后来因为性能问题换成了syscall/sysenter指令。软件中断还有另一个用途，就是在内核里模拟一次中断来做延迟处理。

异常（也叫内中断）是 CPU 在执行指令过程中自己检测到的异常状况，比如除零、访问了非法地址、执行了特权指令。它同样是同步的，但来源是 CPU 内部而不是外部设备。ARM 架构里把复位、未定义指令、数据中止这些都归到异常向量里，和 IRQ、FIQ 放在同一张表上——这也是为什么热词里"stm32调试无法进入中断"这类问题的答案，经常要先分清你说的是外设 IRQ 还是 HardFault。

注意：三者的返回值不一样。硬件中断处理完通常回到被打断的那条指令的下一条；而异常（如缺页）处理完后，往往要重新执行触发它的那条指令，因为异常处理过程可能已经修正了触发条件（比如把页面换进来了）。这个差别在写异常处理程序时是致命的。

1.3 一次中断从触发到返回，中间发生了什么

不管哪种架构，一次完整的中断响应大概都要走这么几步：

1. 设备发起请求。外设把中断状态寄存器的某一位置 1，同时拉高中断线。
2. 中断控制器仲裁。如果同时有多个请求，控制器根据优先级挑一个，把对应的中断号发给 CPU。
3. CPU 保存现场。把当前 PC、状态寄存器、部分通用寄存器压栈。x86 是硬件自动压 EFLAGS、CS、EIP；ARM Cortex-M 是硬件自动压 xPSR、PC、LR、R12、R3~R0 这八个寄存器。
4. 查中断向量表，跳转到 ISR。向量表在内存里的固定位置，每一项 4 字节（32 位系统），存的是 ISR 的入口地址。
5. 执行中断服务函数。读外设状态、清中断标志、搬数据、通知上层。
6. 恢复现场，返回。弹栈，回到被打断的地方继续跑。

第 3 步和第 6 步有个容易忽略的点：保存现场这件事本身就是有成本的。Cortex-M3/M4 硬件自动压 8 个寄存器，大概 12 个时钟周期；如果是带 FPU 的 M4F，在中断里用了浮点指令，还要额外压 17 个寄存器。在 72MHz 的 F103 上，12 个周期约 0.17 微秒，看着不多，但如果你的中断每秒触发十万次，光压栈弹栈就吃掉了 3.4% 的 CPU。这就是"中断优化"这个词的真正含义——不是让中断更快响应，而是让单位时间内中断的总开销降下来。

2. 关中断和开中断：被误解最深的一对操作

2.1 关中断关的是哪一层

初学者对关中断最常见的误解是：以为关了中断，硬件就不产生中断信号了。**并不是。**外设该拉高中断线还是照拉，中断控制器的挂起寄存器该置位还是照置，只是 CPU 核心不再理它了。

真正的动作发生在 CPU 内部的一个状态位。x86 上是 EFLAGS 寄存器的 IF 位（Interrupt Flag），IF=0 表示屏蔽外部可屏蔽中断，IF=1 表示允许。ARM Cortex-M 上是 PRIMASK 寄存器，写 1 表示屏蔽所有可配置优先级的中断（HardFault 和 NMI 不受影响）。ARM 经典核（ARM7/9、Cortex-A）上是 CPSR 的 I 位和 F 位，分别控制 IRQ 和 FIQ。

所以"关中断"准确的说法是"让 CPU 暂时不响应某些中断请求"。请求本身还在，等你开了中断，那些挂起的中断会立刻补上来。这也是为什么关中断时间过长会导致"中断丢失"——如果某个外设只保留一个挂起位，而你在关中断期间事件来了两次，第二次就被覆盖了。

2.2 从汇编指令到内核 API 的封装链条

在裸机上，关中断可能就是一行内联汇编：

/* ARM Cortex-M：写 PRIMASK */ __attribute__((always_inline)) static inline void irq_disable(void) { __asm volatile ("cpsid i" ::: "memory"); } __attribute__((always_inline)) static inline void irq_enable(void) { __asm volatile ("cpsie i" ::: "memory"); }

cpsid i就是 CPSID I 的写法，把 PRIMASK 置 1；cpsie i清零。在 STM32 的工程里，CMSIS 已经封装好了，就是__disable_irq()和__enable_irq()，本质上是同一件事。x86 上对应的就是cli和sti指令。

到了 Linux 内核，这条链条变成三层：

• 最底层是体系结构相关的arch_local_irq_disable()，x86 下就是内联cli，ARM64 下是操作DAIF寄存器的第 7 位。
• 中间层是local_irq_disable()/local_irq_enable()，做了一层宏包装。
• 上层是local_irq_save(flags)/local_irq_restore(flags)，多了一个保存和恢复的步骤。

在 STM32 + FreeRTOS 这种组合里，链条更长：taskENTER_CRITICAL()→portENTER_CRITICAL()→vPortEnterCritical()→__disable_irq()。中间还插了一层uxCriticalNesting++的计数，用来支持临界区嵌套。

2.3 local_irq_save 和 local_irq_disable 的区别，坑就在这

这两个函数看起来差不多，实际用错会导致很难查的 bug。

local_irq_disable()是无条件关中断，local_irq_enable()是无条件开中断。问题在于上下文。假设你的函数被调用时，中断本来就是关着的（比如在另一个临界区里面，或者在中断处理程序里），你调用local_irq_enable()，就把本来不该开的中断给打开了。等函数返回，外层代码以为中断还关着，继续操作共享数据，结果被中断打断——数据就烂了。

local_irq_save(flags)先把当前的中断状态存到flags里，再关中断；local_irq_restore(flags)把flags写回去，恢复成进来时的样子。这样无论进来时中断是开是关，出去时都和进来时一致，可以安全嵌套。

对应的自旋锁家族也是同样的道理，这张表我建议直接背下来：

2.4 关中断窗口能开多大，算一笔账

关中断本身不是罪，关太久才是。到底多久算久？这个得算。

以 115200 波特率的串口为例，一个字节 10 位（1 起始 + 8 数据 + 1 停止），每秒最多传 11520 字节，平均每字节间隔：

1 秒 / 11520 ≈ 86.8 微秒

如果你的 MCU 主频 72MHz，关中断区间里跑了 500 条指令，平均每条指令按 2 个周期算（带 Flash 等待周期的保守估计），关中断时长：

500 × 2 / 72,000,000 ≈ 13.9 微秒

13.9 微秒远小于 86.8 微秒，单字节接收不会丢。但把波特率提到 921600，字节间隔变成 10.85 微秒，13.9 微秒的关中断就会漏掉整整一个字节的起始位——这就是为什么高速串口不能只靠中断接收，必须上 DMA 加空闲中断。

再看 CAN 总线，500kbps 下最长的扩展帧含填充位大约 130 位左右，一帧占用总线时间约 260 微秒，用中断接收完全够。但如果总线上跑 1Mbps 且帧很密集，中断次数会飙升，这时候就要考虑把接收搬到 DMA 或者用 FIFO 加批量中断的方式。

经验值：一般系统里，单次关中断时长控制在10 微秒以内是稳妥的，硬实时场景要求控制在1 微秒以内。Linux 内核里有关中断的调试选项，能直接把最长的关中断区间报出来，这个后面会讲怎么用。

3. 中断控制器和屏蔽机制怎么协同工作

3.1 从 8259A 到 GIC 再到 NVIC

CPU 的中断引脚就那么一两根，但外设的中断源动辄几十上百个，中间的"转换器"就是中断控制器。

PC 时代的 8259A 是级联的，两片芯片合起来能管 15 个中断源，编号 IRQ0 到 IRQ15，IRQ0 给定时器，IRQ1 给键盘，IRQ4 给串口一。中断号直接写死，谁插在哪根线上就是哪个号，特别不灵活。后来被 APIC 取代，可以支持多核、可以动态分配向量。

ARM 服务器和手机用 GIC（Generic Interrupt Controller），分成 Distributor 和 CPU Interface 两部分。Distributor 负责收集所有中断源、根据优先级排队、决定发给哪个 CPU 核；CPU Interface 负责和具体核心对接，处理应答和结束。常见的有 GICv2（最多 8 核）、GICv3（支持上千核，用 GICR 附加寄存器）、GICv4（加上了虚拟化直接注入）。这也是为什么"麒麟操作系统""银河麒麟服务器操作系统"这类国产系统在 ARM 服务器上跑的时候，中断亲和性配置和 x86 完全不一样——你得去/proc/irq/<n>/smp_affinity里改 CPU 掩码。

MCU 这边简单很多，Cortex-M 用的 NVIC 直接集成在核里，最多 240 个外部中断，每个中断有独立可编程的优先级寄存器。再往上一点，TI 的 C2000 系列有个 PIE 模块（Peripheral Interrupt Expansion），把 96 个外设中断源分组复用到 CPU 的 12 条中断线上，每组 8 个源，共用一套使能寄存器——这就是热词里"pie中断"的由来，本质上是中断源比 CPU 中断线多的时候的一种扩展方案。

3.2 屏蔽位其实有三个层级

很多人以为关中断就一个开关，实际上屏蔽发生在三个不同的地方：

**第一层，外设自己的使能位。**比如 USART 的 CR1 寄存器里的 RXNEIE 位，不置 1 的话，接收寄存器非空也不会发出中断请求。这一层决定了"这个事件要不要产生中断"。

**第二层，中断控制器的屏蔽位。**NVIC 的 ISER 寄存器对应每个中断的使能位，GIC 也有对应的 set-enable 寄存器。这一层决定了"产生的中断请求要不要送给 CPU"。注意这一层通常有个"挂起"逻辑：即使你在控制器层面屏蔽了，如果事件已经发生，挂起位会置 1，等你解除屏蔽立刻补一次。

**第三层，CPU 核心的全局开关。**就是前面说的 PRIMASK / IF 位 / DAIF。这一层是"关中断"这个词最常指的东西。

理解这三层之后，很多迷惑就解开了。比如"我在中断里关了中断，为什么另一个中断还能进来？"——因为你只操作了第三层，如果那个中断是 NMI 或者 HardFault，它根本不受 PRIMASK 影响。再比如"为什么我清不掉中断标志？"——可能是外设那一层的使能位没关，事件还在持续产生。

3.3 优先级与嵌套：什么时候高优先级能插队

Cortex-M 的 NVIC 支持中断嵌套，但前提是你允许嵌套。具体规则是：当前正在执行的中断优先级是 P，一个新中断请求的优先级是 Q，只有当 Q 的数值小于 P（数值越小优先级越高）时，才会抢占。

这里有个隐藏条件：如果 ISR 里执行了__disable_irq()，那么无论新中断优先级多高，都不会抢占，直到__enable_irq()或者 ISR 返回。

x86 上情况不同。传统的 PIC 模式下，CPU 响应中断时会自动清 IF 位，也就是说默认不嵌套；如果要在 ISR 里允许被更高优先级中断打断，得手动执行sti。不过现代的 x86 内核普遍采用"中断处理尽量短"的策略，不在 ISR 里做嵌套，而是把耗时工作丢给下半部。

ARM 的 GIC 有个 Group 的概念，GICv3 里把中断分成 Group 0（对应 FIQ，给安全世界/EL3）和 Group 1（对应 IRQ，给普通世界）。Linux 在 ARM64 上跑的时候，内核态通常把 DAIF 的 I 位关掉而不是 F 位，这样 NMI 类的调试中断还能进来，方便定位死锁。

4. 内核里的真实用法：自旋锁、临界区和底半部

4.1 自旋锁为什么要和关中断捆绑使用

自旋锁解决的场景是：两个 CPU 核同时访问同一块数据，或者一个 CPU 核上的进程上下文和中断上下文访问同一块数据。

前一种情况用普通自旋锁就够了，因为它保证了同一时刻只有一个核在临界区里。后一种情况麻烦得多。设想这个序列：

1. 进程 A 拿到了自旋锁，进入临界区，开始修改共享链表。
2. 定时器中断在这颗 CPU 上触发了，ISR 也要访问同一个链表。
3. ISR 尝试拿锁，发现锁被持有，于是自旋等待。
4. 但持锁的是被自己打断的进程 A，进程 A 在 ISR 返回前根本没法继续执行。

死锁。这不是锁的问题，是设计问题：你必须保证中断处理程序不会在持锁期间进来。做法就是在拿锁的同时关掉本地中断，让中断在锁释放之后才可能发生。反过来说，如果中断处理程序也要拿这把锁，那么关中断的窗口就覆盖了整个临界区。

特别注意：关中断只能关本 CPU的中断。另一个 CPU 核照样能来抢锁，所以自旋锁本身还得有原子操作做基础（ARM 上是 LDREX/STREX，x86 上是 LOCK 前缀指令），两者缺一不可。

4.2 上半部和下半部：为什么中断处理程序要短

Linux 把中断处理拆成两半，这个设计不是拍脑袋定的，是被中断上下文的三条限制逼出来的：

• **中断上下文不能睡眠。**它没有 task_struct，调度器不认识它，一旦睡下去就永远醒不来。这意味着不能调用任何可能阻塞的函数，不能拿互斥锁，不能访问可能触发缺页的用户空间指针。
• **中断处理期间，本 CPU 上的中断是关的。**至少同优先级的中断进不来，处理太久会导致丢事件和响应延迟。
• **中断上下文不可重入。**同一中断线在正在处理时默认会被屏蔽，不需要考虑自己重入。

所以上半部（硬中断处理函数）只做最紧急的事：读走硬件里的数据、清中断标志、把数据塞到某个缓冲区，然后触发下半部。真正耗时的解析、协议处理、唤醒用户进程，都放到下半部去做。

下半部有三种主流机制，选择依据是"能不能睡眠"：

线程化中断这几年越来越主流，因为它把"上半部必须极短"这个约束放宽了——耗时代码直接跑在内核线程里，可以睡眠，可以被调度，还能给这个线程设优先级和 CPU 亲和性。代价是多一次上下文切换和唤醒延迟，一般几十微秒量级，对绝大多数外设都够用。

市面上一些现代的操作系统，比如鸿蒙系统在面向设备的版本里，也采用了类似的线程化处理思路，把中断处理放到可调度的任务里，方便做优先级管理和功耗控制。

4.3 抢占、软中断和关中断的边界

还有个概念经常和关中断混淆：抢占禁止（preempt_disable）。

关中断影响的是"外部事件能不能打断我"，抢占禁止影响的是"调度器能不能把我换下去"。在 Linux 上，一个进程被换出去的时机通常是在中断返回时或者显式调用schedule()时，所以如果中断被关了，抢占实际上也间接被禁了。反过来，只调preempt_disable()不关中断，中断还是会进来，只是中断返回时不会触发调度。

在spin_lock的实现里，这两件事都做了：既关抢占，又（在某些变体里）关中断。所以在临界区里调用schedule()会直接报 "scheduling while atomic"，这是内核主动帮你抓 bug。

RTOS 那边逻辑更直白。FreeRTOS 在进入临界区时调vPortEnterCritical()，它会先__disable_irq()，然后操作计数变量，最后如果计数减到 0 就__enable_irq()。所以 FreeRTOS 的taskENTER_CRITICAL()是真的把中断全关了，只留 NMI 和 HardFault。这也是为什么在 FreeRTOS 里做实时性要求高的采集，要特别小心临界区的长度——它直接决定了你的最大中断延迟。

5. 动手实操：Linux 与 STM32 两条路线

5.1 Linux 侧：从 /proc/interrupts 开始观察

任何中断问题的排查，第一步都是看现场。Linux 上最直接的工具是/proc/interrupts：

$ cat /proc/interrupts CPU0 CPU1 0: 23 0 IO-APIC 2-edge timer 1: 4 0 IO-APIC 1-edge i8042 8: 1 0 IO-APIC 8-edge rtc0 16: 8723 0 IO-APIC 16-fasteoi i801_smbus 24: 1245831 0 PCI-MSI 524288-edge eth0-rx-0

输出里每一列的含义要搞清楚：最左边是中断号，中间是各 CPU 上的触发次数，然后是控制器类型和触发方式，最后是注册这个中断的驱动名。几个关键信号：

• 计数完全不涨：中断根本没触发。先查外设使能位、引脚复用配置、时钟是不是没开。
• 计数涨得飞快：可能是电平触发的中断标志没清，导致重复进入。这时候要进 ISR 看清除顺序。
• 全挤在一个 CPU 上：中断亲和性没配好，可以写/proc/irq/24/smp_affinity把负载分散开。

软中断看/proc/softirqs，能看到 NET_RX、NET_TX、TIMER、RCU 这些的分布。如果 NET_RX 数字极高而且集中在 CPU0，通常说明网卡用了单队列或者 RPS 没开。

5.2 写一个能测关中断延迟的内核模块

光看计数器不够，得能量化关中断的时长。Linux 内核自带了 irqsoff tracer，但如果你想在驱动里自己测，可以这么写：

#include <linux/module.h> #include <linux/kernel.h> #include <linux/interrupt.h> #include <linux/ktime.h> static unsigned long flags; static ktime_t t_start, t_end; static int __init irq_lat_demo_init(void) { s64 delta_ns; /* 记录进入关中断前的时间戳，同时关中断并保存原状态 */ t_start = ktime_get(); local_irq_save(flags); /* 这里放你要保护的临界区代码 * 注意：中间绝对不能调用可能睡眠的函数 */ udelay(50); t_end = ktime_get(); local_irq_restore(flags); delta_ns = ktime_to_ns(ktime_sub(t_end, t_start)); pr_info("irq disabled window = %lld ns (%lld us)\n", delta_ns, delta_ns / 1000); return 0; } static void __exit irq_lat_demo_exit(void) { pr_info("irq_lat_demo unloaded\n"); } module_init(irq_lat_demo_init); module_exit(irq_lat_demo_exit); MODULE_LICENSE("GPL");

配套的 Makefile 是标准写法：

obj-m += irq_lat_demo.o KDIR := /lib/modules/$(shell uname -r)/build all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean

编译加载：

make sudo insmod irq_lat_demo.ko sudo dmesg | tail -5

你会看到类似irq disabled window = 52841 ns (52 us)的输出。注意udelay(50)理论上是 50 微秒，实测出来 52 微秒，多出来的部分是ktime_get()本身的开销和函数调用。这说明测量工具自己也会吃掉时间，做精确测量时要把这部分扣掉，或者用更轻量的时间源。

提示：在打开了CONFIG_PREEMPT或者CONFIG_PREEMPT_RT的内核上，local_irq_save未必真的关硬件中断。PREEMPT_RT 把大部分中断转成了内核线程，local_irq_disable变成了只关一个软件标志。所以这套测法在 RT 内核上测出来的数字会小得离谱，别被误导。

5.3 STM32 侧：NVIC 优先级分组与开关中断

裸机这边，先把优先级分组确定下来。Cortex-M 的优先级寄存器有 8 位，但 ST 一般只实现了高 4 位，所以有 5 种分组方式：

/* 4 位全部作为抢占优先级，0~15，可嵌套 */ NVIC_SetPriorityGrouping(NVIC_PriorityGroup_4); /* 2 位抢占 + 2 位子优先级 */ NVIC_SetPriorityGrouping(NVIC_PriorityGroup_2);

抢占优先级决定能不能嵌套，子优先级只在同时挂起时决定先响应谁，不影响嵌套。配置一个串口中断：

/* 使能 USART1 时钟 */ RCC->APB2ENR |= RCC_APB2ENR_USART1EN; /* 使能接收中断 */ USART1->CR1 |= USART_CR1_RXNEIE; /* 设置优先级并开启 NVIC 通道 */ NVIC_SetPriority(USART1_IRQn, 5); NVIC_EnableIRQ(USART1_IRQn); /* 全局开中断 */ __enable_irq();

中断服务函数里，关键是先判断标志、再读数据、最后清标志，顺序错了会导致重复进入：

void USART1_IRQHandler(void) { if (USART1->SR & USART_SR_RXNE) { uint8_t ch = (uint8_t)(USART1->DR & 0xFF); ringbuf_push(&rx_buf, ch); } if (USART1->SR & USART_SR_ORE) { /* 溢出错误：读 SR 再读 DR 即可清除 */ (void)USART1->SR; (void)USART1->DR; } }

这里USART1->SR的判断其实隐含了清标志的动作——读 SR 再读 DR 就自动清了 RXNE。如果你用 HAL 库，HAL_UART_IRQHandler已经把这一套做完了，但 HAL 的分支判断很多，执行时间比手写的裸寄存器版本长不少。对时间敏感的场景，我一般会把 HAL 的中断处理整个替换成裸寄存器版本，实测在 72MHz 下能从 1.8 微秒降到 0.6 微秒左右。

还有个进阶技巧是 BASEPRI。它的作用是"屏蔽优先级数值大于等于某个值的中断"，比 PRIMASK 更细：

/* 只屏蔽优先级 5 及以下（数值更大优先级更低）的中断 */ __set_BASEPRI(5 << (8 - __NVIC_PRIO_BITS)); /* 解除 */ __set_BASEPRI(0);

FreeRTOS 的临界区在 Cortex-M 上用的就是 BASEPRI，它会把你配置的configMAX_SYSCALL_INTERRUPT_PRIORITY写进去，这样高优先级的硬件中断（数值小于这个阈值）不会被屏蔽，保证了紧急中断的实时性。这个设计很巧妙——用一层优先级门槛，换来了"既保护临界区、又不牺牲紧急中断"的效果。

5.4 用 trace 定位关中断过长的元凶

系统卡顿、串口丢包、音频爆音，如果怀疑是关中断太久，Linux 上有现成的工具链：

# 查看当前可用的 tracer sudo cat /sys/kernel/debug/tracing/available_tracers # 开启 irqsoff tracer echo irqsoff | sudo tee /sys/kernel/debug/tracing/current_tracer echo 1 | sudo tee /sys/kernel/debug/tracing/tracing_on # 跑一段业务，然后关掉 echo 0 | sudo tee /sys/kernel/debug/tracing/tracing_on # 看结果 sudo cat /sys/kernel/debug/tracing/trace

输出会直接告诉你最终延迟是多少微秒，以及从关中断到开中断之间调用栈长什么样。下面还会有一个max_latency文件，记录历史最大延迟。我在一台 ARM 服务器上排查网络抖动时，就是用这个方法定位到某个驱动在 ISR 里做了一次 200 微秒的memcpy，把它挪到工作队列之后，最大延迟从 210 微秒降到 8 微秒。

STM32 那侧没有这么强的工具，但有替代方案：用一个空闲的定时器做微秒级计时，在中断入口和出口分别打时间戳存到环形缓冲区，跑一段时间再 dump 出来分析。更省事的办法是用 GPIO 翻转配合逻辑分析仪或者示波器，进 ISR 拉高，出 ISR 拉低，直接看波形占空比。这个方法虽然原始，但最直观，测抖动也最准。

6. 常见问题与排查速查表

6.1 典型症状对照表

下面这张表是我这些年攒下来的经验，按症状反查原因，能省不少时间：

6.2 我踩过的几个坑

第一个坑是在中断里用了打印。裸机上用printf，如果底层是阻塞式串口发送，一个 20 字节的字符串在 115200 下要 1.7 毫秒，如果你的中断每秒来几千次，系统直接瘫。后来全改成往环形缓冲区里塞数据，主循环再打印，问题解决。Linux 上一个类似的坑是在 ISR 里用printk，虽然printk不睡眠，但输出到串口控制台同样会阻塞很久，内核有printk限流机制，但最好还是换成printk_deferred或者干脆不打。

第二个坑是用local_irq_enable而不是local_irq_restore。当时写的驱动在处理流程里调了local_irq_disable()，处理完调local_irq_enable()。测试的时候一切正常，直到把这个函数被另一个也在临界区的路径调用，立刻出现随机崩溃。改法很简单，全部换成local_irq_save(flags)/local_irq_restore(flags)，保存和恢复成对出现。

第三个坑是在 ISR 里操作共享数据但没加锁。这个错误的隐藏性很强，因为大部分时候看着是好的——直到某次中断恰好落在主循环修改链表的中间那一刻，指针就飞了。这类 bug 复现率极低但后果严重，正确做法是把共享数据放进临界区，或者用无锁的单生产者单消费者环形缓冲区。

第四个坑是关中断期间调用了带内存分配的函数。哪怕只是一个看起来人畜无害的malloc，它内部可能持有自己的锁，可能触发页面分配，可能在慢路径里睡眠。一旦睡眠，关中断就变成了永久关中断，整个 CPU 就废了。我现在写代码的习惯是，任何进临界区之前先在心里过一遍：这块代码会不会睡、会不会分配内存、会不会调外部模块。

还有一个不算坑但值得说的点：不是所有场景都需要关中断。如果共享数据只有一个写者（中断）和一个读者（主循环），而读者只关心数据的完整性可以用双缓冲或者序号校验，那完全可以不关中断，用无锁方式解决。关中断是个重武器，能不用就不用，用之前先想清楚有没有更轻的方案。

对于国产操作系统生态，我看到的一个变化是越来越多的实时场景开始用 Linux 加 RT 补丁，或者用国内厂商做的实时内核。这类内核对关中断的处理和标准内核差别不小，很多操作变成了对软件状态的操作，测出来的延迟数字漂亮但语义变了。做实时性评估的时候，光看关中断的耗时数字是不够的，还要看最坏情况下的调度延迟和中断线程的唤醒时间，这两个才是决定端到端响应的关键指标。我在一个数据采集项目里就吃过这个亏，原先按最长关中断 5 微秒估算没问题，实测丢包才发现中断线程被一个低优先级任务压了 300 微秒，后来把中断线程优先级提到最高才解决。