企业官网建设流程全解析

直接内存的分配与回收核心是 “Native 层分配内存 + Java 层持有引用 + Cleaner 机制回收”，全程需 JVM 与操作系统协同，具体原理如下：

一、直接内存的分配原理

1. 分配触发入口

• 核心途径：通过ByteBuffer.allocateDirect(int capacity)（JDK 推荐）或Unsafe.allocateMemory(long size)（底层 Native 调用）触发分配。
• 关键前提：分配前会检查直接内存已用容量是否超过-XX:MaxDirectMemorySize限制，若超过直接抛出OutOfMemoryError: Direct buffer memory。

2. 分配核心流程

1. 调用 Native 方法（如Unsafe.allocateMemory），向操作系统申请 “堆外内存”（直接内存）。
2. 操作系统在本地内存中划分一块连续空间，返回该空间的起始地址（Native 地址）。
3. 在 Java 堆中创建DirectByteBuffer对象，该对象仅存储 “Native 地址、内存容量、读写指针” 等元数据，不存储实际数据。
4. 为DirectByteBuffer关联Cleaner对象（虚引用），绑定释放直接内存的回调逻辑（Deallocator），为后续回收做准备。
5. 返回DirectByteBuffer对象给应用程序，程序通过该对象的 API（如get()、put()）间接操作 Native 层的直接内存。

3. 分配关键细节

• 分配成本：高于堆内存，需跨 JVM 与操作系统调用，且直接内存的物理空间分配由操作系统管理（如内存对齐、空间分配策略）。
• 无冗余开销：直接内存是原生内存块，无 Java 对象头、对齐填充等堆内存特有的冗余消耗。

二、直接内存的回收原理（与前文释放流程呼应，聚焦 “原理本质”）

1. 回收的核心依赖

• 核心机制：Cleaner虚引用 + JVM 垃圾回收，无需手动干预（Unsafe手动分配除外）。
• 关键对象：Cleaner持有DirectByteBuffer的虚引用和Deallocator释放器，虚引用不影响DirectByteBuffer的 GC 回收。

2. 回收核心流程

1. 应用层释放DirectByteBuffer的所有强引用（如置为null、超出作用域），使其成为 GC 不可达对象。
2. JVM 执行 GC 时，标记DirectByteBuffer为可回收对象，同时将关联的Cleaner加入引用队列（ReferenceQueue）。
3. JVM 后台线程ReferenceHandler扫描引用队列，发现Cleaner后调用其clean()方法。
4. clean()方法触发Deallocator的run()方法，通过Unsafe.freeMemory(Native地址)调用 Native 函数。
5. 操作系统回收对应的直接内存空间，GC 后续将DirectByteBuffer从 Java 堆中彻底回收。

3. 回收关键细节

• 回收时机：依赖 GC 触发，若 GC 迟迟不执行，即使DirectByteBuffer不可达，直接内存也不会立即释放。
• 手动分配特例：若通过Unsafe.allocateMemory直接分配，无Cleaner关联，必须手动调用Unsafe.freeMemory释放，否则导致内存泄漏。

三、分配与回收的核心对比