Java 9对象防回收机制详解

Java 9 引入的 `Reference.reachabilityFence` 并非修复空指针的“银弹”，而是一个精巧却极易误用的编译器屏障——它唯一的作用是在 JVM 因激进优化（如逃逸分析）错误判定对象不可达时，强制延长其可达性至代码中明确指定的位置；它仅对配合 `Cleaner` 或 `PhantomReference` 管理非堆资源（如 native 内存、文件句柄）的场景有效，且必须紧邻对象最后一次使用、位于同一栈帧内，否则毫无意义；理解它的边界（不挽救真被置 null 的引用、不跨线程生效、不对静态/成员变量起作用）比盲目添加更重要——用错不如不用，而用对了，就能在资源清理的关键窗口期稳稳托住那个“看似还活着、实则已被 JVM 悄悄回收”的对象。

为什么 Reference.reachabilityFence 会在 GC 后突然报 NullPointerException

这不是 bug，是 JVM 真的把对象回收了——哪怕你代码里还“看着”它。Java 8 及以前没这函数，JVM 可能在方法中途就判定某个对象“后面不会再被访问”，提前触发 GC。尤其在本地变量只用于传参、或仅调用其 finalizer / Cleaner 的场景下，reachabilityFence 就是唯一能明确告诉 JVM“这个对象必须活到这儿”的手段。

常见错误现象：Cleaner 回调里访问 native 资源时报 NullPointerException 或 IllegalStateException；PhantomReference 处理逻辑中发现 referent 已为 null，但你确信“刚还用过它”。

• 它不改变对象生命周期语义，只阻止 JVM 过早优化掉“可达性”
• 必须放在“最后一次使用该对象之后”，且在同一栈帧内（不能丢进另一个方法里）
• 对 static 字段、类成员变量无效——它们本就由类或实例强引用着

reachabilityFence 必须和 Cleaner / PhantomReference 配合用

单独调用 reachabilityFence 没意义。它的存在只为配合那些“不靠强引用维持存活”的资源清理机制。比如 Cleaner 注册时传入的是弱引用目标，JVM 一旦判定该目标不可达，就会触发清理，而此时你的业务逻辑可能还没执行完。

使用场景：封装 native 内存（如 MappedByteBuffer）、文件句柄、GPU buffer 等需手动释放的资源，又不想暴露 close() 给用户。

• 别在 finalize() 里用——finalize 已废弃，且行为不可控
• 别在 lambda 或匿名内部类里调用——容易捕获到已出作用域的局部变量，导致 fence 失效
• 如果用了 PhantomReference，fence 必须放在 ReferenceQueue 取出后、“清理动作开始前”的紧邻位置

Cleaner cleaner = Cleaner.create();
MyResource resource = new MyResource();
cleaner.register(resource, new CleanupAction(resource)); // resource 是 cleanup 的参数
// ↓ 这里 resource 必须活到 cleanup 执行完
CleanupAction.doCleanup(resource); // 假设这是个耗时操作
Reference.reachabilityFence(resource); // 关键：放在这儿，不是注册时，也不是构造时

参数只能是对象引用，不能是基本类型或 null

reachabilityFence 接收一个 Object 类型参数，传 null 不报错但完全无效果；传基本类型会编译失败（自动装箱后可能误导你，但实际起作用的是那个包装对象，不是原始值）。

性能影响几乎为零：HotSpot 中它被编译为一条空指令（no-op），只是给 JIT 一个“别优化掉这个引用”的信号。

• 传 this 是常见写法，但要注意：若 this 是局部构造的对象，且方法返回后不再被持有，fence 仍无法阻止回收
• 不要对数组元素单独 fence——得 fence 整个数组引用；同理，对集合里的元素 fence 也没用，得 fence 集合本身
• Android（Dalvik/ART）不支持该方法，Java 9+ JVM 才有，打包时注意 --release 9 或对应 target 版本

最容易被忽略的：它不解决“引用链断裂”，只解决“JVM 误判”

很多人以为加了 reachabilityFence 就高枕无忧，结果还是 NPE。其实它只在一种情况下起作用：对象本应可达，但 JVM 因激进逃逸分析或标量替换，提前认为它“死了”。如果你的对象真被置为 null、从集合移除、或所属实例已被回收，fence 哪怕写十遍也救不回来。

判断是否真需要它？打开 -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime，观察 GC 日志里对象回收时机是否早于你预期的使用点；再用 JFR 录制，看 ObjectCount 事件里该类实例是否异常早退。

真正难处理的是跨线程场景：fence 只作用于当前线程栈帧，无法保另一线程里对同一对象的访问。这种时候，得靠显式同步或 VarHandle.releaseFence 配合引用传递来保证可见性。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java 9对象防回收机制详解》文章吧，也可关注golang学习网公众号了解相关技术文章。