关闭channel不会自动释放buffer指针或文件句柄，二者需独立显式处理：directbuffer依赖gc与cleaner异步回收，mappedbytebuffer需手动清理，socketchannel还须配合selectionkey.cancel()防止fd泄漏。
关闭 Channel 不会自动释放关联的 Buffer 指针，也不会自动清理底层文件句柄——这两者是独立管理的资源，必须分别处理。
Buffer 指针不会因 Channel 关闭而自动失效
Buffer（尤其是 DirectBuffer）是 JVM 堆外内存对象，其生命周期由 GC 和 Cleaner 机制控制，与 Channel 是否关闭无直接绑定关系。即使调用 channel.close()，只要仍有强引用指向该 Buffer（例如被缓存、未置 null、仍在回调中使用），它就不会被回收；更关键的是，DirectBuffer 的释放依赖 Cleaner 入队后由 JVM GC 线程异步执行 clean()，这个过程可能延迟数秒甚至更久，尤其在高负载下。
- 常见误判：以为“通道关了，缓冲区就安全了”，结果导致
sun.nio.ch.DirectBuffer实例持续堆积 - 典型症状：
jmap -histo:live显示 DirectBuffer 占用 retained heap 超 85%，java.lang.OutOfMemoryError: direct buffer memory频发 - 验证方式：通过
WhiteBox.getPendingCleanerCount()或 JFR 中jdk.CleanerState事件观察 Cleaner 积压情况
文件句柄需显式触发释放，Channel.close() 仅是必要条件之一
对 FileChannel 或网络 SocketChannel，关闭操作本身只是发起资源释放请求，真正释放文件描述符（fd）依赖完整链路断开：
-
SocketChannel.close()必须配合SelectionKey.cancel()，否则 Selector 仍轮询已失效 fd，造成 epoll wait 空转和句柄泄漏 -
FileChannel关闭后，若曾创建MappedByteBuffer，需手动调用FileMD5Util.freedMappedByteBuffer(mappedByteBuffer)或反射清理其内部Cleaner，否则映射区域长期驻留，句柄无法释放 - Windows 下尤其敏感：未及时释放的 FileChannel 可能导致文件被锁定，后续
delete()或rename()失败
正确释放的最小闭环操作
避免副作用的关键是形成“通道 → 键 → 缓冲区 → 映射区”的全链路清理意识，而非依赖单一 close()：
- 使用 try-with-resources 包裹 Channel，确保
close()在异常时也执行 - 若注册过 Selector，务必在关闭前调用
key.cancel()，并从 Selector 中显式移除（selector.keys().remove(key)） - 对 DirectBuffer，避免长期持有引用；如需复用，用
buffer.clear()或buffer.flip()重置指针，而非反复分配新 Buffer - 对 MappedByteBuffer，关闭 channel 后立即调用自定义释放方法（如基于
sun.misc.Unsafe或java.lang.ref.Cleaner的封装）
不复杂但容易忽略：Channel 关闭只是资源释放链的起点，不是终点。
