java nio海量连接下内存优化关键在于精准控制分配、复用与避免拷贝：优先用directbytebuffer配合对象池复用，合理设置缓冲区大小（读8kb–64kb、写4kb–16kb），复用selectionkey attachment并及时清理，文件传输采用transferto/transferfrom或mappedbytebuffer实现零拷贝。
Java NIO 在海量连接场景下能显著降低线程开销，但内存消耗仍可能成为瓶颈——尤其当连接数达十万级时，每个连接持有的缓冲区、通道、选择键等对象会快速累积堆内/堆外内存。优化关键不在于“少用内存”，而在于**精准控制内存分配方式、复用生命周期、避免隐式拷贝**。
优先使用 DirectByteBuffer 替代 HeapByteBuffer
默认的 ByteBuffer.allocate() 分配堆内内存，大量连接意味着大量 byte[] 对象，加重 GC 压力；而 ByteBuffer.allocateDirect() 分配堆外内存，绕过 JVM 垃圾回收，更适合长期存活的网络连接缓冲区。
- 适用于读写缓冲区（如 SocketChannel 的接收/发送 buffer），尤其在高吞吐、长连接场景
- 注意：DirectBuffer 分配成本略高，不要频繁创建销毁；应配合对象池（如 Netty 的 PooledByteBufAllocator）复用
- 监控手段：通过
java.lang.management.ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage()或 Native Memory Tracking（-XX:NativeMemoryTracking=detail）观察直接内存增长
合理设置缓冲区大小，避免过度预留
过大的 buffer（如 1MB）看似提升单次吞吐，实则浪费严重——多数连接实际每次只收发几 KB。内存占用 = 连接数 × 缓冲区大小，10 万连接 × 1MB = 100GB 直接内存，极易 OOM。
- 建议初始值：读缓冲区 8KB–64KB，写缓冲区 4KB–16KB，按业务典型报文长度向上取整
- 动态调整：对长连接可基于流量特征（如连续小包/大块传输）在运行时切换 buffer 大小
- 禁用自动扩容：避免
ByteBuffer.compact()后未重置 limit 导致逻辑容量虚高
复用 SelectionKey 和 Channel 状态对象
每个注册到 Selector 的 Channel 都关联一个 SelectionKey，其中包含 attachment（用户附件）、interestOps、readyOps 等字段。若为每个连接新建 attachment 对象（如自定义 Context 类），会快速堆积堆内存。
- 复用 attachment：使用对象池或静态常量池管理连接上下文，避免每次 accept 都 new Context()
- 及时清理无效 key：调用
key.cancel()+channel.close()后，确保在下一轮 select 前移除 selectedKeys 中该 key（iterator.remove()必须执行） - 慎用 OP_WRITE 注册：仅在 write 返回 0（内核写缓冲区满）时才注册 OP_WRITE，处理完立即取消，否则 key 持续就绪造成空轮询和资源滞留
启用零拷贝与内存映射减少中间数据复制
对于文件传输、静态资源服务等场景，避免将文件内容读入 Java 内存再写出——这既占堆内存又引发多次拷贝。
- 用
FileChannel.transferTo()或transferFrom()实现内核态直传，数据不经过 JVM 堆 - 超大文件（>100MB）可结合
MappedByteBuffer内存映射，由 OS 页面调度按需加载，避免全量载入 - 注意：MappedByteBuffer 不受 GC 管理，需显式调用
Cleaner或依赖 finalize（不推荐），生产环境建议配合 try-with-resources 和明确释放逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
