题目与范围
liburing 的 multishot accept 能让一次提交产生多个完成队列事件（CQE）。请求可能在错误后停止，或在完成事件没有 multishot 标记时终止。核心能力是异步系统编程，因此分类为 coding。
面试官考察点
应解释 IORINGCQEF_MORE、CQE 所有权、提交与完成队列背压、accept 错误、取消和重新布置。先探测内核支持，不能过早复用缓冲区或用户数据，并与传统非阻塞 accept 循环比较。
先澄清的问题
- 部署的内核和 liburing 版本是什么？
- 监听 socket 由一个 ring 所有，还是多个工作器共享？
- 连接速率、突发量和文件描述符预算是多少？
- 接受的 socket 如何交给协议工作器？
- multishot 请求终止或 CQ 满时怎么办？
- 是否需要不依赖 io_uring 的回退？
30 秒答题框架
“先探测支持，提交一个 multishot accept，把每个 CQE 当成独立接受的 socket 处理。检查 IORINGCQEF_MORE；标志缺失时请求已不再布置，处理终止结果后必须重新提交。循环需要有界 CQ、明确处理 EMFILE 与瞬时错误、socket 交接所有权和普通 accept 回退。基准比较 CPU、每秒接受数、尾延迟、丢弃、CQ 溢出和重新布置间隙。”
分步作答
步骤 1：探测并配置
使用 ring 探针或文档化能力检查，确认 multishot accept 和所需标志。根据突发量与交接速率配置队列大小，设置 close-on-exec 和非阻塞行为，并权衡直接描述符的管理成本。
步骤 2：提交长生命周期请求
准备稳定的用户数据，标识监听 socket 和代次。不能假设一个 SQE 只产生一个 CQE。请求生命周期属于事件循环状态，关联状态必须等到终止完成事件消费后才能释放。
步骤 3：消费每个完成事件
逐个检查 CQE：结果可能是接受的描述符，也可能是负错误。成功 socket 只向协议工作器转移一次所有权。每次检查 IORINGCQEF_MORE；即使当前 CQE 成功而标志缺失，也要把请求标为非活动。
步骤 4：重新布置并施加背压
清空可用 CQE 后，若请求非活动且系统仍能接收工作，就重新提交。限制交接队列，文件描述符压力升高时暂停或拒绝新工作，并处理 EMFILE、ENFILE 和瞬时网络错误，避免忙等。
步骤 5：关闭与基准
关闭时取消或关闭请求，排空 CQE，并关闭未交接的接受 socket。用相同 CPU、backlog、连接组合和工作器容量比较 multishot 与传统 accept。除了系统调用数，还要测量重新布置间隙以及丢失或拒绝的连接。
参考答案
“Multishot accept 能降低提交开销，但它是有生命周期的 CQE 流。先探测支持，提交稳定用户数据，每个接受描述符只处理一次，并在每个完成事件检查 IORINGCQEF_MORE。标志消失后，把请求标为非活动，处理终止结果再重新布置。队列深度、交接背压、EMFILE、关闭排空和普通 accept 回退都是正确性的一部分。基准必须包括重新布置间隙、丢弃、尾延迟和 CPU。”
常见错误
- 认为请求永久有效 → 错误或缺少 MORE 后完成会停止 → 显式重新布置。
- 把一个 CQE 当成全部结果 → 后续连接被漏掉 → 排空所有 CQE。
- 过早释放用户数据 → 后续完成事件访问无效状态 → 到终止完成后再释放。
- 忽略负结果 → 循环忙等或隐藏资源耗尽 → 分类错误并退避。
- 交接队列无界 → 接受描述符耗尽进程 → 设置描述符和队列预算。
- 只测系统调用 → 重新布置间隙和丢连接不可见 → 测量端到端连接结果。
追问
追问 1：IORINGCQEF_MORE 表示什么？
它表示 multishot 请求预计还会产生更多 CQE。标志缺失时请求已结束，应用不能假设会有下一次完成事件。
追问 2：成功 CQE 可以是终止事件吗？
可以。CQE 可能带有效接受描述符却没有 MORE。先处理 socket，再重新布置请求。
追问 3：如何避免描述符耗尽？
限制协议交接，监控 RLIMIT_NOFILE，处理 EMFILE 与 ENFILE，容量恢复前暂停接受或削峰。
追问 4：为什么保留回退？
内核、liburing、容器或策略限制可能阻止 io_uring。非阻塞 accept 保持可用性，也提供性能比较的正确性基线。