优必选嵌入式软件面经：优先级反转与项目代码拷问

《面试题目》

1. 自我介绍
2. 面试官要求共享屏幕看代码，并针对代码中的问题进行提问
3. 代码中有哪些可以优化的地方？
4. 优先级反转
5. 优先级继承
6. 第二个项目中任务是怎么划分的？
7. 数据链路

面试官的建议：这个岗位 hc 较少且主要做应用，如果做的是偏底层方向，可以考虑投芯片原厂。

《参考解析》

1. 共享屏幕看代码这种形式，要提前把项目代码本身准备好：面试官要看的是你对自己代码的熟悉度，所以提前把仓库整理干净——能一键跑起来、依赖和构建脚本写清楚、README 说明模块职责。讲代码时按「这个模块解决什么问题 → 数据怎么流 → 关键函数在做什么 → 我当时为什么这么写」讲，而不是逐行念。被指出问题时不要辩解，先把对方的顾虑复述一遍确认，再说你会怎么改、改完怎么验证。

2. 优先级反转要讲清「谁挡住了谁」：高优先级任务要拿一把被低优先级任务持有的锁，于是在等；这时一个与这把锁无关的中优先级任务抢占了低优先级任务，导致它迟迟不释放锁，高优先级任务被间接地无限期阻塞——阻塞它的其实是那个中优先级任务。这是实时系统里最典型的一类时序故障，表现是偶发超时、抖动大，压测不一定复现。

3. 优先级继承只说对一半也够呛，要能说清它的边界：做法是当高优先级任务等待某把锁时，持锁任务临时被提升到等待者中的最高优先级，释放锁后恢复原优先级，这样中优先级任务就抢不进来。但它只解决「一层」的问题，多个锁嵌套时可能出现链式阻塞（死锁情形要靠优先级天花板或按固定顺序加锁来防），而且它会打乱原本的优先级语义，实现上依赖内核支持（很多 RTOS 的互斥量默认开启）。如果题目问「还有什么办法」，可以答优先级天花板协议、把访问共享资源的临界区做到极短、或干脆用无锁的消息传递替代共享内存加锁。

4. 任务划分题要落到「周期、优先级、通信」三件事：说清哪些是硬实时的周期任务（控制环、采样）、哪些是软实时的（上报、日志）、哪些是事件驱动的，各自的周期与截止时间是多少，怎么定优先级（常用单调速率：周期越短优先级越高），任务之间通过什么通信（队列、邮箱、信号量、共享内存），以及共享资源怎么保护。面试官追问「为什么这么切」时，用「截止时间和耦合度」当依据，别只说「按功能模块切」。

5. 数据链路要一路讲到端到端：从传感器/设备采集、总线（CAN、串口、SPI、I2C）上的协议与帧格式、驱动与中断/轮询方式、缓冲区与队列设计、任务间传递与优先级、到上行协议（MQTT/自定义 TCP）和断线重连与缓存补发。重点说清异常路径：丢帧怎么发现（校验、序号）、缓冲满了怎么处理（丢弃还是背压）、网络断了数据存哪、重连后怎么保证不重复不丢。面试官问这个问题通常是在确认你有没有做过真实设备的长稳运行。

6. 被婉拒也是一次有效信号：这次面试官给了明确的建议——岗位偏应用、hc 少，做底层的人可以看芯片原厂。这类反馈比「等通知」有价值：它告诉你团队的技术栈和你的方向差在哪。可以顺着问一句更具体的（团队用哪套 RTOS、外设驱动的维护量有多大、有没有自研 SoC 相关岗位），把信息带走用于后面的投递筛选，不必把这次结果当能力评价。