Java NIO连接池核心是复用Channel、共享Selector、状态可追踪的生命周期管理，而非缓存空闲TCP连接；通过Attachment绑定元数据、定时扫描清理超时连接、异步获取/归还机制实现高效可控的连接管理。
Java NIO 本身不提供连接池，但可以在其基础上构建高效、可控的连接池管理机制。关键不是“复用连接”，而是复用 Channel 实例 + 合理调度 Selector 事件 + 状态可追踪的连接生命周期管理。
连接池的核心职责不是缓存 Socket，而是管理 Channel 生命周期
NIO 连接池和传统 JDBC 连接池逻辑不同：它不维护“已建立但空闲”的 TCP 连接列表，而是在连接活跃时将其注册到 Selector，并在空闲或异常时及时注销、关闭或重连。真正的复用发生在：
- 同一 Channel 可被反复用于多次读写（只要未关闭）
- 多个 Channel 共享一个 Selector 实例，避免线程爆炸
- 连接断开后，可按需触发重建并重新注册，而非每次新建
用 Channel + Attachment 实现连接状态绑定
每个注册到 Selector 的 SocketChannel 都可以携带一个自定义 attachment（如 ConnectionMeta 对象），用来记录连接身份、最后活跃时间、关联请求上下文等信息。这是实现连接复用与超时清理的基础。
- 创建连接时 new SocketChannel.open().configureBlocking(false)，设置 attachment 后 register(selector, OP_CONNECT, meta)
- OP_CONNECT 就绪后调用 finishConnect()，成功则改注 OP_READ；失败则 close 并标记为失效
- OP_READ 就绪时，从 attachment 中取出上下文，驱动业务解码；若读到 EOF 或异常，主动 close 并清理 attachment 引用
空闲连接自动回收与保活控制
连接池必须防止“僵尸连接”堆积。NIO 层面不能依赖 TCP keepalive 做精细控制，需在应用层维护 lastAccessTime：
立即学习“Java免费学习笔记（深入）”；
- 每次读/写操作更新 attachment 中的时间戳
- 单独起一个低频定时任务（如每 5 秒）扫描所有注册的 Channel，剔除超时（如 60 秒无读写）且未在处理中的连接
- 对需要长连的场景（如 MQTT 客户端），可定期发 ping 帧，失败则 close；不依赖系统级 keepAliveTime
连接获取与归还采用非阻塞语义
不要设计成“borrow → use → return”同步三段式，这会破坏 NIO 的事件驱动本质：
- “获取连接”实际是异步发起 connect()，通过 CompletionHandler 或 SelectionKey 回调通知结果
- “归还连接”不是放回池子，而是清除业务上下文引用，让 GC 回收 attachment；Channel 本身仍由 Selector 管理，直到显式 close
- 真正需要“池化行为”的是连接初始化成本（SSL 握手、认证协商），这部分可通过预热连接 + 连接复用减少重复开销
