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() 就不会通知你。
立即学习“Java免费学习笔记（深入）”；
-
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/NIOconnector 也不走 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<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> iter = keys.iterator();
while (iter.hasNext()) {
SelectionKey key = iter.next();
iter.remove(); // 必须移除，否则下次还出现
if (key.isReadable()) handleRead(key);
}
} 
