DirectByteBuffer 通过 Unsafe.allocateMemory() 或 allocateDirect() 在堆外分配内存，对象在堆中而数据在直接内存，依赖 Cleaner 异步释放，不显式清理易致泄漏；零拷贝需 DirectByteBuffer 提供地址指针，HeapByteBuffer 会退化为用户态拷贝；定位泄漏需 NMT、jcmd、jstack 结合分析；Netty 池化复用有线程绑定与 retain/release 匹配要求。
DirectByteBuffer 是怎么分配的
Java 里的直接内存不是 new 出来的，也不是 GC 管的堆内存。它靠 Unsafe.allocateMemory() 或 ByteBuffer.allocateDirect() 触发本地调用，在堆外申请物理内存。
常见错误现象：OutOfMemoryError: Direct buffer memory —— 这和堆内存溢出无关，是 JVM 直接内存限额被突破了（默认通常 64MB，由 -XX:MaxDirectMemorySize 控制）。
-
ByteBuffer.allocateDirect(1024)返回的是DirectByteBuffer实例，对象本身在堆上，但背后那块 1KB 内存不在堆里 - 不显式调用
cleaner（比如通过反射强制触发），这块内存不会随 GC 自动释放，依赖 JVM 的 Cleaner 机制异步回收，有延迟 - 频繁创建/丢弃大块
DirectByteBuffer容易导致直接内存碎片，尤其在长期运行服务中，表现为内存占用持续上涨但没明显泄漏点
零拷贝为什么非要走 DirectBuffer
零拷贝（如 FileChannel.transferTo()）要求数据源/目标至少有一方是直接内存，否则内核无法绕过 JVM 堆做 DMA 传输。
使用场景：NIO 网络传输、大文件 sendfile、Netty 的 PooledByteBufAllocator 默认优先分配 DirectByteBuffer。
立即学习“Java免费学习笔记（深入）”；
- 如果传入的是堆内
HeapByteBuffer，transferTo()会退化成“用户态拷贝 + 系统调用”，多一次 memcpy，吞吐掉一截 -
FileChannel.map()返回的MappedByteBuffer也是直接内存，但它映射的是文件页，生命周期与文件句柄强绑定，unmap()在 Java 里没有公开 API，靠 GC 触发，容易卡住文件删除 - Linux 下
sendfile()和splice()对 buffer 类型有硬性要求；JVM 层面只对DirectByteBuffer暴露了地址指针（address字段），这是零拷贝能成立的底层前提
堆外内存泄漏怎么定位
堆外泄漏不像堆内存那样能用 jmap/jhat 直接看，得靠组合手段交叉验证。
常见错误现象：JVM 堆内存稳定，但进程 RSS 持续上涨；jstat -gc 显示 CCST（Concurrent Cycle Time）异常高；Native Memory Tracking (NMT) 报告 Internal 或 Other 分类暴涨。
- 启动时加
-XX:NativeMemoryTracking=detail，运行中用jcmd <pid> VM.native_memory summary</pid>查直接内存总量 - 对比
java.lang.management.MemoryUsage.getMax()（堆上限）和sun.misc.VM.maxDirectMemory()（直接内存上限），确认是否真超限 - 用
jstack看是否有大量Cleaner线程阻塞在Unsafe.freeMemory()，说明释放路径被某些 native 资源（如未关闭的FileChannel）拖住
Netty 里 PooledDirectByteBuf 的坑
Netty 的池化 DirectByteBuf 能复用内存，但复用逻辑藏在 Recycler 里，和使用者预期常有偏差。
性能影响：池化减少 malloc/free 开销，但若线程间误传 ByteBuf（比如从 IO 线程传到业务线程再还回去），会导致缓存行失效、跨 NUMA 访问变慢。
- 调用
buf.release()不等于内存立刻归还池子，而是先进Recycler.Stack的本地队列，等下次同线程申请时才复用 - 如果 buf 被 retain 了多次，只 release 一次不会真正归还，容易造成“假泄漏”——NMT 显示已分配内存不降，但实际只是被 retain 锁住了
-
Unpooled.directBuffer()每次都 new 新的DirectByteBuffer，适合短生命周期、不可池化场景（如协议头解析），别误当“轻量版”用
直接内存不是银弹，它把 GC 压力换成了更难调试的 native 资源管理问题。最常被忽略的是：你写的 release() 是否真的被执行到了，还是被异常吞掉、被线程中断跳过、或者压根没写。
