高频网络通信中误用原生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/<pid>/fd/ | wc -l</pid>，持续高于 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<selectionkey></selectionkey>），即内存泄漏已与 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 <pid> | grep "IPv4\|IPv6\|socket"</pid>查看打开的 socket 数量与状态；重点关注can't identify protocol或大量sock条目，它们往往对应未关闭的 Channel -
JVM 层面：用
jcmd <pid> VM.native_memory summary</pid>查看internal和direct内存是否异常增长；再用jmap -histo:live <pid></pid>搜索SelectionKeyImpl、EPollSelectorImpl、NioSocketChannel实例数是否远超当前连接数 -
堆快照分析：用
jmap -dump:format=b,file=heap.hprof <pid></pid>抓取快照，在 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<context></context>），严禁直接塞业务对象；大对象统一由池化管理器（如PooledByteBufAllocator）分配与回收 - 生产环境开启
-Djdk.nio.maxCachedBufferSize=0关闭 ByteBuffer 缓存，避免因缓存未清理导致的堆外内存隐性泄漏
