Java NIO大规模连接内存优化核心是精准复用与按需映射：优先用DirectBuffer避免堆拷贝，池化缓冲区降低GC压力，合理映射大文件，及时清理SelectionKey及附件。
Java NIO 在大规模连接场景下优化内存管理，核心在于减少堆内对象开销、避免缓冲区冗余分配、控制直接内存生命周期，并配合操作系统级机制降低整体内存压力。关键不是“多分配”，而是“精准复用”和“按需映射”。
合理使用直接内存（DirectBuffer）而非堆内存
默认 ByteBuffer.allocate() 创建堆内缓冲区，每次读写都要经历 JVM 堆复制 + 内核拷贝；而 ByteBuffer.allocateDirect() 分配的是堆外内存（DirectBuffer），可被 Channel 直接操作，绕过 JVM 堆拷贝，尤其适合高频小包或长连接场景。
- 为每个连接分配固定大小的 DirectBuffer（如 8KB～32KB），避免频繁扩容
- 禁用 -XX:+DisableExplicitGC 后，显式调用 System.gc() 无法强制回收 DirectBuffer，应依赖 Cleaner 或手动清理：通过 ((DirectBuffer) buffer).cleaner().clean()
- 监控 DirectMemory 使用：添加 JVM 参数 -XX:MaxDirectMemorySize=1g，并用 jstat -gc <pid> 观察 DCMN（Direct Count Memory）指标
缓冲区池化与复用机制
不为每个连接新建 Buffer，改用缓冲区池（如 Netty 的 PooledByteBufAllocator）或自建轻量池，显著降低 GC 压力和内存碎片。
- 基于 ThreadLocal 维护每线程专属 buffer 池，避免锁竞争
- 对短生命周期连接（如 HTTP 短连接），采用小缓冲区（4KB）+ 池化；对长连接（如 WebSocket），预分配中等缓冲区（16KB）并支持动态扩容
- 注意：池化后必须在 Channel 关闭或异常时显式 release()，否则造成内存泄漏
利用内存映射（MappedByteBuffer）处理大文件连接
当连接涉及大文件传输（如断点续传、日志推送），FileChannel.map() 将文件区域映射为 MappedByteBuffer，数据访问由 OS 页缓存完成，无需 Java 层分配缓冲区，也无拷贝开销。
立即学习“Java免费学习笔记（深入）”；
- 仅映射当前需要访问的文件段（如每次 map 1MB），避免一次性映射 GB 级文件导致虚拟地址空间耗尽
- 使用 MAP_PRIVATE 映射，修改不回写文件，适合只读分析类场景
- 调用 force() 前需确认是否真需落盘；频繁 force() 会抵消映射优势
控制 Selector 与 Channel 生命周期
Selector 本身不占大量内存，但注册其上的每个 SelectionKey 及关联的附件（attachment）、Channel、Buffer 都是潜在内存持有者。
- 连接关闭时务必 cancel() 对应 SelectionKey，并置空 attachment 引用
- 避免在 SelectionKey 中长期持有大对象（如未序列化的上下文、完整请求体）
- 定期调用 keys() 和 selectedKeys() 的 clean 操作（如 keyIterator.remove() 必须执行），防止已处理事件堆积
