-xx:maxdirectmemorysize默认等于-xmx，二者总和不应超过物理内存的80%，需按应用类型动态调整比例：netty类服务建议1/2~1/3，spring boot类建议≤1/5，spark/hadoop类建议10%~20%。
MaxDirectMemorySize 不是独立运行的参数，它和堆内存配置存在明确的联动关系——这种联动既体现在默认行为上，也反映在资源竞争和稳定性风险中。
默认值自动继承堆上限
若未显式设置 -XX:MaxDirectMemorySize，JVM 会将其默认设为与 -Xmx 相同的值。例如：
• 启动参数为 -Xmx4g 且未配 MaxDirectMemorySize → 直接内存默认上限也是 4GB；
• 这个机制源于 JVM 内部逻辑（如 sun.misc.VM.maxDirectMemory() 的推导），并非硬编码固定值。
物理内存总和不可超限
堆内存与直接内存共享同一块系统资源——物理内存。两者叠加后若超过可用内存，将引发严重后果：
• 在普通服务器上：触发 OutOfMemoryError: Direct buffer memory 或系统级 OOM killer 杀进程；
• 在 Docker 容器中：容器因 RSS 超限被强制 kill（OOMKilled），尤其当 -Xmx + MaxDirectMemorySize > 容器内存限制 时高发；
• 建议总和控制在物理内存的 70%~80% 以内，预留空间给 OS、线程栈、元空间等其他开销。
GC 行为受二者共同影响
虽然直接内存本身不由 GC 直接管理，但它的回收依赖于堆内对象的生命周期：
• DirectByteBuffer 实例本身在堆中分配，其 Cleaner 关联的堆外内存释放动作由 ReferenceHandler 线程触发；
• 若堆内存长期紧张、GC 频繁或 Full GC 滞后，会导致 DirectByteBuffer 对象迟迟不被回收，间接造成直接内存堆积；
• 设置 -XX:+PrintDirectMemoryDetails 可观察 direct buffer 的分配/释放节奏，辅助判断是否因堆 GC 延迟拖累了堆外内存释放。
典型比例需按场景动态调整
没有放之四海而皆准的比例，关键看应用对 NIO 的依赖程度：
• Netty / Kafka 客户端类服务：直接内存 ≈ 堆内存的 1/2～1/3（如 -Xmx4g -XX:MaxDirectMemorySize=2g）；
• Spring Boot 普通 Web 应用：直接内存通常 ≤ 堆内存的 1/5（如 -Xmx4g -XX:MaxDirectMemorySize=512m）；
• Spark Driver 或 Hadoop Client：侧重计算，直接内存占比可压至 10%～20%，避免挤占堆内存导致 GC 压力上升。
