DirectByteBuffer.allocateDirect()分配堆外内存，本质是JVM调用OS接口申请物理内存并由Cleaner异步回收，受-XX:MaxDirectMemorySize控制，适用于零拷贝I/O等高性能场景。
Java NIO 中通过 ByteBuffer.allocateDirect() 分配堆外直接内存，本质是让 JVM 调用操作系统原生接口申请一块不受 GC 管理的本地内存，并由 DirectByteBuffer 对象在堆中持有一个轻量级引用和清理钩子。它不是“一键快”，而是有明确适用边界和隐含约束的操作。
分配方式与底层行为
调用 ByteBuffer.allocateDirect(1024) 会立即触发以下动作：
- 构造
DirectByteBuffer实例（堆内对象），仅占几十字节 - 调用
Unsafe.allocateMemory()向 OS 申请连续物理内存（如 mmap 或 VirtualAlloc） - 执行
Bits.reserveMemory(size, cap)检查是否超出-XX:MaxDirectMemorySize限制 - 注册一个
Cleaner，绑定Deallocator作为异步释放逻辑
关键配置必须显式设置
堆外内存不走 -Xmx，但受 -XX:MaxDirectMemorySize 控制，默认值等于 -Xmx（JDK 8+）。若程序高频创建 DirectBuffer（如 Netty 每连接多个 ByteBuf），不设该参数极易 OOM。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 推荐按实际负载设置，例如：
-XX:MaxDirectMemorySize=2g - 可通过
java.lang.management.ManagementFactory.getPlatformMXBean(MemoryUsage.class)查看当前使用量 - 注意：
reserveMemory统计的是用户请求容量（cap），不含页对齐冗余；而allocateMemory实际申请量可能略大
回收机制不是“自动即时”的
DirectByteBuffer 对象被 GC 回收后，Cleaner 才会在后台线程中调用 unsafe.freeMemory()。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 如果老年代长期不触发 GC（如 CMS 或 ZGC 配置不当），堆外内存会持续累积
- 不能依赖
byteBuffer = null+System.gc()强制释放——这是不可靠且低效的做法 - 真正可控的方式是复用缓冲区（如 Netty 的
PooledByteBufAllocator）或显式调用cleaner.clean()（仅限极少数需确定性释放的场景）
什么场景适合用 allocateDirect？
不是所有 I/O 都需要堆外内存。它的优势只在特定路径上生效：
- 零拷贝网络传输（如
FileChannel.transferTo()、Socket sendfile） - 高吞吐消息中间件（RocketMQ 刷盘、Kafka 网络层）
- 大文件顺序读写，避免堆内复制开销
- 反之，小数据、短生命周期、纯计算场景用
ByteBuffer.allocate()更轻量
