-XX:MaxDirectMemorySize 是防止 Direct buffer memory OOM 的关键上限配置，需显式设置为物理内存的1/4～1/3，且与-Xmx之和不超过物理内存80%；它不解决泄漏，仅限流早报错，须配合 NIO 规范使用和运行时监控验证。
配置 -XX:MaxDirectMemorySize 是防止 NIO 直接内存无节制增长引发 OutOfMemoryError: Direct buffer memory 的关键手段，但它不解决泄漏本身，只设上限、早报错。
合理设置参数值
该参数必须显式配置，否则 JVM 默认按 -Xmx 值推算（常等于堆大小），容易与堆争抢物理内存：
- 推荐设为物理内存的 1/4～1/3，且确保
-Xmx + -XX:MaxDirectMemorySize ≤ 物理内存 × 80%（预留系统、线程栈、Metaspace 等开销）； - 例如：32GB 服务器，堆设为
-Xmx12g，可配-XX:MaxDirectMemorySize=8g； - 避免设为 0 或过小（如 1m），否则正常
allocateDirect()都会失败； - 不要盲目设过大（如 16g），否则泄漏可能缓慢积累至系统内存耗尽，被 OOM Killer 杀掉进程。
配合 NIO 缓冲区规范使用
只设上限不管理释放，溢出只是被推迟，泄漏仍在发生：
- 优先使用
ByteBuffer.allocateDirect()，避免直接调用Unsafe.allocateMemory()（后者绕过 JVM 管控）； - 大 Buffer（如 ≥64MB）用完后及时调用
buffer.clear()并置引用为null，促发 Cleaner 回收； - 禁止将
DirectByteBuffer存入静态集合或长生命周期对象中； - Netty 场景下，每个
ByteBuf必须在业务逻辑结束时调用.release()，异常分支也需加finally保证释放。
验证是否真正生效
配置后必须通过运行时工具确认限额被识别、用量可追踪：
- 启动加
-XX:+PrintDirectMemoryDetails，JVM 退出时输出分配/释放统计，适合压测后复盘； - 运行中执行
jcmd <pid> VM.native_memory summary</pid>（需提前启用-XX:NativeMemoryTracking=summary）； - 通过 JMX 访问
java.nio:type=BufferPool,name=direct，监控MemoryUsed和TotalCapacity，若长期逼近上限且不回落，说明存在泄漏。
警惕 Netty 多实例绕过限制
多个中间件（如 RocketMQ、Sentinel、HSF）各自加载 Netty，会创建多个 PooledByteBufAllocator 实例，每个都按 -XX:MaxDirectMemorySize 独立配额申请：
- 7 个 Allocator 各按 1g 分配，实际堆外内存可能超 7g，远超容器限制；
- 若开启
-Dio.netty.tryReflectionSetAccessible=true，Netty 可能走Unsafe分配，彻底绕过 JVM 限额和 NMT 监控； - 用 Arthas 查实例数：
vmtool --action getInstances --className io.netty.buffer.PooledByteBufAllocator； - 容器环境建议同步加
-Dio.netty.maxDirectMemory=0，禁用 Netty 自限，避免与 JVM 参数冲突。
