大家好，我是一个爱分享的牛马程序员，工作中碰到，加上自己理解，很高兴给大家分享。
-begin-
题目：为何给进程设置了高优先级（如nice -n -20），却仍可能被低优先级进程抢占CPU？如何确保实时任务优先执行？
分析流程：
1.现象解析：很多开发者认为“优先级高的进程一定先执行”，但实际中高优先级进程可能因IO阻塞、时间片耗尽等原因被低优先级进程“抢”走CPU，尤其在实时性要求高的场景（如车载控制系统），这种“不可预测性”会导致严重问题。
2.深层原因：
Linux默认的CFS（完全公平调度器）是“按比例分配CPU时间”的调度器，而非严格的“优先级抢占”调度器，核心机制导致优先级的作用被限制：
◦CFS的公平性：CFS通过计算进程的“虚拟运行时间”分配CPU，优先级高的进程虚拟时间增长慢，能获得更多CPU时间，但不会完全剥夺低优先级进程的运行机会（除非设置了实时优先级）。就像VIP客户能多占用服务时间，但普通客户也能轮到服务，不会一直等；
◦阻塞与调度切换：高优先级进程若执行IO操作（如read、sleep）会主动放弃CPU，此时低优先级进程可趁机运行；即使不阻塞，CFS也会在时间片耗尽后切换进程，避免单一进程独占CPU；
◦优先级范围的误解：nice值范围是-20~19（值越小优先级越高），但这属于“静态优先级”，仅影响CFS的调度权重，而实时进程的优先级（1~99）才会触发严格的优先级抢占。
我之前在开发车载CAN总线数据处理模块时，就因优先级设置踩过坑：给数据解析进程设了nice -n -20，但在系统负载高时，仍会被其他进程打断，导致数据处理延迟超过100ms。后来将其改为实时优先级（chrt -f 50），延迟才稳定在10ms以内——这就是普通优先级和实时优先级的本质区别。
3.确保实时任务优先的措施：
◦使用实时调度策略：将关键任务设置为SCHED_FIFO（先进先出）或SCHED_RR（时间片轮转）实时策略，优先级1~99，此时高优先级实时进程会完全抢占普通进程和低优先级实时进程：
# 用chrt命令设置实时优先级（50） chrt -f 50 ./realtime_task |
代码中设置：
struct sched_param param; param.sched_priority = 50; // 实时优先级50 if (sched_setscheduler(0, SCHED_FIFO, ¶m) == -1) { perror("设置调度策略失败"); } |
◦避免实时进程阻塞：实时进程应尽量避免IO操作、内存分配（可能休眠），确保“可运行”状态，否则会被低优先级实时进程抢占；
◦控制实时进程数量：过多高优先级实时进程会导致低优先级实时进程“饿死”，需按任务重要性合理分配优先级（如刹车控制>空调调节）；
◦使用RT_PREEMPT内核：普通Linux内核的部分代码（如自旋锁）不可抢占，RT_PREEMPT补丁可将内核大部分代码改为可抢占，降低实时任务的调度延迟。
普通优先级与实时优先级的核心区别：
•普通优先级（nice值）：影响CPU时间占比，无法保证绝对优先，适合非实时任务；
•实时优先级（1~99）：严格按优先级抢占，高优先级任务不主动放弃CPU就会一直运行，适合毫秒级甚至微秒级实时需求。
结论：在嵌入式实时系统（如汽车、工业控制）中，仅靠nice调整优先级无法满足实时性要求，必须使用实时调度策略和优化的内核。记住：优先级的“高低”不是绝对的，要看调度器类型——CFS追求公平，实时调度器追求“紧急任务优先”，选择哪种调度方式，取决于任务是否容不得一丝延迟。
-end-
如果文章对你有提升，帮忙点赞，分享，关注。十分感谢
