Unsafe.allocateMemory绕过GC需配对freeMemory，否则内存泄漏或崩溃；putX/getX无边界检查易越界；禁混用DirectByteBuffer地址；新项目应优先使用MemorySegment+VarHandles。
Unsafe.allocateMemory 会绕过 GC，但必须配对 freeMemory
直接调用 Unsafe.allocateMemory 分配的内存完全脱离 JVM 堆管理，GC 不会扫描、不会移动、也不会回收它。这是性能提升的根源，也是泄漏的起点。
关键点在于：分配和释放必须严格成对出现，且不能依赖对象生命周期自动触发。
-
allocateMemory返回的是long类型的地址值，不是 Java 对象，没有引用计数或可达性语义 - 不调用
freeMemory(address)→ 内存永远驻留，直到进程退出 - 重复调用
freeMemory同一个地址 → 可能引发 SIGSEGV（段错误），JVM 崩溃 - 在多线程中释放前未确保无其他线程正在读写该地址 → 数据竞争或非法访问
putX/getX 系列方法不检查边界，越界写入直接破坏相邻内存
Unsafe.putLong、Unsafe.putInt 等方法不做任何数组长度或内存区域边界校验。它们只认地址 + 偏移量，写到哪就是哪。
常见错误现象：SIGSEGV、IllegalAccessError、随机值读取、JVM 意外退出、甚至影响其他进程（在共享内存场景下）。
- 务必手动计算偏移量，例如
base + 8 * index，避免硬编码 magic number - 分配时预留足够空间，比如要存 100 个
long，至少申请100 * 8字节，再加一点 padding 防踩边界 - 调试阶段可用
Unsafe.copyMemory配合Arrays.fill初始化整块内存，降低脏数据干扰 - 不要在
String、Object实例的字段偏移上乱写 —— 跨 JDK 版本字段布局可能变化，极易崩溃
Unsafe 不是 ByteBuffer，别混用 address 和 buffer.address()
有人试图把 DirectByteBuffer 的地址拿出来交给 Unsafe 操作，这是高危操作。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
DirectByteBuffer 内部确实通过 Unsafe 分配内存，但它封装了清理逻辑（Cleaner）、容量检查、字节序处理等。直接提取其地址并绕过这些机制，等于撕掉安全阀。
-
buffer.address()是受保护的私有方法，需反射调用，且返回值在某些 JDK 版本中可能是 0 或无效值（如 G1 GC 下 buffer 被压缩迁移后） - 即使拿到有效地址，也不能擅自调用
freeMemory—— 这会与DirectByteBuffer自身的 Cleaner 冲突，造成 double-free - 若真需要混合使用，应统一走
MemorySegment（Java 16+），它提供类型安全视图 + try-with-resources 自动释放
生产环境慎用 Unsafe，优先考虑 MemorySegment + VarHandle
sun.misc.Unsafe 在 JDK 9+ 被模块系统限制，默认不可访问；JDK 17+ 中部分方法被标记为 deprecated；未来版本可能彻底移除。它不是“高性能捷径”，而是“遗留兼容通道”。
真正面向长期维护的新项目，应切换到 Java 外部内存 API：
-
MemorySegment.allocateNative(size)返回可关闭资源，配合 try-with-resources 保证释放 -
VarHandle提供类型安全、带内存屏障的读写，自动处理对齐与大小端 - 所有操作都经过运行时边界检查（可选关闭，但默认开启），大幅降低误操作风险
- 底层仍可能映射到
Unsafe，但由 JVM 统一管控，不暴露裸地址
复杂点不在“怎么快”，而在于“怎么稳”——堆外内存一旦出错，日志里往往没有栈踪迹，只有 java.lang.OutOfMemoryError: Direct buffer memory 或静默崩溃。越早放弃裸 Unsafe，越晚半夜被报警叫醒。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
