Java面试之Java中IO模型（BIO/NIO/AIO）_技术教程

BIO高并发下撑不住因每个连接独占线程，read()阻塞导致线程堆积，引发OOM或延迟飙升；NIO靠Selector单线程管理多路复用，核心是Channel/Buffer/Selector协作；AIO虽真正异步但生态弱、调试难，生产极少使用。

为什么BIO在高并发下会撑不住

因为每个连接都独占一个线程，ServerSocket.accept() 返回一个 Socket 后，通常立刻交给新线程调用 socket.getInputStream().read() —— 这个 read() 是阻塞的，线程会一直挂起直到有数据或连接关闭。1000 个并发连接 = 1000 个线程，光是线程栈内存就吃掉几百 MB，加上上下文切换开销，系统直接变慢甚至 OOM。

常见错误现象：java.lang.OutOfMemoryError: unable to create new native thread，或者 CPU 不高但请求延迟飙升、大量请求超时。

不要在生产环境对每个 Socket 起一个 Thread 处理读写
如果必须用 BIO，至少套一层线程池（如 Executors.newFixedThreadPool(200)），但上限仍硬受限于连接数
setSoTimeout(5000) 可避免线程无限等待，但只是缓解，不解决本质问题

NIO 的核心不是“非阻塞”，而是“单线程管多路”

很多人以为 NIO = 非阻塞 IO，其实关键在 Selector + Channel + Buffer 这套协作机制。channel.configureBlocking(false) 只是前提，真正价值在于：一个线程调用 selector.select() 就能同时监听成百上千个 Channel 的 OP_READ / OP_WRITE 就绪状态。

典型陷阱：ByteBuffer 用完没调 flip() 或 clear()，导致反复读到旧数据或写不进内容；SelectionKey.interestOps() 改完不调 key.interestOps(newOps)，下次 select() 就不会通知你。

selector.select() 默认阻塞，可传毫秒参数做超时控制
注册 OP_ACCEPT 的是 ServerSocketChannel，注册 OP_READ 的是普通 SocketChannel
处理完一次读事件后，若还要继续收数据，需保持 OP_READ 注册状态（别误删）

AIO（NIO.2）为何实际项目里很少见

Java 7 引入的 AsynchronousSocketChannel 确实做到了真正

的异步：调用 read(ByteBuffer, A, CompletionHandler) 后立即返回，内核完成 IO 后回调 completed()。但它依赖操作系统底层支持（Linux 上走 io_uring 或线程池模拟），JVM 层封装较重，调试困难，且生态适配弱。

常见问题：CompletionHandler 中抛异常不会打堆栈，容易静默失败；AsynchronousServerSocketChannel 的 accept() 回调里再递归 accept()，若忘了重新注册，后续连接就卡住。

Netty、Tomcat 等主流框架默认不用 AIO，Tomcat 8+ 的 APR/NIO connector 也不走 AIO
Android 完全不支持 java.nio.channels.AsynchronousChannel
如果你的业务逻辑本身耗时长（比如查 DB、调远程服务），AIO 带来的“零拷贝”优势会被掩盖，反而增加回调管理复杂度

面试常问对比：BIO/NIO/AIO 到底怎么选

没有银弹。BIO 适合低频、短连、管理后台类场景（如 Spring Boot Actuator 端点）；NIO 是高性能网关、RPC 框架、消息中间件的事实标准；AIO 仅建议在明确压测验证过收益、且 OS/JDK 版本可控的极少数场景尝试（如 JDK 17+ Linux 5.10+ io_uring 启用）。

最容易被忽略的一点：NIO 不等于高性能自动到来。写错 ByteBuffer 使用方式、频繁创建 SelectionKey、在 select() 循环里做耗时操作（如 JSON 解析），性能可能比 BIO 还差。

while (running) {
    selector.select(); // 正确：阻塞等待就绪
    Set keys = selector.selectedKeys();
    Iterator iter = keys.iterator();
    while (iter.hasNext()) {
        SelectionKey key = iter.next();
        iter.remove(); // 必须移除，否则下次还出现
        if (key.isReadable()) handleRead(key);
    }
}