ByteBuffer.allocateDirect 本身不优化拷贝，仅分配堆外内存；真正减少拷贝需配合 Channel 原生 I/O 调用（如 read/write/transferTo），避免 get/put 或转 String 等堆内操作；应池化复用、控制生命周期，并在解析密集场景换回堆内缓冲区。
bytebuffer.allocatedirect 本身不自动优化变量拷贝开销，它只是把内存分配在堆外；真正减少拷贝的关键，在于配合底层 i/o 系统调用，绕过 jvm 堆中转，让数据在内核与直接内存之间直通。
核心前提：必须走原生 I/O 路径
只有当 ByteBuffer 直接参与 Channel 的 read()/write()、transferTo()/transferFrom() 等操作时，才能跳过“堆内存 ↔ 内核缓冲区”的复制环节。若你仍用 get()/put() 频繁读写内容、或手动 copy 到 byte[] 再处理，反而比堆内缓冲区更慢。
- ✅ 正确用法：SocketChannel.write(directBuf)、FileChannel.read(directBuf)
- ✅ 零拷贝增强：FileChannel.transferTo(position, count, writableChannel)
- ❌ 错误用法：directBuf.get() 解析协议头、directBuf.asCharBuffer().toString()
避免反复分配，用池化复用同一块内存
allocateDirect 每次调用都触发系统 malloc，开销是堆内分配的 3–8 倍。高频 IO 场景下，应杜绝每次请求都 new 一个新 buffer。
- 使用 Netty 的 PooledByteBufAllocator，支持按规格（如 512B/4KB）预分配并回收复用
- 自建简易池时，确保 clear() 后复用，而非 compact()+allocateDirect 新建
- 注意池大小需匹配并发峰值，避免因争抢导致阻塞
控制生命周期，防止内存滞胀
DirectByteBuffer 对象本身很小，在堆上；但其背后那块本地内存由 Cleaner 异步释放，依赖 GC 触发。若堆压力低、GC 少，直接内存可能长期不释放，最终 OOM。
- 通过 JMX 查看 java.nio:type=BufferPool,name=direct 的 memoryUsed 和 totalCapacity
- 设置合理上限：-XX:MaxDirectMemorySize=2g（建议略高于实际峰值用量）
- 避免长期持有 direct buffer 引用（如静态缓存、未关闭的连接上下文）
什么情况该换回堆内缓冲区
不是所有“高频 IO”都适合 allocateDirect。当瓶颈不在数据搬运，而在 Java 层解析逻辑时，堆内反而更稳更快。
- HTTP header 解析、JSON 字段提取等小数据高频 decode：用 ByteBuffer.wrap(heapArray) + 复用 byte[] 数组
- 需要频繁转 String 或 Charset.decode()：堆内有 fast-path 优化，避免额外拷贝
- 容器环境内存受限且 -Xmx 与 MaxDirectMemorySize 冲突时，优先保堆内确定性
