java nio的“连接复用”指单线程通过selector复用多个非阻塞socketchannel的i/o处理，需配置非阻塞、统一注册、正确管理selectionkey，并闭环处理连接状态与资源回收。
Java NIO 中的“连接复用”并不是指复用已关闭的 TCP 连接（那是 HTTP/1.1 的 Connection: keep-alive 或 HTTP/2 的流复用），而是指**单个线程高效复用多个活跃连接的 I/O 处理能力**——即通过 Selector 实现的 I/O 多路复用。它解决的是“一连接一线程”的资源瓶颈，让一个线程能持续、非阻塞地轮询并响应成百上千个 SocketChannel 的读写就绪事件。
核心是 Selector + 非阻塞 Channel
连接复用的效率根基在于两点：通道必须是非阻塞的，且全部注册到同一个 Selector 上统一调度。
-
ServerSocketChannel 和 SocketChannel 都要调用
configureBlocking(false)，否则注册会抛异常，select() 也无法正常工作； -
每个新接入的客户端连接（SocketChannel）都注册到同一个 Selector，并只关注
OP_READ（或按需加OP_WRITE），避免为每个连接启新线程； - Selector 本身不处理业务逻辑，它只做事件分发；真正耗时的操作（如协议解析、DB 查询）应交由业务线程池异步执行，防止阻塞 Selector 线程。
关键操作不能漏：SelectionKey 的生命周期管理
每次 select() 返回后，必须正确遍历和清理 selectedKeys，否则会导致事件重复触发或内存泄漏。
-
遍历 selectedKeys 时必须用 Iterator 并调用
remove()—— 不是清空集合，也不是用 for-each； -
处理完 OP_READ 后，若缓冲区未读尽（
buffer.hasRemaining()），无需重新注册，下次 select() 仍会通知（默认水平触发 LT 模式）； -
若主动发起写操作且写入未完成（
channel.write(buffer)返回值 OP_WRITE 并在就绪后继续写，完成后务必取消该兴趣集（key.interestOps(0)或重置为OP_READ），否则会持续被唤醒，浪费 CPU。
避免常见性能陷阱
高效不等于写对语法，更取决于运行时行为控制。
-
ByteBuffer 分配要有策略：不要每次读都
ByteBuffer.allocate(1024)—— 建议使用ByteBuffer.wrap(byte[])复用堆外缓冲区，或引入对象池（如 Netty 的 PooledByteBufAllocator）； -
不要在 Selector 线程里做任何阻塞操作：包括日志同步刷盘、文件 IO、synchronized 块长临界区、甚至
System.out.println()（高并发下可能锁争用）； -
连接数极大时（>10k），确认 JVM 使用了 epoll（Linux）而非 select：可通过启动参数
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider强制，或检查strace -e trace=epoll_wait是否调用 epoll 系统调用。
进阶：连接状态与资源回收要闭环
真正的“复用”意味着连接长期存活且稳定流转，而不是频繁断连重连。
-
检测连接失效：读到 0 字节（对端正常关闭）、读异常（IOException）、写异常（ClosedChannelException）时，必须显式调用
key.cancel()并关闭 channel； -
心跳保活建议由业务层实现：NIO 本身不提供心跳机制；可在应用层定时发送 ping 包，并设置读超时（用
socket.setSoTimeout()对 BIO 有效，NIO 中需自己计时器 + SelectionKey.attach() 存时间戳）； -
连接元数据绑定到 SelectionKey：用
key.attach(new SessionContext())关联用户 ID、登录态、上次活动时间等，便于统一管理与踢人逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
