Java局部变量强引用因JIT优化失效致弱引用被GC的问题

核心原因：JIT逃逸分析与提前引用失效优化 #

你的问题确实是JIT编译器的逃逸分析（Escape Analysis）+ 提前引用失效优化导致的。Java 11的C2编译器会对局部变量做逃逸分析：如果判定局部变量的引用没有“逃逸”出当前方法（即不会被外部方法、其他线程持有），且后续代码没有直接使用该变量，编译器会认为这个变量对应的对象可以被提前回收——哪怕代码中还没执行到locId = null的语句。

JIT的逻辑是：只要代码逻辑上不再需要这个强引用，就可以释放对象，不需要严格遵守代码的行顺序。因为你在try块里没有直接使用locId变量，仅通过弱引用访问对象，JIT会判定locId已经没有存在的必要，提前将其标记为可回收。

为什么Reference.reachabilityFence(locId)无效？ #

你当前的用法位置错误。reachabilityFence的作用是确保在调用该方法之前，给定对象不会被垃圾回收，且对应的引用不会被JIT优化掉，但它只作用到调用点之前的代码。

你把reachabilityFence放在try块外面，只能保证locId在进入try块之前存活，但try块内部的代码中，JIT依然会因为没有直接使用locId而优化掉这个引用，导致对象在try块执行期间被回收。

可行的解决方案 #

1. 正确使用Reference.reachabilityFence #

把reachabilityFence放在try块内部的关键位置——也就是你需要保证对象存活的操作之后，或者在可能触发GC的操作之前。例如：

SomeObjectStructure locId = generateIdAndRememberInternallyWeakReferenceToIdObject();
try {
  somethingAskingWeakReferenceToId();
  // 确保对象在执行后续操作前不会被回收
  Reference.reachabilityFence(locId);
  doSomethingOnTheBasisOfContentOfRememberedWeakReference();
  // 如果后续还有依赖弱引用的操作，继续添加fence
} finally {
  locId = null;
}

如果try块内有多个依赖弱引用的操作，需要在每个关键操作前调用reachabilityFence，或者直接在try块末尾加一次，确保对象在整个try块执行期间存活。

2. 对局部变量进行“不可优化的使用” #

可以通过一个JIT无法优化掉的操作来强制保留locId的引用，比如调用一个无法被内联的方法传递locId：

// 定义一个无法被JIT内联的方法
private static void keepAlive(Object obj) {
    // 借助Unsafe做空操作，避免被JIT优化
    sun.misc.Unsafe.getUnsafe().addressOf(obj);
}

// 在try块内调用
try {
  somethingAskingWeakReferenceToId();
  keepAlive(locId); // 强制保留引用
  doSomethingOnTheBasisOfContentOfRememberedWeakReference();
} finally {
  locId = null;
}

这种方法不推荐，因为依赖Unsafe非标准API，存在权限与可维护性问题。

3. 已验证有效的ThreadLocal方案 #

你使用ThreadLocal的方案有效，原因是：ThreadLocal的set方法是外部方法，JIT无法确定该方法是否会将引用传递给其他线程或保存到外部，因此会判定locId的引用发生了“逃逸”，不会进行提前回收优化。注意要在finally块中及时清理ThreadLocal，避免内存泄漏。

内容的提问来源于stack exchange，提问作者Artur Linhart