io_uring 的链接操作（chain）与多依赖（link）机制是什么？它如何实现多个操作之间的依赖编排？
io_uring 通过 IOSQE_IO_LINK 标志把多个操作链接成链，前一个操作完成后才执行下一个，实现顺序依赖。链中任一操作失败，后续待执行操作会被取消（除非带 IOSQE_IO_HARDLINK 表示硬链接）。这种机制让一组有依赖的操作（如"read 后 write"）可一次提交、顺序完成，减少多次系统调用的开销。链式提交配合 io_uring 的异步执行，显著提升吞吐。
本题考察 io_uring 的链式编排。核心是"IOSQE_IO_LINK 串行 + 失败取消"。作答时说明链式依赖如何减少提交次数并保证顺序。
在连接数很少、IOPS 不高的场景下，io_uring 为何可能因额外的环管理与注册开销反而比 epoll 更慢？
io_uring 需要创建并 mmap 分配 SQ/CQ 环形队列、注册文件与缓冲区（io_uring_register），这些初始化与内存管理有固定开销。在低 IOPS、少量连接场景，这些开销远超实际收益，且每次提交仍需一定同步，因此比 epoll 的简单事件循环更慢。io_uring 的优势在高峰值、高并发、大量系统调用时才能体现，低负载下 epoll 更轻量。
本题考察 io_uring 的适用边界。核心是"固定开销 vs 收益随负载变化"。作答时说明为何低负载下 epoll 更合适。
sendfile 如何在从磁盘文件到 socket 的传输中实现内核态单次拷贝？
sendfile 把文件内容从页缓存直接发送到 socket，全程在内核态完成：文件页从缺页/页缓存读入，经 socket 缓冲区或 page cache 直接引用发送，避免"用户态读 + 用户态写"的两次用户态拷贝。数据在页缓存与 socket 之间通常只需一次拷贝（或利用 MSG_ZEROCOPY 直接引用页）。相比 read/write 循环，sendfile 减少了数据在内核与用户态之间的搬移。
本题考察 sendfile 零拷贝。核心是"页缓存 → socket 一次拷贝，免用户态搬运"。作答时说明相比传统读写的拷贝次数差异。
tee 如何"复制管道数据"？它为什么是用户态可见但零拷贝的？
tee 把管道 A 中的数据复制到管道 B，但复制的是"页引用"而非数据内容，两个管道共享同一页。因此用户态看到数据被复制，实际未发生实质内容拷贝，属于零拷贝。tee 常用于把管道数据同时向两个接收方分发，避免重复拷贝。它与 splice 配合可构建管道相关的零拷贝数据流。
本题考察 tee 零拷贝。核心是"复制页引用而非内容"。作答时说明"用户态可见复制、内核零拷贝"的机制。
mmap 文件后 write 到 socket，相比 sendfile 仍多出一次从页缓存到 socket 缓冲区的拷贝，这次拷贝发生在哪里？
mmap 把文件映射到用户态，用户通过指针访问页缓存；write 把页缓存中的用户数据发送到 socket 时，内核把页缓存内容拷贝到 socket 缓冲区（skb），这是一次额外的内核态拷贝。sendfile 则直接让页缓存引用被 socket 发送，避免这步拷贝。因此 mmap+write 比 sendfile 多一次"页缓存 → socket 缓冲区"的拷贝，发生在内核发送路径。
本题考察 mmap+write 与 sendfile 差异。核心是"sendfile 免去页缓存到 skb 的拷贝"。作答时指明确切拷贝位置。
在高 IOPS 场景下，io_uring 相比 epoll 的性能优势体现在哪里？
高 IOPS 场景下，io_uring 通过一次提交批量操作、一次完成批量收割，大幅减少系统调用次数；同时支持真正的异步 I/O（无需反复轮询与多余拷贝），配合固定缓冲区与注册文件减少每操作开销。epoll 只能做事件通知，每次 I/O 仍需各自系统调用且易阻塞。io_uring 的批处理与零拷贝特性使其在高 IOPS 下显著优于 epoll。
本题考察 io_uring 高 IOPS 优势。核心是"批处理减少 syscall + 真正异步 + 零拷贝"。作答时说明与 epoll 的本质差异。
io_uring 的 IORING_FEAT_* 特性探测是什么？它为何重要？
io_uring 通过 IORING_FEAT_* 标志位（如 IORING_FEAT_SINGLE_MMAP、IORING_FEAT_NODROP、IORING_FEAT_EXT_ARG）向用户态探测内核支持的特性，用户态据此选择可用功能。特性探测让应用适配不同内核版本，避免使用内核未实现的功能导致失败。liburing 封装了这些特性判断，简化开发。
本题考察 io_uring 特性探测。核心是"标志位探测内核能力 + 版本适配"。作答时说明其兼容性作用。
io_uring 的 IORING_OP_* 系统调用族（READ、WRITE、ACCEPT、CONNECT 等）是什么？它们如何统一异步 I/O？
IORING_OP_READ、IORING_OP_WRITE、IORING_OP_ACCEPT、IORING_OP_CONNECT 等操作类型把传统系统调用映射为 io_uring 的提交项，使读、写、接受、连接等都能异步执行。应用只需提交对应 opcode 的 SQE，完成后从 CQE 读取结果，统一了各种 I/O 的异步接口。这使 io_uring 能覆盖网络与文件 I/O 的多数场景。
本题考察 IORING_OP 族。核心是"把传统系统调用映射为异步操作类型"。作答时说明统一异步接口的价值。
io_uring 的双环形队列（submission queue、CQE ring）设计是什么？它如何实现用户态与内核态共享？
io_uring 用两个环形队列：提交队列（SQ）存放要执行的操作，完成队列（CQ）存放完成结果。两者通过 mmap 在用户态与内核态共享，应用直接写 SQ 提交操作、读 CQ 获取结果，无需传统系统调用的数据拷贝。SQ/CQ 共享内存配合内存屏障实现无锁或低锁交互，极大降低每次 I/O 的开销。
本题考察 io_uring 双环形队列。核心是"SQ 提交、CQ 完成、mmap 共享"。作答时说明共享内存如何减少系统调用。
io_uring 的固定缓冲区（fixed buffer）与缓冲区注册是什么？它如何减少拷贝与开销？
固定缓冲区通过 io_uring_register 注册，内核提前锁定并记录这些缓冲区，提交 I/O 时直接引用（如 IORING_OP_READ_FIXED），避免每次检查用户地址与页锁定。这减少每次操作的开销，并支持零拷贝场景。固定缓冲区适合频繁复用、生命周期长的缓冲区，能显著提升批量 I/O 性能。
本题考察固定缓冲区。核心是"注册后内核直接引用、免重复锁定"。作答时说明其适用场景与开销。
io_uring_setup 与 io_uring_register 的内核注册流程是什么？它们分别完成什么？
io_uring_setup 创建 io_uring 实例，初始化 SQ/CQ 环形队列并返回文件描述符，应用据此 mmap 映射队列；io_uring_register 用于注册文件、缓冲区、fixed config 等资源，供后续提交复用。二者是 io_uring 的初始化与资源注册入口，注册后的资源在内核侧预先准备，减少每次 I/O 的重复开销。
本题考察 io_uring 初始化流程。核心是"setup 建环、register 注册资源"。作答时说明二者在生命周期中的分工。
liburing 的 io_uring_prep_* 系列封装是什么？它如何简化 io_uring 的使用？
liburing 提供 io_uring_prep_read/write/accept 等系列函数，封装 SQE 的填充（opcode、fd、地址、长度、flags），隐藏底层细节。开发只需调用 prep 函数准备操作，再 io_uring_submit 提交、io_uring_wait_cqe 等待完成。这减少了直接操作 SQE 的样板代码与出错风险，是 io_uring 的推荐使用方式。
本题考察 liburing 封装。核心是"prep 系列填充 SQE + 提交/完成 API"。作答时说明其简化开发的价值。
io_uring 与 msync、posix_fadvise 的协同体现在哪里？它们如何配合优化 I/O？
msync 用于把 mmap 映射的脏页同步到磁盘，posix_fadvise 用于向内核提示访问模式（如顺序、随机、不缓存），二者可与 io_uring 协同：io_uring 负责异步数据搬运，msync 保证持久性，posix_fadvise 优化缓存策略。io_uring 也提供对应的异步操作（如 IORING_OP_FADVISE、IORING_OP_MSYNC），让这些提示与同步也异步化，统一在提交队列中调度。
本题考察 io_uring 与缓存/同步协同。核心是"msync 持久性、fadvise 缓存策略可异步化"。作答时说明三者结合的场景。
io_uring 的 persona（task_work）异步任务是什么？它如何延迟完成处理？
io_uring 的完成处理常通过 task_work 实现：内核在合适时机（如进程回到用户态前）把完成回调调度到进程上下文执行，而不是在中断/软中断中立即处理。这样完成 CQE 的收割与回调在用户态友好的上下文进行，减少内核上下文切换开销。task_work 机制使 io_uring 的完成路径更高效、更可控。
本题考察 task_work。核心是"完成回调延迟到进程上下文执行"。作答时说明其降低开销的原理。
io_uring 的注册文件描述符（registered fds）如何减少 fd 表查找开销？
通过 io_uring_register 把文件描述符注册进内核，io_uring 用一个固定索引引用这些 fd，提交 I/O 时内核直接按索引取文件结构，避免每次从进程 fd 表查找。这减少每操作的开销，也避免 fd 被关闭导致的问题。注册 fd 适合频繁复用文件的高性能场景。
本题考察 registered fds。核心是"索引直接引用免 fd 表查找"。作答时说明其性能收益与适用场景。
io_uring 在 Rust（tokio-uring）与 Java 的高级封装是什么？它们如何暴露 io_uring 能力？
tokio-uring 把 io_uring 集成到 tokio 异步运行时，提供基于借用的异步 read/write 等接口，让 Rust 异步程序受益于 io_uring 的高性能；Java 端（如 Netty 的 io_uring 传输、JNI 封装）提供非阻塞 I/O 访问 io_uring。这些封装在保留 io_uring 性能的同时，通过语言运行时管理生命周期与安全性，降低直接使用复杂度。
本题考察 io_uring 的语言封装。核心是"tokio-uring/Java 提供安全异步接口"。作答时说明封装的价值。
io_uring 在数据库（TiDB、ScyllaDB）的应用案例是什么？它如何提升数据库性能？
TiDB、ScyllaDB 等数据库对持久化 I/O 要求极高，采用 io_uring 实现异步读写，减少线程阻塞与上下文切换，提升吞吐。io_uring 的批量提交、固定缓冲区与零拷贝减少每笔 I/O 开销，配合数据库的日志与数据文件写入，显著降低延迟与 CPU 占用。io_uring 成为数据库 I/O 引擎的现代选择。
本题考察 io_uring 在数据库的应用。核心是"异步 I/O 减少阻塞与开销"。作答时说明数据库为何受益。
io_uring 的"受限模式"（restricted mode）与安全边界是什么？它如何限制操作权限？
io_uring 的受限模式通过 IORING_SETUP_R_DISABLED 与 io_uring_register 的受限操作，限制队列可执行的 opcode 与注册功能，建立一个操作白名单。这让 io_uring 在沙箱等受限环境中安全运行，仅允许特定操作，减少攻击面。受限模式是 io_uring 安全边界的重要组成，防止恶意代码滥用功能。
本题考察受限模式。核心是"操作白名单限制 + 减少攻击面"。作答时说明其安全价值。
mmap 的"用户态映射内核页"如何避免 read 拷贝？其机制是什么？
mmap 把文件页缓存映射到用户地址空间，用户态直接访问页缓存中的页面，无需 read 系统调用把数据拷贝到用户缓冲区。因此读文件时数据停留在页缓存，用户通过指针读取，避免了"内核拷贝到用户态"的拷贝。mmap 也支持写回（脏页回写），适合大文件随机访问与共享内存。
本题考察 mmap 免拷贝。核心是"用户态直接映射页缓存、read 拷贝被消除"。作答时说明 mmap 与 read 的拷贝差异。
传统 I/O 的"用户态-内核态"两次拷贝（read → 用户 buffer → write）是如何发生？为什么昂贵？
传统 read/write 循环中，read 把数据从内核页缓存拷贝到用户缓冲区，write 再把这些数据从用户缓冲区拷贝回内核（socket 缓冲区/文件），共发生两次用户态-内核态拷贝。每次拷贝都涉及 CPU 与内存带宽开销，且伴随系统调用。这正是零拷贝（sendfile、mmap、io_uring）要消除的冗余。
本题考察传统 I/O 两次拷贝。核心是"read 一次 + write 一次"。作答时说明两次拷贝的位置与零拷贝的动机。
MSG_ZEROCOPY 让 send() 直接引用用户页避免拷贝，内核如何通过 error queue 的扩展错误信息通知用户页可回收？
MSG_ZEROCOPY 让 send() 直接引用用户页，减少拷贝，但用户必须等内核用完该页后才能复用或释放。内核通过 error queue（errqueue）返回带 SO_EE_ORIGIN_ZEROCOPY 的扩展错误信息，报告页引用已释放。应用收到此通知后才安全回收发送缓冲区。这种"引用 + 通知"机制是 MSG_ZEROCOPY 实现零拷贝的配套协议。
本题考察 MSG_ZEROCOPY 的通知机制。核心是"error queue 通知页可回收"。作答时说明零拷贝与回收时机的配合。
io_uring 的 provided buffers（buffer ring，IORING_REGISTER_PBUF_RING）如何让内核接收时直接写入用户预提供缓冲，实现接收零拷贝？
provided buffers 允许应用预先注册一批缓冲区（buffer ring），内核在接收数据时直接从该池选取缓冲区写入，完成后通过 CQE 的 buffer id 通知用户哪个缓冲区被使用。用户无需为每次接收准备缓冲，内核也不用把数据拷贝到临时缓冲，实现接收路径的零拷贝。这对网络接收等高频场景显著提升性能。
本题考察 provided buffers。核心是"预注册缓冲池 + 内核直接写入 + 免拷贝"。作答时说明接收零拷贝的机制。
copy_file_range 的内核态文件到文件拷贝是什么？它如何减少拷贝次数？
copy_file_range 在内核态直接把数据从一个文件复制到另一个文件，全程不经过用户态缓冲区，避免传统"read 到用户 + write 到目标"的两次用户态中转。它可复用页缓存或直接在内核进行拷贝，减少拷贝次数与系统调用。适用于文件复制、日志归档等场景，相比 read/write 循环更高效。
本题考察 copy_file_range。核心是"内核态文件间拷贝、免用户态中转"。作答时说明其与 read/write 的差异。
io_uring 的 IORING_OP_SPLICE 零拷贝 splice 操作是什么？它如何与 splice 系统调用结合？
IORING_OP_SPLICE 把 splice 系统调用异步化，提交后由内核在合适时机执行文件与管道、socket 之间的零拷贝转移。splice 本身通过管道缓冲区实现数据在两个 fd 之间零拷贝，io_uring 使其异步批量执行，避免同步阻塞。这适合构建异步文件传输与管道数据流。
本题考察异步 splice。核心是"io_uring 异步化 splice 零拷贝"。作答时说明其与 splice 的结合。
IORING_SETUP_COOP_TASKRUN、IORING_SETUP_SINGLE_ISSUER 等标志分别优化了什么路径？使用时有什么约束？
IORING_SETUP_COOP_TASKRUN 让完成处理与用户运行协同，减少不必要的 task_work 抢占；IORING_SETUP_SINGLE_ISSUER 声明只有单线程提交，允许内核优化掉相关锁与同步。二者的约束是：SINGLE_ISSUER 要求提交确实来自单一线程，否则并发提交会出错；COOP_TASKRUN 要求应用配合调度。这些标志在特定使用模式下换取性能。
本题考察 io_uring 性能标志。核心是"单发行者/协同运行优化路径 + 约束"。作答时说明各自优化与使用前提。
IORING_SETUP_SQPOLL 模式下内核轮询线程持续检查 SQ，它在什么场景下能彻底消除 io_uring_enter 调用？
SQPOLL 模式启动一个内核轮询线程持续检查 SQ，只要 SQ 有提交项就自动处理，应用只在需要等待完成或唤醒时调用 io_uring_enter。在应用持续提交、忙碌等待高频请求的场景下，轮询线程可把提交也异步化，使应用无需每次主动调用 io_uring_enter 提交，从而彻底消除该系统调用。代价是占用一个 CPU 线程与轮询开销。
本题考察 SQPOLL。核心是"内核轮询线程承担提交，消除 io_uring_enter"。作答时说明适用场景与代价。
io_uring 的 SQ/CQ 环形缓冲区通过 mmap 在用户态与内核态共享，提交与完成如何避免传统系统调用的陷入开销？
io_uring 的 SQ/CQ 通过 mmap 映射到用户态，应用直接写 SQ 中的 SQE 提交、读 CQ 中的 CQE 获取结果，无需在每次 I/O 时进行系统调用陷入。内核在轮询或 io_uring_enter 时消费 SQ，应用侧用内存屏障保证可见性。这样把"每次 I/O 系统调用"降为"批量提交 + 少量同步"，大幅减少陷入开销。
本题考察 io_uring 免陷入。核心是"共享内存直接读写队列 + 屏障同步"。作答时说明减少系统调用的原理。
io_uring 的 linked submission 用 IOSQE_IO_LINK 把多个操作串成链，前一个失败时后续操作如何被取消？
linked submission 中，链上操作按顺序执行，若某个操作失败（返回错误），后续已链接的操作会被取消，其 CQE 返回 -ECANCELED。但若使用 IOSQE_IO_HARDLINK，则链中操作即使前一个失败也继续执行（硬链接）。普通 link 的取消可避免在失败依赖下继续执行无意义操作，体现依赖编排的语义。
本题考察 linked submission 取消。核心是"失败取消后续 + HARDLINK 例外"。作答时说明普通 link 与 hardlink 的差异。
io_uring 的 linked timeout 如何给一组链式操作设置整体超时？它与独立 timeout 操作有什么区别？
linked timeout 通过把带 IOSQE_IO_LINK 的 timeout 操作链接到一批操作之后，为整组操作设置整体超时：若这组操作在超时前完成，timeout 会被取消；若超时到达仍未完成，timeout 触发并发给超时错误。独立 timeout 操作则只针对单个操作或单独计时。linked timeout 适合为一组有依赖的操作设置统一的截止时间。
本题考察 linked timeout。核心是"整组操作统一超时 vs 单操作超时"。作答时说明 linked timeout 的整体语义。
CQE 的 res 与 flags 字段分别返回什么？IOSQE_BUFFER_SELECT 选中的 buffer id 如何回传？
CQE 的 res 字段返回对应操作的返回值（成功时为字节数，失败时为负错误码），flags 字段携带附加标志（如 IORING_CQE_F_MORE 表示还有更多、IORING_CQE_F_BUFFER 表示携带 buffer id）。当使用 IOSQE_BUFFER_SELECT 时，内核从 provided buffers 选择缓冲区，CQE 的 flags 置 IORING_CQE_F_BUFFER，并把选中的 buffer id 编码在高位，应用据此取出对应缓冲区。这是 provided buffers 的配套机制。
本题考察 CQE 字段。核心是"res 返回值、flags 标志、buffer id 回传"。作答时说明 CQE 如何报告完成状态与缓冲信息。
当 SQ 填满或内核处理不过来时，io_uring 的背压如何体现？应用应如何排水？
当 SQ 填满，io_uring_submit 返回的提交数少于请求数，或 io_uring_enter 返回相关错误，表示内核处理不过来，形成背压。应用应等待已有 CQE 完成（io_uring_wait_cqe）释放 SQ 空间后再继续提交，即"排水"：先完成再提交，避免无限堆积。合理控制并发提交数（如用 io_uring_get_sqes 检查可用槽）能有效缓解背压。
本题考察 io_uring 背压。核心是"SQ 填满触发等待 + 排水策略"。作答时说明应用如何应对背压。
io_uring buffer ring（IORING_REGISTER_BUFFERS / BUFFER_SELECT）在 1k concurrent buffer 的工程价值是什么？
在 1k 并发缓冲规模下，io_uring buffer ring 通过 BUFFER_SELECT 让内核在接收时自动从预注册的缓冲池选取可用缓冲，应用无需为每个并发请求单独分配/管理缓冲，多个并发缓冲由内核统一调度。这减少了缓冲分配与切换开销，支持高并发下的高效零拷贝接收。BUFFER_SELECT 让缓冲管理趋于内核化，工程价值显著。
本题考察 buffer ring 高并发。核心是"内核统一管理大量并发缓冲、免分配切换"。作答时说明其高并发价值。
io_uring buffer ring 在 BUFFER_SELECT 与 BPID（buffer pool id）的工程价值是什么？
BPID（buffer pool id）标识不同的缓冲池，应用可注册多个缓冲池，通过 BUFFER_SELECT 时指定的 BPID 让内核从特定池选取缓冲，实现缓冲的分类管理（如按大小或用途分组）。这使不同场景使用不同缓冲池，提升灵活性。CQE 回传的 buffer id 结合 BPID 可定位具体缓冲，工程上便于高并发下的精细管理。
本题考察 BPID。核心是"缓冲池分组 + 按 BPID 选择"。作答时说明多缓冲池的分类价值。
buffer ring 在 zero-copy + io_uring send 的工程价值是什么？
buffer ring 不仅用于接收，也支持发送侧：应用预注册发送缓冲，io_uring send 直接引用这些缓冲，配合零拷贝避免数据拷贝，同时缓冲复用减少分配与回收开销。通过 buffer ring 统一管理发送缓冲，可让发送路径同样实现零拷贝与批量管理，提升整体 I/O 性能。这使 io_uring 的发送与接收都受益于缓冲池。
本题考察 buffer ring 发送侧。核心是"发送缓冲复用 + 零拷贝 send"。作答时说明其发送侧价值。
splice 如何在两个文件描述符之间实现"管道化"零拷贝？
splice 在两个文件描述符之间移动数据，通常经管道中转：把一个 fd 的数据写入管道（转移页引用），再从管道读出到另一 fd，全程共享页引用而非拷贝内容，实现零拷贝。splice 要求一端是管道。它常用于文件与 socket 之间的高效传输，避免数据经过用户态缓冲。
本题考察 splice 零拷贝。核心是"管道中转共享页引用"。作答时说明 splice 的管道要求与免拷贝原理。
vmsplice 的"用户页直接入管道"半零拷贝是什么？它与 splice 有何区别？
vmsplice 把用户态内存页直接映射到管道缓冲区，无需把数据拷贝到内核，实现"用户页直接入管道"的半零拷贝。它配合 splice 从管道发送到目标，构成完整零拷贝路径。vmsplice 是"半零拷贝"因为用户页仍被引用，需在管道消费后释放。与 splice 从内核 fd 取数据不同，vmsplice 从用户内存取数据。
本题考察 vmsplice。核心是"用户页直接入管道 + 半零拷贝"。作答时说明其与 splice 的分工。
MSG_ZEROCOPY 在小包场景为何可能因页引用与通知开销反而变慢？它适合什么样的负载？
MSG_ZEROCOPY 需要内核引用用户页并在报文发出后通过 error queue 通知，伴生页引用管理与通知开销。小包场景下这些固定开销摊薄不到大数据量上，反而比普通拷贝更慢；大包（如大文件传输）时页引用与通知的成本被数据量摊薄，零拷贝收益显著。因此 MSG_ZEROCOPY 适合大包、长连接的高吞吐负载。
本题考察 MSG_ZEROCOPY 边界。核心是"固定开销在小包占比高"。作答时说明其适用的大包负载。
sendpage 与 sendfile 的 socket-specific 优化是什么？它们如何提升网络发送性能？
sendpage 把单个页直接发送到 socket，避免页拷贝；sendfile 在文件到 socket 的传输中做整体优化，从页缓存直接引用发送。二者都是 socket 发送场景的零拷贝优化，减少用户态与内核态拷贝。sendpage 更底层（按页），sendfile 面向文件整体，二者让网络发送路径更高效。
本题考察 sendpage/sendfile。核心是"页/文件直接发送免拷贝"。作答时说明两者在 socket 发送的优化。
multishot 操作（如 multishot recv/accept）一次提交可产生多个 CQE，它解决了什么重复提交的开销？
multishot 操作提交一次后可持续产生多个 CQE，直到显式取消或出错。例如 multishot recv 可连续接收多个数据包，multishot accept 可连续接受多个连接，应用无需每次接收/接受后重新提交，消除了重复提交 SQE 的开销。这在高频连接/数据场景显著降低提交负担，提升吞吐。
本题考察 multishot。核心是"一次提交多次完成，免重复提交"。作答时说明其减少提交开销的价值。
