iocp与epoll不可直接比较吞吐量：epoll是reactor模式，需用户调用recv/read搬运数据；iocp是proactor模式，由内核完成数据搬运并通知完成，二者抽象层级不同，硬比数字仅反映测试偏差而非真实能力。
没有“极限制吞吐量”可比——IOCP 和 epoll 根本不是同一类东西，硬比数字只会误导决策。
epoll_wait 返回后你还得自己调 recv() 搬数据
epoll 是 Reactor 模式，只负责通知“这个 socket 可读了”，不碰数据搬运。你必须立刻调 recv() 或 read() 把数据从内核缓冲区拷到用户内存。这一步是同步的、阻塞在拷贝上的系统调用：
- 用水平触发（LT）但没清空缓冲，
epoll_wait()下次还会返回该 fd，而你可能还卡在上次recv()里 - 用边缘触发（ET），必须循环
recv()直到返回EAGAIN，否则丢包 - 每次
recv()都有上下文切换 + 内存拷贝开销；吞吐越高，这部分 CPU 消耗越明显 - 单线程下高吞吐依赖
recvmmsg()、零拷贝接收等额外优化，不是 epoll 自身提供的
IOCP 的 WSARecv() 提交即返回，内核填好缓冲区
IOCP 是 Proactor 模式：你调一次 WSARecv() + OVERLAPPED，函数立即返回；内核在后台把网卡数据直接复制进你传入的缓冲区，完成后才把完成包投递到完成端口：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 应用线程完全不参与数据搬运，可以持续投递新请求（比如一边等上次 recv 完成，一边再发一次 recv）
- 多个线程可安全共用一个 IOCP 句柄，
GetQueuedCompletionStatus()无锁取包，调度由内核完成 - Windows 内核深度集成 IOCP，支持
TransmitFile、DisconnectEx等零拷贝/原子操作 - 但错误是在完成阶段才暴露（如缓冲区满、连接断开），调试时容易滞后
所谓“epoll 吞吐更高”的测试往往混杂平台干扰
很多公开对比（比如虚拟机 Ubuntu vs 原生 XP）得出 “epoll 达到 1000MB/s，IOCP 只有 400MB/s”，这类结果实际混杂了三类干扰：
- 网卡速率不同：
ifconfig显示虚拟机是 1000M，XP 主机是 100M，物理层就差 10 倍 - 线程模型不对等：epoll 测试用单线程，IOCP 测试用多线程但未启用线程池模式，无法发挥完成端口的负载均衡优势
- 数据包大小敏感：20KB 包下 IOCP CPU 占用仅 1%，但 800KB 包下飙升到 80%，说明其吞吐受缓冲区管理策略影响极大，而 epoll 对包长更钝感
Linux 上真异步 IO 得用 io_uring，不是 epoll
epoll 本身不提供异步 I/O 能力，它只是事件通知机制。“Linux 用 epoll 模拟 AIO”是常见误解。真正的异步 I/O 在 Linux 上需依赖 io_uring（5.1+ 内核）或较老的 libaio：
-
io_uring支持提交读写请求后立即返回，内核后台执行，完成时通过轮询或事件通知告知 - 有零拷贝路径（如
IORING_OP_SENDFILE）、批处理、无锁提交队列，大幅降低上下文切换开销 - 但需应用程序主动适配新 API，glibc 尚未完全封装，生态支持弱于 IOCP
- 其完成通知机制（
SQPOLL、polling mode）对 CPU 占用更敏感，配置不当反而降低吞吐
真正关键的差异不在数字本身，而在「谁在搬运数据」：epoll 把搬运压力留给了你写的代码，IOCP 把搬运责任交给了内核。选哪个，取决于你愿不愿意为可控性让渡一部分自动化能力——这比吞吐数字重要得多，也容易被忽略得多。
