高频网络通信中误用原生Selector会同时引发文件描述符和内存泄漏，根源是未正确关闭资源：channel.close()不自动cancel key，导致SelectionKey残留、FD不释放、关联缓冲区及附件无法回收，进而触发Direct Memory OOM与FD耗尽。

高频网络通信中误用原生 Selector（如 Java NIO 的 java.nio.channels.Selector）可能同时引发文件描述符泄漏和内存泄漏——这不是两种独立问题，而是同一根源的并发表现：未正确关闭资源导致 FD 持续增长，而关联的 SelectionKey、Channel、缓冲区（ByteBuffer）及闭包引用无法被回收，进而拖垮内存。

确认是否为 Selector 相关双泄

先做快速验证，避免误判：

• 检查进程 FD 使用量：ls -l /proc//fd/ | wc -l，持续高于 2000 且随运行时间单向增长，基本可锁定 FD 泄漏
• 对比 JVM 堆外内存（Direct Memory）：若 java.lang:type=MemoryPool,name=Direct Memory Pool 的使用量同步飙升，且 sun.nio.ch.EPollArrayWrapper 或 SelChImpl 实例数在堆快照中居高不下，说明 Selector 底层结构未释放
• 观察 GC 行为：频繁 Full GC 但老年代回收率低，且 SelectionKeyImpl 或 AbstractNioChannel（Netty 场景）对象长期存活，Retainers 中常见指向 SelectorImpl 或线程局部变量（如 ThreadLocal），即内存泄漏已与 Selector 绑定

高频通信下 Selector 的典型误用模式

以下操作在连接密集、短生命周期通信（如 API 网关、实时信令）中极易触发双泄：

• 注册后未取消键就关闭 Channel：调用 channel.close() 不等于自动取消注册；必须显式调用 key.cancel() + selector.wakeup()，否则 SelectionKey 残留，FD 不释放，关联的附件（attachment）、缓冲区、回调函数全滞留
• 重复注册同一 Channel：未检查是否已注册就执行 channel.register(selector, ops)，导致多个 SelectionKey 指向同一 fd，后续 cancel 逻辑混乱，FD 被多次计数却只释放一次
• Selector 未 close，仅线程中断：Worker 线程被 interrupt，但 selector.close() 未执行；底层 epoll/kqueue fd 未关闭，JVM 不会自动清理，FD 和内核事件表项永久泄漏
• 附件（attachment）持有强引用大对象：将 ByteBuffer、HttpRequest 或完整上下文塞进 key.attach(obj)，而 key 又未及时 cancel，导致整个对象图无法 GC，同时占用堆内+堆外内存

定位泄漏点的实操步骤

不依赖猜测，用工具链直击根因：

• FD 层面：用 lsof -p | grep "IPv4\|IPv6\|socket" 查看打开的 socket 数量与状态；重点关注 can't identify protocol 或大量 sock 条目，它们往往对应未关闭的 Channel
• JVM 层面：用 jcmd VM.native_memory summary 查看 internal 和 direct 内存是否异常增长；再用 jmap -histo:live 搜索 SelectionKeyImpl、EPollSelectorImpl、NioSocketChannel 实例数是否远超当前连接数
• 堆快照分析：用 jmap -dump:format=b,file=heap.hprof 抓取快照，在 VisualVM 或 Eclipse MAT 中筛选 SelectionKeyImpl，查看其 channel 字段是否指向已断开的连接，并追踪 Retained Heap 最大的几个 key 的 attachment 和 owner selector

修复与加固建议

从编码习惯到架构设计逐层设防：

• 所有 channel.register() 前加判断：if (channel.keyFor(selector) == null) { ... }，杜绝重复注册
• 所有 channel.close() 必须包裹在 try-finally 中，并在 finally 里执行 if (key != null && key.isValid()) key.cancel()
• Selector 生命周期与线程强绑定：在线程 shutdown 钩子（Runtime.getRuntime().addShutdownHook）或 @PreDestroy 中显式调用 selector.close()
• 附件（attachment）只存轻量 ID 或弱引用容器（如 WeakReference），严禁直接塞业务对象；大对象统一由池化管理器（如 PooledByteBufAllocator）分配与回收
• 生产环境开启 -Djdk.nio.maxCachedBufferSize=0 关闭 ByteBuffer 缓存，避免因缓存未清理导致的堆外内存隐性泄漏