“Java 基础还行吧？那咱们聊聊 IO 吧，BIO、NIO、AIO 各自的模型是什么？为什么 Netty 不用 AIO？”——这是我在面试中特别喜欢用的一段开场。你发现没有，大多数候选人简历上都写着“熟悉 Java IO”，但一追问“同步、异步、阻塞、非阻塞”这四个词的区别，就支支吾吾开始混了。
这篇文章我想把 Java IO 体系彻底拆开讲一遍，从 BIO 到 NIO 再到 AIO，不光是“背概念”，更重要的是把底层机制、线程模型、代码形态全部说透，再加上我在面试候选人和实际项目中用到的经验。无论你是正在准备面试的求职者，还是想搞清楚“为什么 NIO 能支撑高并发”的开发者，这篇文章应该能把你的知识盲区补上。
1. 开篇：先搞清楚“阻塞、非阻塞、同步、异步”这四件事
很多人在看 BIO/NIO/AIO 的时候死记模型图，其实根源问题没理顺。咱们先花点篇幅把四个基础概念对齐，这决定了后面所有内容能不能串起来。
1.1 阻塞与非阻塞：数据没就绪时，你等还是不等？
阻塞和非阻塞讨论的是“调用者在等待结果期间”的状态。拿网络请求举例：你调了read()方法去读数据，如果内核缓冲区里暂时没有数据，阻塞模式下，这个线程会卡在read()调用上，一直等，等到有数据了才返回；而非阻塞模式下，read()会立刻返回一个值告诉你“现在没数据”，你可以先去干别的，过一会儿再回来问。
理解了这个区别，后面的 BIO/NIO 就好懂了。BIO 的所有 IO 操作都是阻塞的，而 NIO 的核心就是“非阻塞 + 多路复用”，让一个线程能同时盯着成千上万个连接。
1.2 同步与异步：数据准备好了，谁帮你把数据搬到内存？
同步和异步讨论的是“数据从内核缓冲区拷贝到用户缓冲区”这个过程由谁来做。同步 IO 下，这个拷贝过程需要调用线程自己参与，哪怕用的是非阻塞 IO，数据到达内核后，你还得自己调read()把数据搬出来；异步 IO 则是你告诉内核：“数据到了之后，你自己帮我搬到用户空间的这个内存地址，搬完了再通知我。”通知到达的那一刻，数据已经躺在你的内存里了。
这个区别特别关键，因为 Java NIO 虽然是“非阻塞”的，但它依然是“同步”的——selector 只是帮你发现“哪个连接的数据准备好了”，真正读数据还得你自己调read()。而 AIO 才是真正意义上的异步，回调触发时数据已经复制完毕。
2. BIO 工作机制拆解：一连接一线程的“原始时代”
BIO 全称是 Blocking IO，阻塞式 IO。它是 JDK 1.4 之前唯一的 IO 模型，也是很多人写网络程序的第一课。逻辑非常简单：服务端启动一个 ServerSocket，循环调用accept()接收客户端连接，每来一个连接就创建一个线程去处理这个连接的读写。
2.1 BIO 的经典代码长什么样
// BIO 服务端示例：一连接一线程 ExecutorService threadPool = Executors.newFixedThreadPool(100); ServerSocket serverSocket = new ServerSocket(8080); System.out.println("BIO Server started on port 8080"); while (true) { // 阻塞在这里，直到有客户端连接进来 Socket socket = serverSocket.accept(); // 每个连接交给线程池处理 threadPool.execute(() -> handleRequest(socket)); } // 处理客户端请求 static void handleRequest(Socket socket) { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter out = new PrintWriter(socket.getOutputStream(), true)) { String line; while ((line = in.readLine()) != null) { System.out.println("收到消息：" + line); out.println("已收到：" + line); } } catch (IOException e) { e.printStackTrace(); } }注意代码里的两个阻塞点。第一个是accept()，它在没有新连接时会一直卡住；第二个是readLine()，如果客户端半天不发数据，这个线程就彻底挂在那了。每个 socket 分配一个线程，线程数量随着客户端数量线性增长。
2.2 线程池优化：伪异步 IO 的折中方案
因为“来一个连接就开一个线程”实在太暴力，后来出现了用线程池改进的做法，也就是上面代码里写的ExecutorService。连接来了不直接new Thread，而是丢进线程池排队执行，线程总数被限制住，不至于把系统资源耗尽。这种方案叫作“伪异步 IO”，因为它只是限制了线程创建数量，底层 IO 依然是阻塞的。
这里有个非常典型的坑：线程池的队列大小和最大线程数怎么配？很多项目直接把线程池无限加大，假设maximumPoolSize=500，结果还是扛不住几千个长连接——因为每个连接占一个线程，500 个线程被 500 个连接死死占住，后面的请求全部排队，最终客户端大面积超时。
2.3 BIO 的致命伤：为什么支撑不了高并发
BIO 的根本问题在于“阻塞”这个字。一个线程在等待 IO 时，CPU 完全闲着，但线程资源（栈内存、上下文切换开销）却被占着不放。默认线程栈大小 1MB，1000 个线程光栈就是 1GB 内存，再加上线程调度开销，系统很快就趴下了。
更要命的是，连接大多是“空闲”的——客户端连上来之后，可能几十秒才发一条心跳消息，但 BIO 模式下连接不释放，线程就得一直陪着它等。大量线程在等一个可能永远不来的数据，这种资源利用率用“惨不忍睹”来形容一点不过分。
所以在高并发、长连接场景下，BIO 基本出局。但话又说回来，BIO 简单、直观、可靠，在连接数少、低并发的传统应用里，它依然是完全够用的方案。
3. NIO 核心机制解析：非阻塞 + 多路复用
NIO（New IO，也叫 Non-blocking IO）在 JDK 1.4 引入，核心是三个组件：Buffer（缓冲区）、Channel（通道）、Selector（选择器）。和 BIO 的“流”不同，NIO 用“通道 + 缓冲区”来读写数据，并且在合适的时候可以让一个线程管理成千上万个连接。
3.1 Buffer 缓冲区：数据搬运的容器
BIO 是面向流的，字节从流里一个一个读，读到什么算什么。NIO 是面向缓冲区的，数据先读到 Buffer 里，你可以随意访问、回退、反复读取其中的任意位置。
Buffer 有四个核心属性：
- capacity：缓冲区容量，创建后不可变
- position：当前读写位置，初始为 0
- limit：可读写的最大边界
- mark：标记位置，配合 reset() 使用
一个经典 bug 是忘了调flip()。读模式下，buffer 从 channel 读入数据后，position 指向了最后一个写入字节的位置；此时如果你想从 Buffer 里把数据读出来写进 Channel，必须先把 position 归零、limit 设置到原来的 position，这个动作就是flip()。很多新手漏了这一步，导致数据读出来全是 0。
// Buffer 的基本用法 ByteBuffer buffer = ByteBuffer.allocate(1024); // 从通道读入数据到 buffer，position 指向最后写入的位置 int readBytes = channel.read(buffer); // 切换为读模式：limit=position, position=0 buffer.flip(); // 从 buffer 写数据到输出通道 while (buffer.hasRemaining()) { outputChannel.write(buffer); } // 清空 buffer：position=0, limit=capacity buffer.clear();还有两个方法容易混：clear()是“假装什么都没读”，重置三个位置；compact()是把未读完的数据挪到头部，然后 position 指向未读数据末尾。如果数据没读完就要继续读文件，用compact()会合适一些。
3.2 Channel 通道：双向的数据管道
BIO 里的 InputStream 和 OutputStream 是单向的，读和写要分开两个流。NIO 的 Channel 是双向的，既能读又能写。常用的 Channel 有四类：
- FileChannel：文件 IO
- SocketChannel：TCP 客户端
- ServerSocketChannel：TCP 服务端
- DatagramChannel：UDP
FileChannel 是 NIO 里一个特殊的存在——它不支持非阻塞模式，因为文件 IO 本身没有“连接”的概念，但它的transferTo()和transferFrom()方法可以实现零拷贝，在某些场景下性能提升非常明显，这个后面单独讲。
3.3 Selector 选择器：NIO 的核心灵魂
Selector 是整个 NIO 体系里最关键的组件。它的作用是“轮询注册在其上的所有 Channel，找出那些已经就绪、可以读或写的连接”，这样你就不用每个连接开一个线程死等了。
// NIO 服务端核心代码 Selector selector = Selector.open(); ServerSocketChannel serverChannel = ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); // 必须非阻塞 serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞等待有就绪的 channel，最多等 1 秒 selector.select(1000); Set<SelectionKey> keys = selector.selectedKeys(); Iterator<SelectionKey> it = keys.iterator(); while (it.hasNext()) { SelectionKey key = it.next(); it.remove(); // 必须手动移除，否则会重复处理 if (key.isAcceptable()) { // 处理新连接 SocketChannel socketChannel = serverChannel.accept(); socketChannel.configureBlocking(false); socketChannel.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { // 处理可读事件 SocketChannel channel = (SocketChannel) key.channel(); ByteBuffer buffer = ByteBuffer.allocate(1024); channel.read(buffer); // ... 业务处理 } } }注意几个细节。第一，configureBlocking(false)必须在 register 之前调用，否则会抛IllegalBlockingModeException。第二，selector.select()是阻塞的，但阻塞的是“有没有事件就绪”，而不是“某个连接有没有数据”，所以一个线程等一万个连接完全没问题。第三，遍历完selectedKeys()之后必须把当前的SelectionKey从集合里移除，不然下次 select 还会把它带出来，导致重复处理同一个事件。
3.4 Redis 的启示：为什么单线程也能扛高并发
很多人对“一个线程管几万连接”没概念，我拿 Redis 举例。Redis 的高性能很大程度就来自经典的 Reactor 模式——一个 IO 线程通过多路复用监听所有连接的事件，来了请求就去处理，没请求就阻塞在 select 上。这种模型的 CPU 利用率极高，没有线程切换开销，没有锁竞争。
NIO 也是同样的思路。用少量线程管理大量连接，吞吐量上去了，线程栈内存占用降下来了，这正是它和 BIO 的本质区别。
4. AIO 工作机制与适用场景：真正的异步非阻塞
AIO（Asynchronous IO，也叫 NIO.2）在 JDK 7 才正式加入。它和 NIO 最大的区别在于：NIO 是“同步非阻塞”，AIO 是“异步非阻塞”。在 NIO 里，selector 通知你连接可读了，你还要自己去调 read 把数据搬出来；AIO 里你直接提交一个读请求，内核把数据拷贝到 buffer 之后才回调你。
4.1 AIO 的代码形态：回调式编程
AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); // 异步接收连接 serverChannel.accept(null, new CompletionHandler<AsynchronousSocketChannel, Void>() { @Override public void completed(AsynchronousSocketChannel channel, Void attachment) { // 继续接收下一个连接 serverChannel.accept(null, this); // 分配缓冲区，异步读取数据 ByteBuffer buffer = ByteBuffer.allocate(1024); channel.read(buffer, buffer, new CompletionHandler<Integer, ByteBuffer>() { @Override public void completed(Integer readBytes, ByteBuffer attachment) { attachment.flip(); // 数据已经在 buffer 里了，直接处理 System.out.println("收到：" + new String(attachment.array(), 0, readBytes)); } @Override public void failed(Throwable exc, ByteBuffer attachment) { exc.printStackTrace(); } }); } @Override public void failed(Throwable exc, Void attachment) { exc.printStackTrace(); } }); // 主线程不能退出，否则守护线程没了 Thread.sleep(Integer.MAX_VALUE);AIO 的编程风格是“告诉内核你要干什么，干完了我通知你”。Java 内部用线程池处理回调，你不需要关心 IO 线程怎么分配，只需要写清楚完成之后做什么。
4.2 为什么生产环境很少直接使用 AIO
这是个非常好的面试题：既然 AIO 是“最先进”的模型，为什么 Netty 这些高性能框架选的是 NIO 而不是 AIO？
原因有几个。第一，Linux 的异步 IO 支持不完善，Java 的 AIO 底层在 Linux 上其实是靠 epoll 模拟的，没有真正用上内核的 native AIO，性能优势打了折扣。第二，AIO 的编程模型复杂，回调嵌套回调，代码可读性和可维护性差。第三，Netty 在 NIO 上做了大量优化，性能已经非常好，AIO 的复杂度带来的收益在大多数业务场景下并不明显。
所以结论是：AIO 在实际项目中的应用远不如 NIO 广泛，面试中考它更多是看你对异步模型的理解深度。要在“选择题”阶段就搞清楚选型逻辑——高并发网络应用首选 NIO + Netty，别盲目追求“先进”。
4.3 同步/异步、阻塞/非阻塞的交叉组合表
很多人老是混这四个词，我整理了一个表格，一眼就能看明白：
| 维度 | 阻塞 | 非阻塞 |
|---|---|---|
| 同步 | BIO：调 read 后线程卡死，直到数据准备好并复制完成才返回 | NIO：调 read 立即返回，但数据复制必须自己再调一次 read 完成 |
| 异步 | — | AIO：提交 read 请求，内核完成数据复制后回调通知，期间线程完全自由 |
注意：异步和阻塞的组合在实践里只有一种具体情况——Java AIO 的同步处理在某些实现中，但真正常见的是 BIO=同步+阻塞、NIO=同步+非阻塞、AIO=异步+非阻塞。
5. 面试高频考点与答题框架
下面这套知识结构，基本覆盖了 Java IO 方向的核心考点。有些是基础题，有些是进阶题，但底层逻辑都是相通的。
5.1 BIO / NIO / AIO 三者的对比总结
这是面试必考题，答题时最好配合表格和例子，别干巴巴背定义。
| 对比项 | BIO | NIO | AIO |
|---|---|---|---|
| 全称 | Blocking IO | New IO / Non-blocking IO | Asynchronous IO |
| IO 模型 | 同步阻塞 | 同步非阻塞 | 异步非阻塞 |
| 线程模型 | 一连接一线程 | 一线程管多连接（多路复用） | 回调触发，异步处理 |
| 底层实现 | Socket | Selector（JDK 1.4） | CompletionHandler（JDK 1.7） |
| 并发能力 | 低，线程数是瓶颈 | 高，可支撑数千/数万连接 | 高，理论上最优 |
| 编程复杂度 | 低，简单直观 | 中，需要理解 Buffer/Selector | 高，回调嵌套难维护 |
| 适用场景 | 连接少、低并发、简单服务 | 高并发、长连接、中间件 | 文件 IO 量极大、回调模型合适的场景 |
答题的时候一定要补充一句：NIO 是现在的主流，Netty 的底层就是基于 NIO 的 Reactor 模型；AIO 由于 Linux 原生异步支持问题，实际应用不如 NIO 广泛。
5.2 网络编程中的 IO 模型五种模式
面试官如果追问“多路复用是什么”，往往是想考察你对 Unix 五种 IO 模型的理解：
- 阻塞 IO（Blocking IO）——对应 BIO
- 非阻塞 IO（Non-blocking IO）——轮询检查，CPU 浪费严重
- IO 多路复用（IO Multiplexing）——select/poll/epoll，对应 NIO
- 信号驱动 IO（Signal-driven IO）——数据到内核后发信号通知
- 异步 IO（Asynchronous IO）——对应 AIO
其中第 3 种 IO 多路复用是重点中的重点。面试官会追问 select、poll、epoll 的区别，你要能说出来：
- select：连接数上限 1024（Linux 默认 fd_set 大小），每次调用都要把所有 fd 从用户态拷贝到内核态，O(n) 遍历
- poll：没有 1024 上限，但依然是“全量拷贝 + 全量遍历”
- epoll：基于红黑树和回调，只通知就绪的 fd 列表，是真正高效的多路复用方案
这段如果能流畅讲出来，基本能证明你不仅知道 NIO 的 API，还理解它底层的操作原语。
5.3 零拷贝技术：transferTo 背后的原理
零拷贝是 NIO 面试的进阶考点。传统的文件传输需要四次拷贝（磁盘 -> 内核缓冲区 -> 用户缓冲区 -> Socket 缓冲区 -> 网卡），四次上下文切换。NIO 的FileChannel.transferTo()可以直接让数据从内核缓冲区“飞”到 Socket 缓冲区，不经过用户态，省掉了两次拷贝和两次上下文切换。
Java 里实现零拷贝的主要方式有两种。一种是mmap方式，把文件映射到内存，读写直接操作内存映射区域，避免了 read/write 的层层复制；另一种是sendfile方式，内核态直接把文件数据从磁盘复制到网卡，用户态完全不用干预。Netty 里常用的FileRegion底层就是 sendfile。
这个考点答得好，能明显给你加分，因为它体现的不只是“会用 API”，而是对操作系统层面的理解。
5.4 实战答题示例：如何完整回答“为什么 BIO 撑不住高并发”
模拟一个标准的面试回答。如果面试官问“BIO 在高并发下会有什么问题”，我的回答框架是这样：
BIO 是同步阻塞模型，服务端每次 accept 一个连接，就要分配一个线程处理这个连接的后续读写。假设有 2000 个客户端同时在线，哪怕其中 1800 个连接都在空闲等待心跳，服务端也至少要创建 2000 个线程。每个线程默认栈大小 1MB，光线程内存就接近 2GB。另外，CPU 在线程间频繁切换，上下文切换开销也大幅上升。最严重的是，空闲连接占着线程不放，新连接来了可能根本没有线程可用，服务端无法 accept，导致客户端连接超时或拒绝服务。
而 NIO 用 Selector 做多路复用，一个线程可以管理成百上千个连接。它有数据才处理、没数据就阻塞，切换的是事件的轮询，而不是线程的切换。所以 NIO 可以用有限的线程支撑海量连接。
这个回答里有数据、有因果链、有对比，面试官听完基本能确定“这个人真懂”。
6. 实操经验与避坑指南
以下是我在实际项目和面试指导中积累的一些干货，希望能帮你避开我踩过的坑。
6.1 NIO 使用中的高频 Bug
Buffer 忘记 flip()。这是 NIO 新手最常见的问题。数据通过 Channel 读进 Buffer 后，position 指向末尾，此时直接channel.write(buffer)会把 position 后面的空数据写出去，要么啥都没有，要么写一堆 0。必须flip()切到读模式，让 position 回到 0、limit 指向实际数据末尾。
Selector 的 selectedKeys 没有 remove。遍历selectedKeys()集合时，处理完一个事件后必须手动移除对应的 SelectionKey。忘了移除，下次 select 会把这个 key 再次返回，导致同一个事件被处理两遍、三遍，甚至死循环。
没有配置为非阻塞模式。想注册到 Selector 上的 Channel 必须先调用configureBlocking(false)，否则注册时会抛IllegalBlockingModeException。这个异常信息已经写得很清楚了，但因为它出现在register()阶段，很多新手会以为是注册本身写错了。
处理完数据后没有清空 Buffer。用clear()还是compact()要想清楚。如果 Buffer 里的数据已经全部处理完，用clear()把 position 归零、limit 恢复为 capacity；如果还有未读数据，要用compact()把剩余内容移到头部，否则下次写入会覆盖掉未读的数据。
6.2 框架之外的思考：什么时候你该自己写 NIO，什么时候直接用 Netty
我经常被问到“要不要自己实现一个 NIO 服务器”。老实说，如果你不是学习目的，千万别。NIO 的坑非常多：半包粘包问题、缓存池管理、背压处理、write 部分写入、Reactor 线程模型选择……这些生产级问题，Netty 已经全部帮你解决好了。
但面试和工作里有个矛盾点：面试官不太可能问 Netty，他们问的是“你懂不懂 NIO 底层原理”。所以学习路径最好是：先用原生 NIO 写一个简单的 EchoServer 练手 -> 理解 Selector、SelectionKey、Buffer 的交互机制 -> 再看 Netty 源码，你会发现一切都非常熟悉。
我一向建议：即使项目最终没用 NIO，候选人如果能画出 Reactor 线程模型图，讲清楚 BossGroup 和 WorkerGroup 的分工，面试基本就稳了。
6.3 关于网络编程性能的一些“反直觉”经验
第一，非阻塞不等于更快。如果你的连接数很少（比如几十个），BIO 的性能不见得差，甚至因为实现简单，代码执行路径更短，吞吐量能打平甚至超过 NIO。NIO 的优势是在高连接数下的“扩展性”，而不是单连接的性能。
第二，缓冲区大小不是越大越好。很多人觉得ByteBuffer.allocate(1024*1024)性能就更高，实际上过大的缓冲区会占据内存，且如果每次只读几百字节，大 buffer 反而浪费。按经验，网络连接初始 buffer 用 4KB 或 8KB 比较合理，需要动态扩容时再加大。
第三，线程数设置别死板。NIO 的 IO 线程也不是越少越好，通常设置为 CPU 核心数或核心数+1，业务线程池再单独配置。如果你用 Netty，默认的线程数是 CPU 核心的两倍，这个值在大部分场景下是合理的。
6.4 最后一个加分项：IO 模型和网络框架的横向知识
面试如果聊得很深入，面试官很可能会延伸问“Redis 为什么是单线程”“Kafka 为什么用 NIO”“Tomcat 的 IO 模式怎么配置”。这些横向问题考察的是你对 IO 模型的迁移理解能力。
Redis 使用单线程 Reactor 模型，因为它的操作全部在内存中，瓶颈是网络 IO 而不是 CPU，单线程避免锁竞争反而更好。Kafka 用 NIO 接收海量网络请求，同时借助 PageCache 和零拷贝把日志落盘的性能优化到极致。Tomcat 从 9.0 之后默认是 NIO 模式，也可以通过配置切换成 NIO2 或 APR。
答这类问题的关键是：先看这个产品的瓶颈在哪，再理解它为什么会选择某种 IO 模型。不是为了用而用，而是为了匹配场景。
我在多次面试中感受最深的一点是：大多数候选人停留在“会用 API”的层面，能把 BIO、NIO、AIO 的原理讲透、能画出模型图、能说出底层操作系统原语的，占比不到三成。这篇文章把最核心的几个知识点拆到了足够深的位置，剩下的就看你怎么把这些内容串起来，结合自己的项目经历形成答题体系了。
如果时间有限，建议优先掌握三件事：第一，清楚说出阻塞/非阻塞、同步/异步的交叉关系；第二，熟练掌握 NIO 的三大组件和 Reactor 模型；第三，能解释清楚为什么 Netty 选 NIO 而不是 AIO。这三个点拿下了，Java IO 方向的面试基本不会拖你后腿。
