嵌入式 FreeRTOS 必备 20 道常考题目总结：任务调度、同步机制与内存可靠性

《面试题目》

1. 什么场景适合上 FreeRTOS，什么场景继续裸机更合适？
2. FreeRTOS 的任务状态有哪些，分别在什么条件下切换？
3. 任务优先级怎么定，优先级反转通常怎么出现、怎么缓解？
4. xTaskCreate 时栈大小怎么估，栈溢出怎么排查？
5. SysTick、PendSV、SVC 在 FreeRTOS 调度里分别起什么作用？
6. 抢占式调度和时间片调度有什么区别，你们项目用的是哪种？
7. vTaskDelay 和 vTaskDelayUntil 有什么区别，绝对周期任务怎么做？
8. 中断里能不能调用普通阻塞 API，ISR 专用接口有哪些限制？
9. 临界区 taskENTER_CRITICAL 和关中断有什么区别，各自适用场景？
10. 队列、信号量、互斥量、事件组分别适合解决什么问题？
11. 二值信号量和互斥量有什么本质区别，为什么互斥量通常带优先级继承？
12. 生产者消费者模型用队列怎么设计，队列满/空时怎么处理？
13. 任务通知（Task Notification）适合替代哪些轻量同步场景？
14. 同一个外设被多个任务访问时，驱动层通常怎么做互斥？
15. FreeRTOS 里出现死锁，常见原因有哪些，怎么避免？
16. 内存分配用堆还是静态创建，FreeRTOS 几种 heap 方案怎么选？
17. 什么是优先级继承，能解决什么问题，解决不了什么问题？
18. 看门狗和 FreeRTOS 任务监控一般怎么配合，如何发现任务卡死？
19. 低功耗场景下，Tickless Idle 解决什么问题，会带来哪些代价？
20. 如何证明你们系统实时性达标，常用哪些指标和测试方法？

《参考解析》

第一层：先答「为什么是 RTOS」，再答「任务怎么拆」

「什么场景该上 RTOS」考的是判断边界，不是背优点。裸机适合逻辑固定、模块少、时序宽松的系统——按键扫描、单路采集、简单控制。一旦通信、存储、显示、算法、低功耗同时出现，主循环的问题就是结构性的：所有事排队执行，一个阻塞点拖慢整条链路；时序靠「先调通再说」，后期没人敢改；偶发卡死分不清是业务 bug 还是调度问题。RTOS 给的不是「多开几个线程」，而是一套可讨论的并发模型：任务、优先级、阻塞、同步、超时、资源保护。答的时候拿自己项目的模块数和响应指标做对照，比背定义有说服力。

任务划分的判据是时间尺度与阻塞特性，不是功能名词。10ms 采样、1s 上报、30ms 刷屏是三个节奏；某段逻辑里有 Flash 擦写或等串口回包，就必须独立成任务或改异步，不能塞进高频任务。按触发源、按数据流（采集→处理→上传用队列串起来）拆也常用，但要主动说清「为什么不再细分」——任务越多，栈开销、切换开销、共享数据都越多。优先级按截止时间排，不是按业务重要性排；FreeRTOS 数值越大优先级越高，上限是 configMAX_PRIORITIES，同优先级再按时间片轮转。

第二层：优先级反转与栈溢出，两条最常被追到底的排障线

优先级反转的完整链条：低优先级任务持有互斥量 → 高优先级任务就绪、等这把锁 → 中优先级任务就绪并抢占低优先级 → 高优先级被一个与它无关的任务间接拖住。缓解靠优先级继承：持锁方临时被抬到等待者的优先级，尽快释放，FreeRTOS 用 xSemaphoreCreateMutex 创建的互斥量默认带这一机制。但要讲清边界——继承只压缩「持锁期间被抢占」这段窗口，解决不了死锁、持锁时间过长和多级链式反转，根治办法是尽量不共享，让一份状态只被一个任务拥有。

栈估算靠三件事叠加：静态估算（沿最深调用链累加局部变量、数组、浮点上下文和库函数开销，printf、sprintf 很吃栈）、实测高水位（跑一段时间后读 uxTaskGetStackHighWaterMark）、留余量（按高水位 1.5 倍以上）。溢出排查把 configCHECK_FOR_STACK_OVERFLOW 开到 2，切换时检查栈指针越界，再实现 vApplicationStackOverflowHook 打出任务名。现场常常不是干脆崩溃，而是跑几小时后无关变量被改写、HardFault 随机出现——要能直接联想到栈。

第三层：同步机制选型，看传不传数据、有没有所有者、能不能进中断

分工一句话切开：传数据用队列（值拷贝、长度固定、自带缓冲）；只通知「发生了」用信号量；保护被多任务改写的资源用互斥量；等多条件任一或全部满足用事件组。二值信号量与互斥量的本质差别在所有权：信号量谁都能给、谁都能拿，适合任务与中断同步；互斥量有持有者概念，只能由持锁者释放，才能做优先级继承，也因此不能在中断里用。任务通知更轻，每任务一个 32 位值，省掉队列对象和一次拷贝，但只能一对一，做不了广播。

生产者消费者真正被追问的是满/空怎么办：发送带超时（满则等待或按业务分级丢弃）、接收阻塞等待避免空转；中断里用 FromISR 版本，配合 xHigherPriorityTaskWoken 和 portYIELD_FROM_ISR 决定是否立刻切换。同一外设被多任务访问，驱动层把「获取设备」做成拿互斥量、读写收进同一临界区，业务代码统一走这层，而不是各自加锁。死锁常见于加锁顺序不一致、持锁调用阻塞接口、中断与任务抢同一把锁，对策是全局约定顺序、临界区内不做阻塞操作、超时获取当兜底。

第四层：中断与临界区，以及怎么证明系统「实时」

中断里不能调普通阻塞 API，因为它们内部可能进临界区、可能挂起当前任务，而中断上下文没有任务控制块可挂。ISR 只能用 FromISR，且中断硬件优先级必须不高于 configMAX_SYSCALL_INTERRUPT_PRIORITY（Cortex-M 上数值更大等于逻辑优先级更低），否则内核的保护盖不到它，会直接破坏内核数据结构——这个方向是高频扣分点。taskENTER_CRITICAL 与关中断的差别在作用范围：前者只把 BASEPRI 抬到该优先级，屏蔽受内核管理的中断、支持嵌套计数；后者关掉所有可屏蔽中断，连不该受影响的实时中断一起延迟。所以临界区只保护几条指令级别的共享状态，绝不在里面做长外设操作或打印。

实时性要落到可测的量：中断延迟、任务切换时间、最坏响应时间。在中断入口和任务里翻转 GPIO，用示波器或逻辑分析仪读时间差，或用 DWT 周期计数器打点；报最坏值而不是平均值，再配长时间压测看栈高水位与丢包计数。Tickless Idle 则是取舍题：关掉周期 tick 让 MCU 睡到下一个任务到期，省电的代价是精度依赖低功耗定时器、唤醒有额外延迟、tick 补偿容易写错。