直接内存的分配与回收核心是 “Native 层分配内存 + Java 层持有引用 + Cleaner 机制回收”，全程需 JVM 与操作系统协同，具体原理如下：
一、直接内存的分配原理
1. 分配触发入口
- 核心途径：通过
ByteBuffer.allocateDirect(int capacity)（JDK 推荐）或Unsafe.allocateMemory(long size)（底层 Native 调用）触发分配。 - 关键前提：分配前会检查直接内存已用容量是否超过
-XX:MaxDirectMemorySize限制，若超过直接抛出OutOfMemoryError: Direct buffer memory。
2. 分配核心流程
- 调用 Native 方法（如
Unsafe.allocateMemory），向操作系统申请 “堆外内存”（直接内存）。 - 操作系统在本地内存中划分一块连续空间，返回该空间的起始地址（Native 地址）。
- 在 Java 堆中创建
DirectByteBuffer对象，该对象仅存储 “Native 地址、内存容量、读写指针” 等元数据，不存储实际数据。 - 为
DirectByteBuffer关联Cleaner对象（虚引用），绑定释放直接内存的回调逻辑（Deallocator），为后续回收做准备。 - 返回
DirectByteBuffer对象给应用程序，程序通过该对象的 API（如get()、put()）间接操作 Native 层的直接内存。
3. 分配关键细节
- 分配成本：高于堆内存，需跨 JVM 与操作系统调用，且直接内存的物理空间分配由操作系统管理（如内存对齐、空间分配策略）。
- 无冗余开销：直接内存是原生内存块，无 Java 对象头、对齐填充等堆内存特有的冗余消耗。
二、直接内存的回收原理（与前文释放流程呼应，聚焦 “原理本质”）
1. 回收的核心依赖
- 核心机制：
Cleaner虚引用 + JVM 垃圾回收，无需手动干预（Unsafe手动分配除外）。 - 关键对象：
Cleaner持有DirectByteBuffer的虚引用和Deallocator释放器，虚引用不影响DirectByteBuffer的 GC 回收。
2. 回收核心流程
- 应用层释放
DirectByteBuffer的所有强引用（如置为null、超出作用域），使其成为 GC 不可达对象。 - JVM 执行 GC 时，标记
DirectByteBuffer为可回收对象，同时将关联的Cleaner加入引用队列（ReferenceQueue）。 - JVM 后台线程
ReferenceHandler扫描引用队列，发现Cleaner后调用其clean()方法。 clean()方法触发Deallocator的run()方法，通过Unsafe.freeMemory(Native地址)调用 Native 函数。- 操作系统回收对应的直接内存空间，GC 后续将
DirectByteBuffer从 Java 堆中彻底回收。
3. 回收关键细节
- 回收时机：依赖 GC 触发，若 GC 迟迟不执行，即使
DirectByteBuffer不可达，直接内存也不会立即释放。 - 手动分配特例：若通过
Unsafe.allocateMemory直接分配，无Cleaner关联，必须手动调用Unsafe.freeMemory释放，否则导致内存泄漏。
三、分配与回收的核心对比
| 环节 | 核心操作 | 依赖组件 | 关键约束 |
|---|---|---|---|
| 分配 | 操作系统划分配外内存，Java 堆创建引用对象 | Unsafe、DirectByteBuffer | 受MaxDirectMemorySize和系统总内存限制 |
| 回收 | 触发 Native 释放函数，回收堆外内存 | Cleaner、GC、ReferenceHandler | 依赖DirectByteBuff |