Java中安全操作堆外内存应优先使用MemorySegment（JDK17+推荐），它封装地址、提供边界检查和生命周期管理；Unsafe因无GC、无越界检查且已标记弃用，不应在生产环境直接使用。
Java 中没有“外函数内存 API”这个标准概念，你实际想问的是如何通过 Unsafe、VarHandle 或 MemorySegment（JDK 14+）安全地操作堆外内存——而其中真正能直接触达裸内存地址的，只有 Unsafe 和 MemorySegment（配合 MemoryAccess），且它们都**不提供“自动内存安全”保障**。所谓“安全”，只能靠开发者约束使用方式，而非 API 自身保证。
为什么 Unsafe.allocateMemory 不该在生产代码里直接用
它绕过 JVM 内存管理，不参与 GC，不触发写屏障，也不做越界检查。一旦指针算错、未对齐访问或忘记释放，就是 SIGSEGV 或静默数据损坏。
-
Unsafe是受限类：JDK 9+ 默认模块化隔离，需启动参数--add-opens java.base/jdk.internal.misc=ALL-UNNAMED才能反射获取实例 - 分配的内存不会被 GC 自动回收，必须显式调用
Unsafe.freeMemory，漏掉就内存泄漏 - 读写需手动计算偏移量，
putInt(addr + 4, 123)这种写法极易出错，且不同平台字节序、对齐要求不同 - JDK 17+ 已标记
Unsafe的内存操作方法为@Deprecated(forRemoval = true)
用 MemorySegment + MemoryAccess 替代裸指针操作（JDK 17+ 推荐）
这是目前最接近“安全堆外内存 API”的标准方案：它把地址封装成不可变段对象，绑定生命周期，并提供类型化、带边界检查的访问器（运行时抛 IndexOutOfBoundsException，而非崩溃）。
- 分配：用
MemorySegment.allocateNative（自动管理 size + alignment），或MemorySegment.mapFile映射文件 - 访问：必须通过
MemoryAccess.getIntAtOffset等方法，传入segment和offset，不是原始地址 - 释放：依赖
Cleaner或try-with-resources（需手动调用close()），避免悬垂引用 - 注意：
MemorySegment默认是“confined”，跨线程传递需显式fork()，否则抛IllegalStateException
MemorySegment seg = MemorySegment.allocateNative(1024, SegmentScope.AUTO);
try {
MemoryAccess.setIntAtOffset(seg, 0L, 42); // 安全：越界会抛异常
int x = MemoryAccess.getIntAtOffset(seg, 0L);
} finally {
seg.close(); // 必须关闭，否则 native 内存不释放
}
为什么 ByteBuffer.allocateDirect 有时比 MemorySegment 更实用
它不暴露地址，但底层仍用 Unsafe 分配堆外内存，且由 JVM 统一管理回收（通过 Cleaner）。适合需要与 NIO Channel 交互、或已有成熟 ByteBuffer 生态的场景。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 获取地址需调用
((DirectBuffer) buf).address()，但这属于内部 API，JDK 20+ 已禁止反射访问DirectBuffer - 不能直接用
MemoryAccess操作，需先转成MemorySegment.ofByteBuffer(buf)（JDK 21+） - 优势在于：GC 可见（虽然不立即回收，但能触发清理）、支持
get/put方法族、天然适配SocketChannel和FileChannel - 缺点：固定 byte 粒度访问，整数/浮点字段需自己处理字节序和偏移
真正的安全底线不是 API，而是作用域与所有权控制
无论用哪种方式，堆外内存的“安全”只存在于明确的生命周期契约中：谁分配、谁释放；谁持有、谁负责同步；段是否可共享、是否已关闭。JVM 不会替你守门。
- 永远不要把
MemorySegment或ByteBuffer传给不受信的第三方库，除非确认它不缓存引用 - 多线程访问同一段内存时，
MemorySegment的fork()不等于线程安全，仍需额外同步（如synchronized或VarHandle的原子操作） - 用 JMH 做性能对比时，记得预热并禁用 GC 日志干扰；堆外内存的吞吐优势常被序列化/拷贝开销抵消
最常被忽略的一点：本地内存不足时，allocateNative 抛 OutOfMemoryError，但错误信息里不提示“堆外”，容易误判为堆内存问题。
