Java NIO内存泄漏主要指DirectByteBuffer堆外内存泄漏，表现为RES持续增长、OOM Direct buffer memory、native_memory中Direct区飙升；需通过NMT、jcmd等工具定位，修复方式包括复用缓冲区、及时释放、限制MaxDirectMemorySize。
Java 中 NIO 内存泄漏主要指堆外内存（DirectByteBuffer）泄漏，它不经过 JVM 堆管理，不受 GC 直接控制，但若分配后未释放或引用未清理，会导致物理内存持续上涨、OutOfMemoryError: Direct buffer memory 报错，甚至系统级内存耗尽。
一、确认是不是 NIO 堆外内存泄漏
满足以下现象中的 2 条，高度怀疑是 DirectByteBuffer 泄漏：
- 进程物理内存（
top或ps aux的 RES 列）持续增长，远超-Xmx设置值 - JVM 堆内存（
jstat -gc <pid></pid>中的OU/OGC）稳定，但服务仍频繁 OOM - 日志中出现
java.lang.OutOfMemoryError: Direct buffer memory -
jcmd <pid> VM.native_memory summary scale=MB</pid>显示Internal或Direct区域持续飙升
✅ 小技巧：用
jmap -histo:live <pid> | grep DirectByteBuffer</pid>查看当前 DirectByteBuffer 实例数。若长期 > 数千且只增不减，基本坐实。
二、常见泄漏原因与对应修复
使用 ByteBuffer.allocateDirect() 后未释放
// ❌ 危险写法：分配后无清理，GC 不会回收堆外内存 ByteBuffer buf = ByteBuffer.allocateDirect(1024 * 1024); // ... 使用中 // 忘记 clean 或未触发 Cleaner 回收
✅ 正确做法：
立即学习“Java免费学习笔记（深入）”；
-
优先使用 try-with-resources（JDK 12+ 支持
Cleaner自动注册，但需确保ByteBuffer是可关闭资源） - 手动调用
clean()（不推荐直接用，有兼容风险） - 更稳妥：复用
ByteBuffer，配合clear()/compact()，避免高频分配
// ✅ 推荐：池化 + 显式释放（如 Netty 的 PooledByteBufAllocator）
// 或使用 JDK 自带的 Cleaner（需反射调用，生产慎用）
Field cleanerField = buf.getClass().getDeclaredField("cleaner");
cleanerField.setAccessible(true);
Cleaner cleaner = (Cleaner) cleanerField.get(buf);
if (cleaner != null) cleaner.clean(); // 触发释放⚠️ 注意：JDK 9+ sun.misc.Cleaner 已迁移至 jdk.internal.ref.Cleaner，反射方式需适配版本。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
NIO Channel / Selector 持有未关闭的 DirectBuffer
例如 FileChannel.map()、SocketChannel.read() 返回的 ByteBuffer 若被缓存或长期持有（如放入静态队列），会造成泄漏。
✅ 解决：
- 避免将 DirectBuffer 存入静态集合、缓存或长生命周期对象中
- 使用完立即丢弃引用，必要时
.clear()后归还到缓冲池 - 检查框架行为：Ehcache、Netty、Spring WebFlux 等若配置了 direct buffer 缓存，需限制大小
第三方库滥用 Unsafe.allocateMemory
某些高性能库（如 Chronicle-Bytes、FST）底层调用 Unsafe 分配内存，若未配套 freeMemory()，极易泄漏。
✅ 解决：
- 查阅该库文档，确认是否需手动释放
- 在
finalize()或close()方法中显式释放（如有） - 升级到已修复版本（如 Netty 4.1.100+ 对
PooledByteBuf的 Cleaner 调用更健壮）
三、排查工具与关键命令
| 工具 | 用途 | 示例 |
|---|---|---|
jcmd <pid> VM.native_memory summary scale=MB</pid> |
查看堆外内存各区域用量 | 关注 Direct 和 Mapped 行 |
jstat -gc <pid></pid> |
排除堆内干扰，确认 OOM 非 heap 引起 | 若 OU 稳定但进程 RES 暴涨 → 指向堆外 |
pstack <pid></pid> + jstack <pid></pid>
|
结合线程栈，看是否卡在 Unsafe.park 或 FileChannelImpl
|
可能是阻塞在 buffer 等待释放 |
Native Memory Tracking (NMT) |
最准方式：启动时加 -XX:NativeMemoryTracking=detail，再 jcmd <pid> VM.native_memory detail</pid>
|
可定位到具体类/方法分配源头 |
? 启用 NMT 示例启动参数：
java -XX:NativeMemoryTracking=detail -Xmx4g -jar app.jar
四、预防性配置与最佳实践
- 设置堆外内存上限（防失控）：
-XX:MaxDirectMemorySize=512m（默认≈-Xmx，不设易爆） - 限制 NIO 缓冲区最大缓存尺寸（如 Netty）：
-Dio.netty.maxDirectMemory=512000000 - 使用成熟缓冲池（如 Netty
PooledByteBufAllocator），而非裸allocateDirect - 在
try-finally或AutoCloseable中统一释放逻辑，避免遗漏 - CI/CD 加入内存基线测试：用 JMH +
jcmd native_memory对比 buffer 分配前后差值
不复杂但容易忽略
