必须通过反射获取theUnsafe字段并setAccessible(true)，JDK9+还需--add-opens参数；allocateMemory返回的地址需手动管理生命周期，重复free或越界访问将导致JVM崩溃。
Unsafe 实例获取必须绕过安全检查，且仅限内部类加载器
Java 8 及以后版本中，Unsafe.getUnsafe() 会校验调用类是否由 BootstrapClassLoader 加载，普通应用代码直接调用必抛 SecurityException。你无法靠 new Unsafe() 或静态方法拿到实例。
唯一可行路径是反射访问私有静态字段 theUnsafe：
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);
注意：该方式在 JDK 9+ 模块系统下需添加 JVM 参数 --add-opens java.base/jdk.internal.misc=ALL-UNNAMED，否则 setAccessible(true) 失效。
allocateMemory 后的地址必须显式管理生命周期，GC 不管它
unsafe.allocateMemory(size) 返回的是裸指针（long 类型地址），JVM 完全不感知其存在。一旦丢失该值，内存就永久泄露——没有 Finalizer 补救，没有 SoftReference 回收路径。
立即学习“Java免费学习笔记（深入）”；
- 每次
put新 value 前，若旧 value 占用堆外内存，必须先调用unsafe.freeMemory(oldValAddr) -
freeMemory只能调用一次；重复释放同一地址会触发 JVM SIGSEGV 崩溃，不是抛异常 - 不要依赖
finalize()：JVM 不保证执行时机，生产环境等同于不释放 - 推荐搭配
Cleaner（Java 9+）注册清理逻辑，但 Cleaner 本身有延迟，关键路径仍需显式释放
内存布局设计决定读写正确性，错一个字节就全乱
堆外缓存不是“把对象序列化进去就行”，而是你要亲手定义二进制协议。比如 key entry 的典型结构：{ next_addr(8), hash(4), val_addr(8), size(1), len(4) }，其中每个字段长度、偏移、对齐都必须严格一致。
-
size字段若用 1 字节（putByte），但实际字符串长度超 255，后续getInt(addr + offset)就会读错位置，导致哈希查找失败或覆盖相邻 key - 字符串内容必须以 UTF-8 字节数组写入，
str.getBytes()不指定StandardCharsets.UTF_8会导致跨平台解码不一致 - 每个 entry 起始地址必须 8 字节对齐（64 位系统常见要求），否则
unsafe.getInt(addr + 8)可能抛IllegalArgumentException - 每次读写前建议加边界断言：
if (addr + offset >= base + capacity) throw new IndexOutOfBoundsException()（调试期开启，线上可关）
putString / copyMemory 等操作极易越界，崩溃静默无提示
Unsafe 所有 putXXX / getXXX 方法完全不校验地址有效性。越界不会抛 IndexOutOfBoundsException，而是直接破坏相邻内存，轻则数据错乱，重则 JVM crash。
-
unsafe.copyMemory(src, srcOffset, dest, destOffset, bytes)要求 src 和 dest 区域绝对不能重叠，否则行为未定义（JVM 可能静默出错） - 写入字符串时，目标区域必须预留足够空间：size 字段占 1 或 4 字节 + len 字段占 4 字节 + 实际 UTF-8 字节数；少一格就会踩到下一个 key 的
next_addr - 用
copyMemory替代循环putByte更高效，但前提是确认源/目标地址不重叠、长度不超分配范围 - 扩容不是 realloc：必须遍历老表所有非空 entry，重新计算 index 并 copy 到新 base，漏掉任意一个 entry 就丢数据
真正的难点不在“怎么写”，而在“怎么确保每一次读写都在合法范围内”——这需要你在每处指针运算后手动验证，而不是靠语言兜底。
