io_uring百万连接需同时启用ioring_setup_iopoll和ioring_setup_sqpoll，否则submit延迟飙升、吞吐减半；iopoll绕过中断轮询完成队列，sqpoll由内核线程提交sq，二者缺一不可。
io_uring 初始化必须用 IORING_SETUP_IOPOLL + IORING_SETUP_SQPOLL
不加这两个 flag，百万连接下 io_uring_submit() 延迟会飙升，实际吞吐掉一半以上。IOPOLL 让内核绕过中断直接轮询完成队列，SQPOLL 则让内核单独起线程提交 SQ，避免用户态频繁陷入 syscall —— 这两者是压测时区分「能跑」和「能稳住」的关键分水岭。
常见错误：只设 IORING_SETUP_SQPOLL 却漏掉 IORING_SETUP_IOPOLL，结果 submit 耗时抖动剧烈，io_uring_sq_ready() 返回值忽高忽低；或者用在非 NVMe 设备上（比如 SATA SSD 或虚拟块设备），IOPOLL 反而降低性能。
- 初始化前确认设备支持：
cat /sys/block/nvme0n1/queue/iostat存在且IO poll字段为 1 - 内存必须页对齐：
posix_memalign()分配 sq/cq ring 和 submission buffer，否则io_uring_queue_init_mem()失败返回-EINVAL - sq_entries 至少设为 32768（2^15），太小会导致 submit 频繁阻塞；cq_entries 建议 ≥ sq_entries × 2，防 completion 队列溢出丢事件
accept 连接不能用 io_uring_register_files() 预注册
预注册文件描述符（fd）看似省事，但 io_uring_register_files() 最大支持约 65535 个 fd，远不够百万连接；更严重的是，新 accept 的 fd 无法动态追加进已注册数组，每次扩容要 io_uring_unregister_files() + 全量重注册，锁竞争激烈，accept 路径直接卡死。
正确做法是彻底放弃预注册，改用 IORING_OP_ACCEPT 直接操作 socket fd，靠 SO_REUSEPORT + 多个 io_uring 实例分担负载。每个 ring 绑定一个 CPU 核，accept 事件由对应核上的 io_uring_enter() 处理。
立即学习“C++免费学习笔记（深入）”；
- 监听 socket 必须设
SO_REUSEPORT：setsockopt(listen_fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt)) - 每个
io_uring实例调用io_uring_prep_accept()时，传入真实 fd（非 file_index），并设IOSQE_IO_LINK链后续 read/write 操作 - 别在 accept 回调里立刻分配 connection 对象 —— 内存分配器（如 tcmalloc）在多线程高并发下易成瓶颈，建议用 per-CPU slab cache 预分配
read/write 必须用 IORING_OP_READ_FIXED + IORING_OP_WRITE_FIXED
百万连接意味着每秒数百万次 read/write 提交，如果每次都 copy 用户 buffer 地址进 sqe，CPU cache line 争用严重，io_uring_sqe_set_data() 开销不可忽视。用 fixed buffer（通过 io_uring_register_buffers()）后，sqe 只需填 index，内核直接查表取物理地址，延迟下降 30%+。
坑在于：fixed buffers 生命周期必须严格长于所有关联的 I/O 请求；buffer 数量要按连接峰值预估（比如 1M 连接 × 2 buffers/conn = 2M buffers），且单 buffer 大小建议 4KB–16KB，太小导致频繁切 buffer，太大浪费内存并加剧 TLB miss。
- 注册前确保 buffer 地址页对齐、长度是页大小整数倍，否则
io_uring_register_buffers()返回-EFAULT - 每个 connection 关联固定 buffer index，用
io_uring_sqe_set_flags(sqe, IOSQE_BUFFER_SELECT)+sqe->buf_group指定 group id - 收到
IORING_CQE_F_BUFFER标志时，从cqe->flags & 0xffff提取实际使用的 buffer index，别硬解指针
epoll 退场后，如何安全关闭百万连接？
传统 epoll 下 close(fd) 是即时的，但 io_uring 中大量 IORING_OP_CLOSE 提交会挤占 sq 空间，completion 还可能延迟触发，导致 fd 泄漏或 TIME_WAIT 爆满。真正可靠的方案是：先禁读写（shutdown(fd, SHUT_RDWR)），再异步 close，最后靠 io_uring_wait_cqe_timeout() 轮询 close 完成，而非阻塞等待。
更关键的是连接池回收时机：不能等 close 完成才归还 connection 对象，而应在 shutdown 后立即归还到 per-CPU pool，close 操作纯异步执行 —— 否则 pool size 被 pending close 占满，新连接无法分配对象。
- shutdown 后立刻调用
io_uring_prep_shutdown()，避免残留数据触发 RST - close 提交失败（如
cqe->res == -EBADF）说明 fd 已被回收，跳过后续逻辑，别重试 - TIME_WAIT 问题靠 sysctl 调优：
net.ipv4.tcp_tw_reuse = 1+net.ipv4.ip_local_port_range = "1024 65535"，否则端口耗尽比程序崩溃还快
百万连接不是堆参数就能跑起来的事——ring 大小、buffer 管理粒度、fd 生命周期、甚至网卡 RSS 队列与 CPU 核绑定方式，任何一个环节没对齐硬件特性，吞吐就卡在十万级不动。最常被忽略的是：io_uring 不是黑盒，它暴露了内核 I/O 调度的全部细节，你得像调内核模块一样去调它。