【一文吃透】FreeRTOS之优先级反转
1. 什么是优先级反转？
优先级反转是指：
高优先级任务因为等待低优先级任务持有的资源，导致实际执行被中优先级任务阻塞，从表现上看高优先级任务被低优先级任务 “压住了”。
2. 优先级反转完整时序分解
2.1 前提假设
假设有 3 个任务和 1 个用信号量保护的共享资源：
表格
| 任务 | 优先级 | 说明 |
|---|---|---|
| H（High） | 高 | 需要访问共享资源 |
| M（Medium） | 中 | 不需要访问共享资源 |
| L（Low） | 低 | 先持有共享资源 |
2.2 时序分解
阶段 1：L 开始运行，拿到资源
- 时刻 1：只有 L 就绪，L 开始运行；
- 时刻 2：L 执行
xSemaphoreTake(xSem)，成功持有资源。
text
L: ████████████... （持有资源，持续运行） H: M:阶段 2：H 变为就绪，抢占 CPU
- 时刻 3：H 变为就绪态（比如某事件触发）；
- H 优先级最高，立即抢占 L 的 CPU 执行权；
- L 被挂起，但仍持有信号量。
text
L: ████████▌ （被抢占，但还持有 xSem） H: ████...（抢占 CPU，开始运行） M:阶段 3：H 也要这个资源，被阻塞
- 时刻 4：H 执行
xSemaphoreTake(xSem, MAX_DELAY)； - 发现 xSem 被 L 持有，拿不到；
- H 进入阻塞等待。
text
L: ████████▌ （仍持有 xSem，等待 CPU） H: ▌ （阻塞，等 xSem） M:阶段 4：M 趁机运行，长期占用 CPU（这就是优先级反转！）
- 时刻 5：此时就绪队列里只有 M 和 L（H 阻塞了）；
- M 优先级比 L 高，M 开始运行；
- M 不需要 xSem，所以它可以一直跑。
问题来了：
- L 没有 CPU，无法释放 xSem；
- H 等着 xSem，无法继续；
- M 反而在一直运行。
text
L: ████████▌ （等 CPU，无法释放 xSem） H: ▌ （等 xSem） M: ████████████████ ...（一直运行，压住 L）从结果上看：
- H 是最高优先级，理应最先运行；
- 但 H 实际上被 M 压住了；
- 而 M 的优先级比 H 低。
表现形式：中优先级任务的运行时间变相 “凌驾” 于高优先级任务之上。
阶段 5：M 最终结束，L 才能拿到 CPU
- 时刻 N：M 执行完或阻塞，L 才得以恢复执行；
- 时刻 N+1：L 释放 xSem；
- 时刻 N+2：H 终于拿到 xSem，继续运行。
text
L: ████████▌ ██（执行并释放 xSem） H: ▌ ████（终于能运行） M: ██████████（中间一直跑）3. 优先级继承是怎么解决这个问题的？
如果把上面的xSem换成互斥信号量（Mutex），内核会加入优先级继承机制：
3.1 核心逻辑
当阶段 3 发生后（H 阻塞等 Mutex），内核检测到：
- H 在等这个 Mutex；
- 这个 Mutex 的持有者是 L；
- L 的优先级比 H 低。
于是内核做这件事：
临时把 L 的优先级提升到和 H 相同（继承 H 的优先级）。
3.2 结果
- L 原来优先级：低；
- L 继承后优先级：高（与 H 相同）；
- L 优先级提高，M 无法压住 L；
- L 能尽快释放 Mutex，H 能尽快拿到资源。
text
L: ████████▌ ████（优先级提升后，L 能抢到 CPU，继续释放 Mutex） H: ▌ ████（L 释放后，H 立即运行） M: ▌ （M 抢不过 L，被挤后面了）3.3 后续处理
- L 释放 Mutex 后；
- H 立刻拿到 Mutex，继续执行；
- L 的优先级恢复到原来的低优先级；
- M 才开始运行。
4. 优先级继承 vs 普通二值信号量：效果对比
表格
| 维度 | 使用 Binary Semaphore | 使用 Mutex（优先级继承） |
|---|---|---|
| 中优先级任务 M | 可以长期运行，H 被间接延误 | L 被临时提升，M 被挤后面 |
| 高优先级任务 H 的实时性 | 无法保证 | 能尽快获得资源，实时性更好 |
5. 为什么优先级继承不是完美方案？
优先级继承只是缓解，不是根治，它还有以下局限：
5.1 只能解决单级继承问题
如果有多个 Mutex 嵌套，优先级继承可能不完整，需要更复杂的机制（如优先级天花板协议）。
5.2 不能解决死锁
两个任务互相持有对方需要的 Mutex：
- A 持有 mutex1，等 mutex2；
- B 持有 mutex2，等 mutex1。
这是死锁，优先级继承解决不了。
5.3 FreeRTOS 的优先级继承有限
FreeRTOS 的 Mutex 优先级继承是基础实现，只处理最常见的单 Mutex 场景，在复杂嵌套场景下不保证完全正确。
文档里也明确说了：
FreeRTOS 的 mutex 优先级继承不是完整的优先级反转解决方案。
6. 实际工程建议
表格
| 场景 | 推荐用什么 |
|---|---|
| 任务间通知、ISR 通知任务 | Binary Semaphore / Task Notification |
| 保护共享资源 | Mutex |
| 保护共享资源且任务可能嵌套加锁 | Recursive Mutex |
| 对实时性要求极高 | 考虑优先级天花板协议（FreeRTOS 不内置，需自行设计） |
7. 一句话总结
Binary semaphore 没有所有权概念，内核不知道资源被谁持有，所以无法做优先级继承；Mutex 记录了持有者，内核可以在高优先级任务等待时临时提升持有者优先级，让它尽快释放资源，从而缓解优先级反转问题。