4.3 死锁与优先级反转攻防

4.3 死锁与优先级反转攻防

本节摘要：死锁与优先级反转是任务协作失败的两个极端形态：前者让大家永远等下去，后者让高优先级任务被低优先级任务「绑架」。本节还原经典故障的完整过程，给出两种反转解法的差异与死锁的预防纪律，并整理现场识别特征。

一九九七年夏天，火星表面的探路者号探测器在着陆几天后开始反复自发重启，地面团队看着遥测数据里的系统复位记录一筹莫展。最终身在地球的工程师通过复现找到了元凶：互斥量上的优先级反转，而修复方式只是在配置里打开一个当时默认关闭的优先级继承开关。这个案例后来成了实时系统课程的必修内容——它证明优先级反转不是教科书里的理论怪物，而是能让数亿美元任务当机的现实威胁。本节负责把这两类故障拆到机制层：怎么发生、怎么解、现场长什么样。

优先级反转：完整过程还原

设置三个任务：高优先级的通信任务 H、中优先级的两个常规任务 M、低优先级的数据记录任务 L，外加一个三者共用的互斥量。故障按五步展开：L 先拿到互斥量开始写记录文件；L 尚未释放时 H 就绪，抢占 L 后请求同一把锁，进入阻塞等锁；此刻 L 本应继续跑到释放锁为止，但 M 恰好就绪，L 优先级低于 M，被 M 抢占；M 可能要跑很久（它甚至与这把锁毫无关系），L 被无限期压在后面；结果是 H 的截止期被一个「与己无关」的中优先级任务决定——优先级的秩序被倒了过来。

按 3.2 节的响应时间公式看，这笔账本不该存在：公式的干扰项只统计高优先级任务，而反转引入了「低优先级持有资源」这条隐性延迟路径。这就是它危险的原因——所有常规分析都会漏掉它，它只在特定的调度交错下现身。

两种解法：继承与天花板

解法一，优先级继承：H 等锁的瞬间，内核把持有者 L 的优先级临时提升到 H 的级别，M 再也压不住 L，L 全速跑到释放锁的那一刻，随后恢复原优先级。它的优点是按需触发、无锁时零开销；缺点是应对不了更复杂的链——若 L 持有的另一把锁又牵扯第三方任务，继承链条可能出现死结。探路者号的修复用的就是它。

解法二，优先级天花板：给每把锁预设一个「天花板」优先级（等于所有可能锁定该资源的任务的最高优先级），任务一旦拿到锁，立刻被提到天花板高度，不管有没有人在等。它的优点是简单粗暴且可静态推演——拿到锁的瞬间起，反转在任何交错下都不可能发生，这正是安全标准偏爱它的原因；缺点是即使无人竞争也付出提升代价，且天花板值需要随系统演进而维护，配低了照样反转。

两者工程上如何选：竞争频繁、锁关系简单的系统用继承，按需付费；功能安全项目或锁关系复杂的系统用天花板，把正确性交给静态规则。FreeRTOS 的互斥量默认实现继承协议，天花板协议在安全扩展版本中提供。

/* 反转防线：创建互斥量时确认继承行为已启用 */
xConfigMutex = xSemaphoreCreateMutex();      /* 自带优先级继承 */
/* 反面教材：用二值信号量充当锁——没有持有者，继承无从谈起 */
xLockSem = xSemaphoreCreateBinary();
xSemaphoreGive(xLockSem);                    /* 「锁」初值给上，埋雷开始 */
​

反面教材那两行值得抄进团队的代码规范负面清单：它编译无警告、运行大多数时候正常，正是反转最喜欢的藏身处。

死锁：成环的等待

死锁的机制表述：若干任务各自持有资源，又互相等待对方手里的资源，等待关系构成环，谁也不肯（也不能）先放手。要成环需要四个条件同时成立——资源互斥、持有且再等待、资源不可被强行剥夺、等待关系闭环。破坏其中任何一个都能解开死锁，工程上最实用的是破坏「闭环」：全系统规定统一的加锁顺序，所有任务都按同一顺序获取多把锁，环在构造上就画不出来：

/* 纪律：先 A 后 B，全系统一致 */
void vSafeTransfer(void)
{
    xSemaphoreTake(xQueueLockA, portMAX_DELAY);
    xSemaphoreTake(xStatsLockB, portMAX_DELAY);
    /* ... 同时改动两处共享数据 ... */
    xSemaphoreGive(xStatsLockB);
    xSemaphoreGive(xQueueLockA);
}
​

第二条防线是限时等待：所有 Take 调用带超时而非永久等待，拿不到就释放已持有的锁、退避重试。超时把「永久的环」变成「可恢复的冲突」，代价是路径里多出重试逻辑。两条防线不冲突：顺序纪律防患于未然，超时退避兜底意外。顺带一提，递归互斥量解决的是「同任务重复加锁」的计数问题，与死锁无关，别混淆。

现场：这两类故障长什么样

优先级反转的现场特征：高优先级任务周期性超时，超时时刻随机、与自身负载无关；跟踪时间线上能看到它阻塞在一个互斥量上，而持有者是个低优先级任务，两者之间还夹着别的任务在跑。若系统配了看门狗，往往表现为「几天一次的神秘复位」，复位后一切正常——探路者号的地面团队面对的就是这个画面。

死锁的现场更安静：相关任务集体消失在调度里，其他任务照常运行，系统表现为「某个功能永久失灵」而不是变慢。用运行时统计接口一查，那几个任务的等待计数永远在涨、执行计数纹丝不动，等待的内核对象用对象查询接口列出来，环一目了然。

第九章的复盘案例会再次回到这两类现场，届时配合跟踪工具逐帧分析。此刻先记住操作顺序：先开继承（或改天花板），再查锁顺序，最后给所有等待加时限——三步走完，第四章的故障清单基本清零。

本节要点回顾

• 反转的必要条件：低优先级持锁、高优先级等锁、中间另有任务就绪；
• 优先级继承按需提升持有者，天花板拿锁即提升，后者更利于静态论证；
• 用信号量充当锁是最常见的反转入口，代码规范必须点名禁止；
• 死锁四条件中破坏闭环最实用：全系统统一加锁顺序；
• 限时等待加退避重试是第二道防线，把死等改成可恢复冲突；
• 反转现场是「随机超时加神秘复位」，死锁现场是「功能静默失灵」。

常见问题

问：优先级继承会永久改变任务优先级吗？ 不会，继承是临时的：持锁期间提升、释放即恢复。正因为是临时行为，它的静态分析也比天花板复杂——要遍历可能的继承链，这也是安全标准更偏爱天花板的原因。

问：死锁超时该设多长？ 数量级参考「正常持锁时长的数十倍」：太短会频繁误判重试，太长则退避失去意义。超时触发后除了退避，务必记日志——频繁触发的超时是锁设计问题的信号，不是重试能吸收的噪声。

问：怎么向外行解释火星探路者事故？ 一句话版本：一个低优先级任务拿着「钥匙」干慢活，高优先级任务干等着，中间还有别的事插队——最后看门狗忍不住把整个系统重启了。修复只是让拿钥匙的人临时升级到等钥匙者的地位。

问：自旋锁在这里为什么没出场？ 任务世界的锁都该是阻塞型，自旋烧处理器毫无收益；自旋锁属于多核核间同步（7.1 节），单核任务用它等于空转。分清两者的适用域，能避免一类低级事故。