Java AIO在Windows上基于IOCP实现真异步，在Linux上实为epoll+线程池模拟的伪异步，macOS等平台基本不可用；其“异步性”严重依赖操作系统，跨平台行为割裂且语义错位。
Java 的 AIO（AsynchronousSocketChannel 等）名义上是“异步非阻塞”，但它的底层实现严重依赖操作系统，且在不同平台差异显著——这种差异不是简单的封装适配，而是模型本质的妥协。
Windows 上：基于真正的 IOCP（I/O Completion Ports）
Windows 内核原生支持异步 I/O，AIO 在此平台调用的是 WSARecv/WSASend + IOCP 机制：
- 应用提交读写请求后立即返回，内核在数据收发完成、拷贝到用户缓冲区后，才通过完成端口通知 JVM；
- 整个过程由内核驱动，无需用户线程轮询或额外线程模拟；
- JDK 的 AIO 实现在此平台最接近“标准异步 I/O”定义（POSIX AIO 或 Windows 原生语义）。
Linux 上：epoll + 用户态线程池模拟，实为 Reactor 变种
Linux 内核的原生 aio_read/aio_write 系统调用不支持 socket（仅支持普通文件），因此 JDK 无法直接使用。从 JDK 7 到 JDK 10+，Linux 下的 AIO 实际走的是：
- 用
epoll_wait监听 socket 就绪事件（类似 NIO）； - 一旦就绪，交由内部线程池（如
ForkJoinPool.commonPool()或用户传入的ExecutorService）执行实际的read/write系统调用； - 操作完成后，再回调
CompletionHandler—— 这个“回调”不是内核发起的，而是 JVM 自己调度的线程触发的。
也就是说，Linux 下 Java AIO 并非 Proactor 模型，而是一个“伪异步”：它把同步读写包装成异步 API，但数据搬运仍由用户线程完成，内核只负责通知“可以读写了”，不负责“读完并放好”。
立即学习“Java免费学习笔记（深入）”；
macOS / 其他 UNIX：基本不可用或退化为 NIO 行为
macOS 不支持 POSIX AIO 对 socket 的异步操作，JDK 在该平台通常禁用 AIO 或强制降级为类似 Linux 的模拟策略；部分 BSD 系统虽有 kqueue，但 JDK 未对其做 AIO 适配，实践中也极少启用。
关键结论：AIO 的“异步性”不跨平台，且与操作系统语义错位
Java AIO 的 API 设计试图统一接口，但底层行为割裂：
- Windows 上它是真异步（内核完成数据搬运 + 通知）；
- Linux 上它是“回调式 NIO”，性能无优势，反而增加线程调度和上下文切换开销；
- 调试时，Linux 下
strace -e trace=io_submit,io_getevents几乎看不到 AIO 系统调用，却能清晰捕获epoll_wait—— 这就是它真实运作的证据。
所以，与其说 Java AIO 是跨平台异步抽象，不如说它是“Windows 优先、Linux 妥协、其他平台忽略”的历史产物。
