直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）是堆外物理内存耗尽所致，不走GC流程，需通过-XX:MaxDirectMemorySize限制、追踪allocateDirect调用、强制clean或改用堆内缓冲解决。
直接内存溢出（java.lang.outofmemoryerror: direct buffer memory）不是堆内问题，而是 jvm 管理的堆外物理内存耗尽所致。它不走 gc 流程，不会被常规堆分析工具捕获，容易误判为系统资源不足。解决关键在于：**确认是否真用到了直接内存、查清谁在分配、限制上限、强制释放或改用堆内替代方案。**
确认是否触发了 Direct Memory 限制
默认情况下，JVM 的最大直接内存 ≈ 堆最大值（-Xmx），但实际受 -XX:MaxDirectMemorySize 控制。未显式设置时，HotSpot 默认取 Runtime.getRuntime().maxMemory()（即 -Xmx 值），但某些 JDK 版本或容器环境可能受限于 cgroup 内存限额，导致实际可用值远低于预期。
- 启动时加参数打印当前限制：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps配合日志观察是否频繁触发DirectBuffer分配失败 - 代码中主动检查：
System.out.println("MaxDirectMemory: " + sun.misc.VM.maxDirectMemory() / 1024 / 1024 + " MB"); - 用
jstat -gc <pid>查看CCSC（Compressed Class Space）和MU（Metaspace Used）无异常，但 OOM 仍报 Direct buffer，基本可锁定该区域
定位非法或失控的直接内存分配源
常见高危场景：NIO 文件传输、Netty/Undertow 等高性能网络框架、自定义 ByteBuffer 缓冲池、图像处理库（如 OpenCV Java binding）、序列化组件（Kryo with unsafe mode）。
- 搜索项目中所有
ByteBuffer.allocateDirect(...)调用点，尤其注意循环、递归、连接复用未清理的场景 - 检查 Netty 是否启用了
PooledByteBufAllocator但未正确 release —— 每次buffer.release()必须成对出现，漏一次就泄漏一块 - 用
jcmd <pid> VM.native_memory summary（需开启-XX:NativeMemoryTracking=summary）查看 direct memory 实际占用趋势 - 若使用 JFR（Java Flight Recorder），开启
jdk.NativeMemoryUsage事件，可精确追踪每次 allocateDirect 调用栈
强制限制 + 主动回收双保险
不能只靠“调大”，必须设硬上限并确保释放路径可靠。
- 启动参数明确限制：例如
-XX:MaxDirectMemorySize=512m（推荐设为堆内存的 1/4～1/2，避免挤占系统内存） - 禁用隐式清理机制（慎用）：
-Dio.netty.noPreferDirect=true强制 Netty 使用堆内缓冲；或全局关闭-Dsun.nio.PageAlignDirectBuffers=false减少页对齐开销 - 对非 Netty 场景，用
Cleaner或PhantomReference注册回调，在对象不可达时主动调用Buffer.clean()（JDK 9+ 推荐 Cleaner） - 避免长期持有
DirectByteBuffer引用 —— 它本身很小（几十字节），但背后是堆外几 MB，GC 不管它
替代方案：能不用 Direct 就不用
除非追求极致零拷贝性能（如高频小包 socket write、mmap 大文件读写），否则多数场景堆内 buffer 更安全可控。
立即学习“Java免费学习笔记（深入）”；
- 将
allocateDirect替换为allocate，配合channel.write(buffer)时 JVM 自动做堆内→内核拷贝优化（现代 Linux zero-copy 支持已很成熟） - Netty 中配置
UnpooledByteBufAllocator.DEFAULT替代 Pooled，牺牲一点性能换取稳定性 - 文件 IO 优先用
Files.copy(InputStream, Path)或AsynchronousFileChannel，它们内部自动选择最优 buffer 类型
