4. 优先级调度：优先级定义与反转、动态优先级调整、优先级继承协议
好，咱们来聊聊优先级调度。说实话，这是多线程任务调度里最让人头疼的一块。我见过不少系统，明明设计时觉得优先级定得挺合理，一跑起来就出各种幺蛾子。今天我把这些年踩过的坑和总结的经验，一次性讲清楚。
4.1 优先级定义：别想当然
优先级怎么定？很多人觉得数值越大优先级越高，或者反过来。其实这都不重要，重要的是——整个团队必须统一。我个人习惯用「数值越小优先级越高」的方案，因为Linux内核就是这么干的，看代码时不容易混淆。
但真正要命的是：优先级不是拍脑袋定的。你得根据任务的实时性要求来。比如：
- 硬实时任务：比如刹车控制，优先级最高，必须抢占一切
- 软实时任务：比如视频播放，优先级中等，偶尔延迟可以接受
- 普通任务：比如日志写入，优先级最低，有空再干
核心原则：优先级代表的是「如果发生冲突，谁先执行」，而不是「谁更重要」。这两个概念有本质区别。
我在项目中遇到过一件事：有个同事把UI刷新线程的优先级设得比网络接收还高。结果网络数据一直丢包，UI倒是刷得飞快——但显示的都是旧数据。你想想看，这有什么意义？
4.2 优先级反转：经典坑王
优先级反转，说白了就是低优先级任务把高优先级任务给堵住了。听起来很反直觉对吧？但现实中经常发生。
典型的场景是这样的：
- 任务L（低优先级）拿到了一个共享锁
- 任务H（高优先级）来了，想拿同一个锁，但被L占着，只能等
- 任务M（中优先级）来了，它不需要锁，直接抢占L开始跑
- 结果呢？H被L堵着，L又被M堵着。H明明优先级最高，却要等M跑完才能执行
这就是优先级反转。我曾经在一个嵌入式项目中遇到过类似问题，一个高优先级的传感器数据采集任务，硬生生被一个中优先级的日志任务拖了200毫秒。200毫秒啊，在实时系统里简直是天文数字。
注意：优先级反转不是理论问题，是真实存在的。而且越复杂的系统，越容易发生。不要以为你的系统简单就没事。
4.3 动态优先级调整：灵活但别乱来
静态优先级有个问题：太死板。任务的行为是会变的，比如一个任务刚启动时需要快速响应，但稳定后就没那么急了。这时候就需要动态调整优先级。
常见的策略有：
- 基于等待时间：等得越久，优先级越高。防止饥饿
- 基于执行时间：跑得越久，优先级越低。公平调度
- 基于事件触发：收到紧急事件时临时提升优先级
我建议你记住一点：动态调整要有限度。别把优先级调来调去，最后系统自己都搞不清楚谁该先跑。我见过一个系统，动态优先级调整的逻辑比业务逻辑还复杂，结果出了bug根本查不出来。
我的经验：动态优先级调整最好只用于「临时提升」，不要频繁降低。降低优先级容易导致任务被饿死，而且很难排查。
4.4 优先级继承协议：解决反转的利器
优先级反转怎么治？最经典的办法就是优先级继承协议。
它的核心思想很简单：当低优先级任务持有高优先级任务需要的锁时，临时把低优先级任务的优先级提升到高优先级任务的级别。这样中优先级的任务就没法插队了，高优先级任务就能尽快拿到锁。
具体流程是这样的：
- 任务L拿到锁，优先级为5
- 任务H来了，需要同一个锁，优先级为10
- 系统发现H在等L，于是把L的优先级临时提升到10
- 任务M（优先级8）来了，发现L的优先级是10，抢不过，只能等
- L释放锁后，优先级恢复为5，H拿到锁开始执行
你看，这样H就不会被M堵住了。
关键点：优先级继承是临时的，锁释放后必须恢复原优先级。否则低优先级任务会一直以高优先级运行，那就乱套了。
我在项目中用过优先级继承协议，效果确实好。但要注意一点：它只能解决「锁导致的优先级反转」，解决不了「资源竞争导致的优先级反转」。比如两个任务抢CPU缓存，优先级继承就帮不上忙。
4.5 实战建议：别让优先级成为你的噩梦
最后，我总结几条实战建议：
- 优先级数量别太多：我一般控制在8级以内。太多级反而增加调度开销和复杂度
- 明确优先级映射关系：每个优先级对应什么类型的任务，写文档记清楚
- 测试优先级反转场景：写单元测试时，专门构造反转场景，验证你的协议是否生效
- 监控优先级变化：上线后要能实时看到每个任务的当前优先级，方便排查问题
避坑指南：我曾经在一个项目中，因为优先级继承协议实现有bug，导致锁释放后优先级没恢复。结果一个低优先级任务一直以高优先级运行，把其他实时任务全堵死了。排查了整整两天才找到原因。所以——一定要验证锁释放后的优先级恢复逻辑。
嗯，优先级调度这块就讲这么多。说白了，优先级就是个「谁先谁后」的问题，但搞不好就会让系统崩溃。记住：优先级是工具，不是目的。你的目标是让系统稳定、高效地运行，而不是把优先级调得花里胡哨。