直接内存溢出（java.lang.outofmemoryerror: direct buffer memory）发生在jvm堆外、由操作系统直接管理的内存区域，是nio中bytebuffer.allocatedirect()分配的本地内存超限所致，不受gc自动回收控制，根本原因是directbytebuffer对象长期存活或cleaner清理延迟导致堆外内存堆积。
直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）发生在 JVM 堆外、由操作系统直接管理的内存区域，不是堆内存，也不受 GC 自动回收控制。它本质是 NIO 中 ByteBuffer.allocateDirect() 分配的本地内存超限，而 JVM 无法及时释放或限制不当所致。
根本触发机制
Java 程序通过 sun.misc.Unsafe 或底层系统调用（如 mmap）向操作系统申请物理内存，这部分内存不经过堆，JVM 只维护一个轻量级的 DirectByteBuffer 对象（在堆内）作为“句柄”。当该对象被 GC 回收时，会触发其内部的 Cleaner 执行 free() 释放对应堆外内存——但这个过程**延迟且不可控**。
一旦出现以下任一情况，就容易堆积未释放的直接内存，最终触发 OOM：
- 大量创建
DirectByteBuffer，但对应的堆内对象长期存活（比如被缓存、静态引用、线程局部变量持有） - GC 频率低或 Full GC 不及时，导致
Cleaner没机会运行 - 显式调用了
System.gc()但未起效（JDK 9+ 默认禁用 Cleaner 的主动触发） - 使用了 Netty 等框架却未正确调用
release()或recycle()，造成 ByteBuf 泄漏
典型业务场景
这类问题多见于高性能 I/O 场景，而非普通业务代码：
- Netty 服务端高并发连接：每个 Channel 分配 DirectByteBuf 处理网络读写，若 Channel 异常关闭未释放资源，缓冲区持续累积
-
大文件零拷贝传输：用
FileChannel.transferTo()+ DirectBuffer 实现高效传输，但循环中反复 allocate 而未复用或清理 - 图像/音视频处理：解码帧数据直接分配 MB 级 DirectBuffer，处理链路长、异常路径未释放
- 未设上限的缓存池：自建 DirectBuffer 缓存池，但缺乏容量控制与淘汰策略
JVM 参数与默认限制
直接内存上限由 -XX:MaxDirectMemorySize 控制，默认值等于 -Xmx（最大堆大小），但很多项目未显式设置，导致实际可用值可能远低于物理内存预期。
例如：java -Xmx2g -jar app.jar → 默认 MaxDirectMemorySize ≈ 2GB；若应用频繁分配 10MB 直接内存且每秒 200 次，不到两分钟就可能耗尽。
更隐蔽的是：Unsafe.allocateMemory()（部分框架底层使用）不受此参数约束，只受操作系统虚拟内存限制，此时 OOM 报错可能变为 Kill process or sacrifice child（Linux OOM Killer 干预）。
如何验证和定位
关键看错误日志是否明确含 Direct buffer memory，再结合以下手段确认：
- 启动时加参数：
-XX:+PrintGCDetails -XX:+PrintReferenceGC，观察 GC 日志中是否频繁出现DirectBuffer清理记录 - 运行时执行：
jstat -gc <pid></pid>查看CCSC（Compressed Class Space）和DC（Direct Memory Capacity）、DU（Direct Memory Used）指标（JDK 11+ 支持） - 导出堆 dump 后用 MAT 或 JProfiler 搜索
DirectByteBuffer实例数量及 retained heap，检查是否有异常强引用链 - 用
Native Memory Tracking (NMT)：启动加-XX:NativeMemoryTracking=detail，再用jcmd <pid> VM.native_memory summary</pid>查看 direct memory 分配总量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
