在Java的网络编程体系里，BIO、NIO、AIO是三个绕不开的概念。不少人对AIO抱有一种朴素的期待：既然AIO是异步IO，那它一定比NIO更先进、性能更好。但真实情况恰恰相反，在Linux服务器上，绝大多数高性能框架（比如Netty）最终都选择了NIO而不是AIO。要理解这个现象，就必须搞清楚两种模型背后的设计思想，也就是Reactor模式和Proactor模式的本质区别。本文将从IO模型原理、核心API、代码实现、实际性能表现四个层面展开对比。
一、同步非阻塞与异步非阻塞的本质区别
先厘清概念。NIO是同步非阻塞IO，AIO（也叫NIO.2）是异步非阻塞IO。这里的同步与异步，判断标准只有一个：真正的IO读写操作（数据在内核缓冲区和用户缓冲区之间的拷贝）由谁来完成。
在NIO模型下，Selector负责监听事件，当Channel就绪后，应用程序自己调用channel.read()或channel.write()去完成数据的实际读写。也就是说，就绪通知是内核做的，搬运数据这件事仍然是应用线程在同步执行。而AIO不一样，应用线程发起read()调用后立刻返回，内核会在数据完全准备好并拷贝到用户缓冲区之后，才回调应用的CompletionHandler。整个读写过程应用线程完全不参与，这才是真正意义上的异步。
可以把两者的差别类比成去餐厅吃饭。NIO像是服务员告诉你“菜好了”，你需要自己去端菜；AIO则是服务员直接把菜端到你桌上，还顺便把餐具摆好了。前者是“就绪通知”，后者是“完成通知”。
二、Reactor模式与Proactor模式的架构差异
NIO对应的经典架构是Reactor模式。Reactor核心角色有三个：Reactor（对应Selector，负责事件分发）、Acceptor（处理连接建立）、Handler（处理具体的读写和业务逻辑）。整个流程是：Selector轮询就绪事件，分发给对应的Handler，Handler自己完成read、decode、compute、encode、write这一整套动作。数据的拷贝发生在应用线程里，所以它是同步的。
Proactor模式则把读写也交给了操作系统内核。应用只负责两件事：发起异步操作和注册完成回调。内核维护一个异步操作队列，完成数据拷贝后通过事件通知机制（比如回调线程）唤醒应用的CompletionHandler。理论上Proactor对应用更友好，编程模型更简洁，但它有一个致命的前提：操作系统必须原生支持真正的异步IO。
问题就出在这里。Linux平台上真正能算异步IO的只有libaio（依赖O_DIRECT，限制极多）和后来的io_uring（JDK长期未适配）。JDK在Linux上实现AIO时，底层其实是用epoll模拟出来的——内核线程池在背后帮你做同步的读写，然后再回调你。这意味着Linux上的Java AIO并没有获得真正的性能收益，反而多了一层线程切换的开销。只有在Windows上，AIO才真正映射到IOCP（I/O Completion Ports），是原生异步的。这就是Netty在Linux上移除AIO支持的根本原因。
三、核心API与代码实现对比
先看NIO的服务端实现，典型的Reactor单线程模型：
Selector selector = Selector.open();
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.bind(new InetSocketAddress(8080));
serverChannel.configureBlocking(false);
serverChannel.register(selector, SelectionKey.OP_ACCEPT);
while (true) {
selector.select(); // 阻塞等待就绪事件
Set<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> it = keys.iterator();
while (it.hasNext()) {
SelectionKey key = it.next();
it.remove();
if (key.isAcceptable()) {
// 接收连接并注册读事件，由应用线程自己完成读写
SocketChannel client = serverChannel.accept();
client.configureBlocking(false);
client.register(selector, SelectionKey.OP_READ);
} else if (key.isReadable()) {
SocketChannel client = (SocketChannel) key.channel();
ByteBuffer buffer = ByteBuffer.allocate(1024);
int n = client.read(buffer); // 数据拷贝由应用线程同步完成
if (n > 0) {
buffer.flip();
client.write(buffer); // 写回也由应用完成
} else if (n == -1) {
client.close();
}
}
}
}这段代码体现了Reactor的典型特征：事件循环不断轮询，读写操作穿插在事件处理逻辑中，应用线程对IO过程有完全的控制权。你可以自由决定一次读多少、是否拆包、写不完怎么办（注册OP_WRITE事件），灵活性非常高。
再看AIO的写法：
AsynchronousServerSocketChannel serverChannel =
AsynchronousServerSocketChannel.open()
.bind(new InetSocketAddress(8080));
serverChannel.accept(null, new CompletionHandler<AsynchronousSocketChannel, Void>() {
@Override
public void completed(AsynchronousSocketChannel client, Void att) {
serverChannel.accept(null, this); // 继续接收下一个连接
ByteBuffer buffer = ByteBuffer.allocate(1024);
client.read(buffer, buffer, new CompletionHandler<Integer, ByteBuffer>() {
@Override
public void completed(Integer result, ByteBuffer buf) {
if (result < 0) {
try { client.close(); } catch (IOException ignored) {}
return;
}
buf.flip();
// 写操作同样是异步的，回调通知完成
client.write(buf, null, new CompletionHandler<Integer, Void>() {
@Override
public void completed(Integer result, Void att) { }
@Override
public void failed(Throwable exc, Void att) {
exc.printStackTrace();
}
});
}
@Override
public void failed(Throwable exc, ByteBuffer buf) {
exc.printStackTrace();
}
});
}
@Override
public void failed(Throwable exc, Void att) {
exc.printStackTrace();
}
});AIO的代码里没有事件循环，全部通过回调串联。注意一个细节：AIO内部有一个默认的线程池来执行回调，多个回调可能在不同线程并发执行，所以同一个连接上的操作存在乱序风险，需要自己做同步控制。而NIO单线程Reactor天然保证一个连接的事件串行处理，不会出现线程安全问题。
四、如何选型：工程实践中的真实考量
从实践经验来看，选型建议非常明确：在Linux服务器上，首选NIO。原因有三点。第一，Linux上AIO是epoll加线程池模拟的，性能不占优；第二，NIO生态成熟，Netty、Tomcat NIO Connector、Dubbo等主流框架都构建在NIO之上；第三，AIO的回调式编程在复杂业务下容易写出多层嵌套的代码，可读性和可维护性都差。
AIO更适合的场景是：运行在Windows上的程序（IOCP原生支持），或者连接数极大但单个连接吞吐量很低、且希望编程模型简单的场景，比如某些物联网网关，海量设备长连接、每条连接只有少量心跳数据，用AIO可以省去自己管理Selector的麻烦。
最后补充一点，如果你追求极致性能又不想手写NIO，直接使用Netty是最务实的选择。Netty通过主从Reactor多线程模型，把accept和读写事件分配到不同的EventLoopGroup，配合零拷贝、内存池化等优化，性能远超手写的AIO代码。理解Reactor和Proactor的意义不在于自己造轮子，而在于看懂这些框架源码时能明白每一步设计背后的IO模型依据。
总结一下：NIO是同步非阻塞，基于Reactor模式，就绪通知加应用自己读写；AIO是异步非阻塞，基于Proactor模式，完成通知加内核代劳读写。两者在Linux上的实际差距远小于理论差距，因为底层都被epoll统一了。技术选型时看平台、看场景、看生态，而不是简单认为异步一定优于同步。
Java AIONIOProactor模型修改时间：2026-09-13 09:54:33