直接内存泄漏导致outofmemoryerror: direct buffer memory，因不走gc、依赖cleaner或显式释放，需通过-xx:nativememorytracking、jfr、netty泄漏检测等定位allocatedirect未释放或配置不当问题。
Java 中直接内存（Direct Memory）泄漏不会触发常规堆 GC，但会实实在在耗尽物理内存，最终抛出 java.lang.OutOfMemoryError: Direct buffer memory。它和堆内存泄漏逻辑不同——对象不在堆里，GC 不管，靠的是 Cleaner 或显式释放机制，一旦漏掉，就积少成多。
确认是不是直接内存问题
看到错误信息带 Direct buffer memory，就不是堆、也不是 Metaspace，而是 NIO 的直接缓冲区超限。常见于：
- 高频使用
ByteBuffer.allocateDirect()且未释放 - Netty、gRPC、Kafka 客户端等底层大量依赖 direct buffer 的框架，连接数多或消息体大时易中招
- 调用
Unsafe.allocateMemory()或 JNI 分配本机内存但未free
启动时开启监控和自动 dump
加 JVM 参数，让问题可追溯：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
-XX:+UnlockDiagnosticVMOptions -XX:+PrintDirectMemoryAccess：打印 direct buffer 分配/释放行为（JDK 9+，需调试启用） -
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/：虽然 dump 是堆快照，但结合日志能交叉验证是否伴随堆正常、仅 direct 耗尽 -
-XX:MaxDirectMemorySize=512m：显式限制上限（默认≈-Xmx），避免失控膨胀，同时让 OOM 更早暴露
排查泄漏点的实操方法
直接内存不走 GC Roots 可达性分析，得换思路：
- 用
jcmd <pid> VM.native_memory summary</pid>查实时 direct 内存用量（JDK 8u60+ 支持，需开启-XX:NativeMemoryTracking=summary） - 用
jstack <pid></pid>看线程栈，重点找io.netty.util.internal.PlatformDependent、sun.nio.ch.DirectBuffer相关调用链 - 在代码中搜索
allocateDirect、Unsafe.allocateMemory、new DirectByteBuffer，检查每处是否配对cleaner.clean()或buffer.clear()+ 显式释放（如 Netty 的ReferenceCountUtil.release()） - 对 Netty 应用，开启
-Dio.netty.leakDetectionLevel=paranoid，它会在 buffer 未释放时打警告栈，精准定位泄漏位置
编码层面的关键防护
不靠运气，靠约束：
- 禁止裸写
ByteBuffer.allocateDirect(n)；封装为工具类，强制 try-with-resources 或 finally 释放 - 用
io.netty.buffer.ByteBuf替代原生ByteBuffer，利用其引用计数机制（retain()/release()） - 缓存 direct buffer 时，必须用
Recycler（Netty）或对象池（如 Apache Commons Pool），严禁无上限复用 - 关闭资源时，确保 channel、connection、pool 全部 shutdown，它们内部持有的 direct buffer 才会批量清理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
