嵌入式任务为何饿死？优先级怎么封顶？

系统卡住时，CPU 利用率常常并不高，真正出问题的是关键任务再也抢不到自己该有的窗口。嵌入式调度只要让优先级关系失真、执行时间预算失控，高优先级任务就可能在统计上一直存在，却在现场意义上已经被饿死。

优先级反转最典型的场景不是三段教材示意，而是低优先级任务拿着共享资源做了本不该在锁内做的慢操作。高优先级控制任务被这把锁挡住，中优先级通信或日志任务又不断抢占低优先级持锁者，于是高优先级反而要等更久。问题难查在于它并非每次都触发，只有当报文高峰、存储访问或某类回调刚好插进来时才会爆发，所以看起来像偶发卡顿。若再叠加中断里唤醒多个任务、锁粒度过粗或驱动层与业务层共用同一互斥，等待链会比代码表面长得多。有些系统还把喂狗任务设得太低，结果最先失联的反而是故障指示本身。

互斥继承能缓解一部分反转，但前提是锁边界本身合理。把可阻塞 IO、格式化输出、内存申请和外部回调放进锁里，再高级的内核策略也只是替一段坏临界区兜底。更有效的办法通常是拆分共享数据与慢操作，先在锁内复制最小状态，再把耗时动作挪到锁外；对单生产者单消费者路径，则优先改成无锁队列或事件通知。嵌入式系统真正需要封顶的不是名义优先级，而是任何共享路径能把高优先级任务拖住多久。

最坏执行时间则决定你算出来的周期任务是否真的装得下。很多团队用一次平均测量就给任务下结论，结果空载时每个任务都很快，一上实机却发现周期被慢慢侵蚀。缓存未命中、分支极端路径、DMA 完成回调扎堆、外设超时重试，都会让一次调度片里的执行时间比平时长得多。只要某个高频任务偶尔超出自己的预算，它就会挤压后面的同级或低级任务；若这些任务又负责释放缓冲、喂狗或维护状态，连锁反应很快就会把整机拖进假死边缘。

因此，封顶优先级不能只靠把关键任务设成最高，而要把每条周期链都换算成可验证的时间账。先定义控制、通信、存储和后台维护各自允许占用的最坏时隙，再根据依赖关系安排相位，必要时让非关键任务主动降级或丢弃部分工作，而不是硬挤进同一周期。预算里还要给偶发异常处理留余量，不能把周期填到只剩理论缝隙。只要预算清楚，就能判断该优化哪一段；预算不清楚时，所有“偶发卡顿”都会被误认为是内核不可控。

排查时最好抓任务切换轨迹，而不是只看 CPU 百分比。记录任务就绪、运行、持锁和超时事件，再和看门狗喂狗点、缓冲高水位或控制环错周期时刻对齐，往往能直接看到是哪一段执行时间越界，或者哪一把锁在放大反转。否则轨迹上只会留下一串来不及解释的超时。许多所谓随机死机，最后都能还原成一条具体的等待链。

所以，任务饿死通常不是因为系统不忙，而是因为忙的方式没有上限。把锁内慢操作拿掉，再把最坏执行时间当成真约束，调度才会稳。