java - 删除未使用的字段是否会导致垃圾回收？

Question

对于涉及异步操作的库，我必须保持对对象的引用，直到满足特定条件。

<支持>(我知道，这听起来很不寻常。所以这里有一些上下文，尽管它可能并不严格相关:该对象可能被认为是一个direct ByteBuffer，它用于JNI 操作。JNI 操作将获取缓冲区的地址。此时，该地址只是一个“指针”，不被视为对字节缓冲区的引用。该地址可能会被使用异步地，稍后时间。因此，必须防止缓冲区被垃圾收集，直到 JNI 操作完成。)

为了实现这一点，我实现了一个基本上等同于此的方法:

private static void keepReference(final Object object)
{
    Runnable runnable = new Runnable()
    {
        @SuppressWarnings("unused")
        private Object localObject = object;

        public void run()
        {
            // Do something that does NOT involve the "localObject" ...
            waitUntilCertainCondition();

            // When this is done, the localObject may be garbage collected
        }
    };
    someExecutor.execute(runnable);
}

想法是创建一个 Runnable 实例，将所需的对象作为 field，将这个 runnable 丢给一个执行器，让 runnable 等待直到条件满足遇见了。执行程序将保留对可运行实例的引用，直到它完成。 runnable 应该 保留对所需对象的引用。因此，只有 满足条件后，执行程序才会释放 runnable，因此，本地对象才有资格进行垃圾回收。

localObject 字段不用于run() 方法的主体中。编译器(或更准确地说:运行时)是否可以检测到这一点，并决定删除这个未使用的引用，从而允许对象过早地被垃圾回收？

_{(我考虑过解决这个问题的方法。例如，在像 logger.log(FINEST, localObject); 这样的“虚拟语句”中使用对象。但即使那样，也无法确保“智能”优化器不会进行一些内联​​并且仍然检测到该对象并未真正被使用)}

---

更新:正如评论中所指出的:这是否可以完全可能取决于确切的Executor 实现(尽管我' d 必须更仔细地分析这个)。在给定的情况下，执行器将是一个 ThreadPoolExecutor。

这可能是迈向答案的一步:

ThreadPoolExecutor 有一个afterExecute 方法。一个人可以重写此方法，然后使用反射大锤深入研究那里作为参数给出的 Runnable 实例。现在，可以简单地使用反射 hack 来找到这个引用，并使用 runnable.getClass().getDeclaredFields() 来获取字段(即 localObject 字段) , 然后获取该字段的值。我认为应该不允许它在那里观察到一个与它最初拥有的值不同的值。

另一个评论指出 afterExecute 的默认实现是空的，但我不确定这个事实是否会影响是否可以删除该字段的问题。

现在，我强烈认为该字段可能不会被删除。但一些明确的引用(或至少更有说服力的论据)会很好。

---

更新 2:基于评论和 answer by Holger ，我认为不是删除“字段本身”可能是个问题，而是周围 Runnable 实例的 GC。所以现在，我认为可以尝试这样的事情:

private static long dummyCounter = 0;
private static Executor executor = new ThreadPoolExecutor(...) {
    @Override
    public void afterExecute(Runnable r, Throwable t) {
        if (r != null) dummyCounter++;
        if (dummyCounter == Long.MAX_VALUE) {
            System.out.println("This will never happen", r);
        }
    }
}

确保 runnable 中的 localObject 确实 尽可能长地存在。但我几乎不记得曾经被迫写过像这几行代码一样大声尖叫“粗暴黑客”的东西......

Answer 1

如果 JNI 代码获取直接缓冲区的地址，那么只要 JNI 代码持有指针，就应该由 JNI 代码本身负责持有对直接缓冲区对象的引用，例如使用 NewGlobalRef 和 DeleteGlobalRef。

关于您的具体问题，这在 JLS §12.6.1. Implementing Finalization 中直接解决了:

Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. …

Another example of this occurs if the values in an object's fields are stored in registers. … Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap.

^{(最后一句很重要)}

在该章中通过一个与您的示例没有太大区别的示例对其进行了说明。简而言之，Runnable 实例中的 localObject 引用将使引用对象的生命周期至少与 Runnable< 的生命周期一样长 实例。

也就是说，这里的关键点是 Runnable 实例的实际生命周期。根据上面指定的规则，如果它也被一个不受优化影响的对象引用，它将被认为是绝对活跃的，即不受优化影响，但即使是 Executor 也不一定是全局的可见对象。

也就是说，方法内联是最简单的优化之一，之后 JVM 会检测到 ThreadPoolExecutor 的 afterExecute 是空操作。顺便说一下，传递给它的Runnable是传递给execute的Runnable，但它不会是与传递给 submit 相同，如果您使用该方法，因为(仅)在后一种情况下，它是 wrapped in a RunnableFuture .

请注意，即使 run() 方法的持续执行也不会阻止 Runnable 实现实例的收集，如 “finalize() called on strongly reachable object in Java 8” 所示。 .

底线是，当您尝试与垃圾收集器对抗时，您将如履薄冰。正如上面引用的第一句话所述:“可以设计优化程序的转换，将可到达的对象数量减少到比天真地认为可以到达的对象数量少。”而我们所有人都可能会发现自己的想法太天真了……

如开头所述，您可能会重新考虑职责。值得注意的是，当您的类有一个 close() 方法时，必须调用该方法以在所有线程完成其工作后释放资源，此所需的显式操作已经足以防止早期收集资源(假设确实在正确的位置调用了该方法)...