Azul Prime JVM 默认不限制堆外内存（Off-Heap Memory），但可通过 -XX:MaxDirectMemorySize 参数设定上限；需谨慎配置，因堆外内存不可自动回收，超限将直接导致 OutOfMemoryError 或进程崩溃。
azul prime jvm 默认不限制堆外内存（off-heap memory），但可通过 `-xx:maxdirectmemorysize` 参数设定上限；需谨慎配置，因堆外内存不可自动回收，超限将直接导致 `outofmemoryerror` 或进程崩溃。
Azul Prime JVM 作为高性能商业 JVM，广泛用于低延迟、高吞吐场景。与堆内存不同，堆外内存（如 java.nio.DirectByteBuffer 分配的内存）不受 GC 管理，由应用显式申请/释放，因此其使用更易失控。默认情况下，Prime JVM 将 -XX:MaxDirectMemorySize 设为 0（即无限制），与 OpenJDK HotSpot 行为一致。
✅ 正确设置堆外内存上限
使用以下 JVM 启动参数可强制限制堆外内存最大用量（例如限制为 2GB）：
-XX:MaxDirectMemorySize=2g
支持单位包括 k/m/g（大小写不敏感），也可用字节数（如 2147483648）。该值仅约束通过 DirectByteBuffer 分配的直接内存，不影响其他堆外区域（如 JIT 代码缓存、元空间、线程栈、Native 库内存等）。
⚠️ 重要警告：若设值过小（低于应用实际需求），JVM 在 ByteBuffer.allocateDirect() 调用时将立即抛出 OutOfMemoryError: Direct buffer memory，且无法通过 GC 缓解——这与堆内存“GC 回收后可继续运行”有本质区别。
? 诊断高堆外内存的真实原因
盲目设限治标不治本。建议优先排查根源：
-
检查 DirectByteBuffer 泄漏
使用 JDK 工具定位未释放的直接缓冲区：jcmd <pid> VM.native_memory summary scale=mb
关注 Internal 和 Direct 类别用量；或启用详细追踪：
-XX:NativeMemoryTracking=detail -XX:+UnlockDiagnosticVMOptions
-
评估 JIT 代码缓存占用
Prime 的 JIT 编译器会缓存热点代码到堆外。启用日志确认其规模：-XX:+PrintCodeCache
典型用量为几 MB 至百 MB 级，极少达 GB 级；若异常偏高，可配合 -XX:ReservedCodeCacheSize 限制（如 -XX:ReservedCodeCacheSize=512m）。
审查第三方库行为
Netty、Kafka Client、数据库驱动（如 PostgreSQL JDBC）等常大量使用 DirectByteBuffer。检查其配置（如 Netty 的 -Dio.netty.maxDirectMemory）是否与 JVM 层级设置冲突。
✅ 最佳实践建议
-
先监控，再限制：上线前用 jstat -gc
和 jcmd VM.native_memory 建立基线； - 分层设限：-XX:MaxDirectMemorySize 控制 Direct Buffer；-XX:ReservedCodeCacheSize 控制 JIT 缓存；-XX:MaxMetaspaceSize 控制元空间；
- 应用侧防御：在关键路径中显式调用 buffer.clear() / buffer.free()（若使用 Unsafe 或自定义池），并启用 DirectByteBuffer 弱引用跟踪（需 -Djdk.nio.maxCachedBufferSize=0 关闭缓存）；
- 避免零值陷阱：生产环境切勿保留 MaxDirectMemorySize=0，应设为略高于实测峰值的保守值（如实测 1.2GB → 设 1.5g）。
总之，堆外内存管理的核心逻辑是主动治理而非被动拦截：通过精准监控定位泄漏点，辅以合理参数约束，才能兼顾稳定性与性能。
