播面

Netty 在 4.0 版本的开发初期（Alpha/Beta 阶段）确实尝试过引入对 Java AIO（NIO.2，即异步 IO）的支持，但在最终发布之前，Netty 的核心开发者 Norman Maurer 决定彻底移除对 AIO 的支持。

这一决定是基于大量的性能测试和架构考量做出的。主要原因可以归结为以下四个核心方面：

1. Linux 平台下 AIO 的“伪异步”问题（核心原因）

Netty 的主要运行环境是 Linux 服务器。然而，Java 7 引入的 AIO（NIO.2）在不同操作系统底层的实现是不同的：

• 在 Windows 上：Java AIO 完美映射了 Windows 底层的 IOCP（I/O Completion Ports），实现了真正的操作系统级别的异步 IO，性能表现极佳。
• 在 Linux 上：当时的 Linux 并没有完善的、适用于网络编程的真异步 IO 机制（当时还没有 io_uring，原生的 AIO 主要是为磁盘 IO 设计的，对网络 Socket 支持很差）。因此，Java 7 在 Linux 下的 AIO 实际上是在用户态使用 epoll + 线程池（Thread Pool）模拟出来的。
• 结果：既然 Linux 下的 Java AIO 底层依然是 epoll，那么 Netty 直接使用自己高度优化的 NIO（基于 epoll）不仅更直接，而且避免了 Java 标准库中间那一层线程池带来的额外上下文切换开销。

2. 性能不仅没有提升，反而可能下降

Netty 团队在实测中发现，在 Linux 系统下使用 AIO 相比于 NIO：

• 吞吐量和延迟：并没有明显的优势，甚至在某些高并发场景下比 Netty 自己封装的 NIO 还要慢。
• 内存与 GC 压力：AIO 的编程模型（Proactor 模式）要求在发起读写操作前就分配好缓冲区（Buffer）。如果连接数极大，但活跃连接少，会导致大量预分配的内存闲置。而 NIO（Reactor 模式）是“就绪可读”时才分配内存读取，对内存的利用率更高。此外，AIO 的回调函数（CompletionHandler）会产生更多的短期对象，增加了垃圾回收（GC）的压力。

3. 架构复杂度和维护成本激增

NIO 和 AIO 代表了两种截然不同的网络编程模型：

• NIO 是 Reactor 模式（就绪通知）：系统告诉你“某个 Channel 可以读/写了”，然后你自己去执行读/写操作。
• AIO 是 Proactor 模式（完成通知）：你告诉系统“帮我读/写这些数据，做完了叫我”，系统完成后执行回调。

Netty 一直是基于 Reactor 模式构建的（它的核心是 EventLoop）。为了强行兼容 AIO 的 Proactor 模型，Netty 的底层架构变得非常复杂，代码变得臃肿不堪。维护两套完全不同的底层逻辑，对于一个开源框架来说成本过高。

4. Netty 找到了更好的替代方案：Native Epoll

既然 Java 标准库提供的跨平台 NIO / AIO 在 Linux 上不够极致，Netty 团队决定绕过 Java 标准库，直接使用 JNI（Java Native Interface）调用 Linux 原生的 epoll 接口（即 netty-transport-native-epoll）。

这种 Native 方案带来了压倒性的优势：

• 支持 Linux 特有的高级特性（如 Edge-Triggered 边缘触发、SO_REUSEPORT 端口复用、TCP_CORK 等）。
• 产生更少的垃圾回收（GC），直接操作 C 堆内存。
• 性能全面碾压了 Java 自带的 NIO 和 AIO。

有了基于 JNI 的 Native Epoll 方案后，Java 自带的 AIO 在 Linux 上彻底失去了存在的意义。

总结

Netty 丢弃 AIO 完全是一个务实的工程决定。因为 AIO 增加了代码复杂度和内存/GC 开销，却未能在 Netty 的主要战场（Linux 服务器）上提供实际的性能提升。相反，Netty 团队将精力集中在了优化基于 epoll 的 Reactor 模型，并推出了 Native 传输层，最终造就了今天 Netty 的超高性能。