大华嵌入式 AI 面：IO 多路复用、main 之前与虚继承

《面试题目》

1. 当需要同时监控多个串口和网络套接字的数据到达状态时，为什么通常不采用轮询每个文件描述符的方式，而是选择使用 IO 多路复用机制？
2. IO 多路复用能避免频繁占用 CPU，那它在嵌入式场景下相比 select、poll，为什么更常选用 epoll？
3. 在嵌入式设备实际部署中，如何应对某个串口因线路接触不良导致 epoll_wait 长期无响应的问题？
4. 嵌入式程序进入 main() 之前做了什么？
5. 什么是虚继承？它解决什么问题？
6. 继承能避免数据重复和访问二义性，那它在对象内存布局上具体是怎么实现的？
7. 虚继承带来的额外开销具体体现在对象结构和访问效率上吗？
8. 近两年遇到困难，是怎么解决的？
9. 近两年有没有协同合作的经历？

《参考解析》

为什么用 IO 多路复用而不是轮询

轮询是「我挨个去问每个 fd 有没有数据」，问题在于绝大多数时刻都没有数据，CPU 周期全花在无意义的系统调用上，fd 一多还会线性变慢；而阻塞在单个 fd 上又只能等一路。IO 多路复用把「等待」交给内核：一次系统调用声明关心哪些 fd，内核在有事件时唤醒，用户态只在真有事件时处理，既不空转 CPU 又能同时看住多路。

两点补充能显水平：轮询并非一无是处，fd 很少、对延迟极敏感且允许跑满 CPU 的场景里忙轮询反而延迟最低，「短时间自旋、之后转入阻塞」的混合方式是嵌入式常见折中；另外「避免占用 CPU」的前提是等待时间远大于处理时间，如果事件本身极度密集，瓶颈会从等待转移到处理能力上。

嵌入式里为什么偏爱 epoll，select/poll 差在哪

select 有三个硬伤：fd 集合大小受 FD_SETSIZE 限制（通常是 1024）、每次调用都要把整个集合从用户态拷进内核并线性扫描、返回后还得自己遍历找出就绪的 fd。poll 用数组去掉了数量上限，但每次仍要拷贝全部 fd 并做 O(n) 扫描。epoll 把「注册」和「等待」拆开：epoll_ctl 一次注册，内核用红黑树管理 fd、用就绪链表记录有事件的 fd，epoll_wait 直接返回就绪链表，复杂度只与就绪数相关。两个工程细节常被追问：ET（边沿触发）必须配非阻塞 fd 并把数据一次读干净，否则会丢事件；EPOLLONESHOT 用来避免多线程惊群。

但「嵌入式一定用 epoll」并不成立，要分环境说：Linux 应用处理器方案上 epoll 是首选，MCU/RTOS 上根本没有 epoll，只能用 select 或 RTOS 自己的事件机制（队列、事件组）来组织，fd 只有三五个时 select 也完全够用。

串口接触不良导致 epoll_wait 长期无响应怎么处理

先澄清概念：epoll_wait 长期没有事件本身不是故障，它本来就在阻塞等待，真正的风险是「卡在里面导致其他逻辑得不到执行」和「串口掉了却没人发现」。工程上分几层做：

一是给 epoll_wait 设毫秒级超时，超时后跑一遍定时任务——心跳、状态机、喂狗，主循环就不会僵住；二是把设备级健康检测独立出来，定期用 ioctl(TIOCMGET) 读状态线或发探测帧，连续 N 次失败就 close 后重新 open 串口，并做退避以免疯狂重试；三是协议与硬件加固，帧加 CRC 与超时重传，坏帧丢弃而不是死等，接口加隔离与防浪涌、端子防松；四是故障隔离，每个 fd 独立状态与独立重试，必要时把这条通道摘除并上报，看门狗喂狗放在健康检查里而不是主循环里，这样即便主循环卡死也能复位。

还有一个容易误判的点：ET 模式下如果一次只读了一部分数据，也会表现为「没有后续事件」，排查时容易被当成线路问题，实际要检查读循环有没有读干净。

嵌入式程序进入 main() 之前做了什么

这一段大部分由芯片原厂提供的启动代码完成：CPU 从上电复位向量取指，先设置各模式栈指针、关闭看门狗与中断，然后执行 C 运行时初始化——把 .data 段从 Flash 拷到 RAM（有初值的全局/静态变量）、把 .bss 段清零（无初值或初值为 0 的全局/静态变量）、初始化堆边界；如果是 C++，还要跑 __libc_init_array 调用全局对象构造函数与 __attribute__((constructor)) 函数，所以全局对象的构造函数里不能使用还没初始化好的外设。再往前，Reset_Handler 里通常还会做时钟初始化（PLL、总线分频、Flash 等待周期），可选地配置内存重映射或 MPU，最后才跳到 main。

Linux 用户态程序是另一套语境：内核 execve 建立地址空间、装好 argv/envp，动态链接器完成重定位与依赖库加载，再调 __libc_start_main 跑构造函数、最后才进 main。回答前先确认问的是裸机/RTOS 还是 Linux 用户态程序，是这道题的分水岭。

虚继承与它的内存开销

菱形继承里 D 同时继承 B 和 C，而两者又都继承自 A，于是 D 中会出现两份 A 的子对象：数据冗余，且通过 D 访问 A 的成员有二义性。虚继承（class B : virtual public A）让最派生类只保留一份虚基类子对象，冗余与二义性都消失。

实现上，编译器为带虚基类的对象插入虚基类指针（vbptr）或复用虚函数表里的虚基类偏移表，用运行期偏移定位共享的 A。因此 B 单独存在时 A 的位置与它作为 D 的基类时并不相同，访问虚基类成员需要多一次间接寻址，无法像普通继承那样在编译期定死。开销具体体现在三处：对象体积变大（每条路径一个指针）、访问变慢（间接寻址、优化更难）、构造语义变化——虚基类由最派生类负责初始化，D 的构造函数要直接初始化 A，中间层传的参数会被忽略，这是最容易被追问的坑。此外虚继承会改变对象布局与 ABI，跨模块传递这种对象要谨慎。实践结论是：能用组合（成员对象）或纯接口（无数据成员的抽象基类）替代时优先替代。

软性题：困难与协作

「近两年遇到的最大困难」和「协同合作经历」是行为面的固定题，答法都要落到具体事件：情境（时间、角色、约束）、你做了什么、结果、学到什么。困难题建议选一个技术与协作上有真实取舍的例子，比如工期与质量的冲突、跨团队接口对不上、线上问题应急，把「怎么解决的」落到动作上，而不是「我很努力地扛过去了」。

协作题要讲清角色边界和沟通方式：怎么同步信息、怎么处理分歧、有没有主动补位，最好给出一次具体的分歧与收敛过程——面试官想听的是你在团队里的实际作用。这两题都不适合答「没有遇到过」，也不适合虚构大项目，真实的小事讲透比编大事更安全。