Java 8 中强可达对象上的 Finalize() 调用

我们最近将消息处理应用程序从 Java 7 升级到 Java 8。自升级以来，我们偶尔会遇到一个异常，即流在读取时已关闭。日志显示终结器线程正在调用finalize()在保存流的对象上（进而关闭流）。

代码的基本轮廓如下：

MIMEWriter writer = new MIMEWriter( out );
in = new InflaterInputStream( databaseBlobInputStream );
MIMEBodyPart attachmentPart = new MIMEBodyPart( in );
writer.writePart( attachmentPart );

MIMEWriter and MIMEBodyPart是本土 MIME/HTTP 库的一部分。MIMEBodyPart延伸HTTPMessage，其中有以下内容：

public void close() throws IOException
{
    if ( m_stream != null )
    {
        m_stream.close();
    }
}

protected void finalize()
{
    try
    {
        close();
    }
    catch ( final Exception ignored ) { }
}

异常发生在调用链中MIMEWriter.writePart，如下：

1. MIMEWriter.writePart()写入该部分的标题，然后调用part.writeBodyPartContent( this )
2. MIMEBodyPart.writeBodyPartContent()调用我们的实用方法IOUtil.copy( getContentStream(), out )将内容流式传输到输出
3. MIMEBodyPart.getContentStream()仅返回传递给构造函数的输入流（参见上面的代码块）
4. IOUtil.copy有一个循环从输入流中读取 8K 块并将其写入输出流，直到输入流为空。

The MIMEBodyPart.finalize()被调用时IOUtil.copy正在运行，并且出现以下异常：

java.io.IOException: Stream closed
    at java.util.zip.InflaterInputStream.ensureOpen(InflaterInputStream.java:67)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:142)
    at java.io.FilterInputStream.read(FilterInputStream.java:107)
    at com.blah.util.IOUtil.copy(IOUtil.java:153)
    at com.blah.core.net.MIMEBodyPart.writeBodyPartContent(MIMEBodyPart.java:75)
    at com.blah.core.net.MIMEWriter.writePart(MIMEWriter.java:65)

我们在其中添加了一些日志记录HTTPMessage.close()记录调用者的堆栈跟踪并证明它肯定是正在调用的终结器线程的方法HTTPMessage.finalize() while IOUtil.copy()在跑。

The MIMEBodyPart对象肯定可以从当前线程的堆栈访问，如下所示this在堆栈帧中MIMEBodyPart.writeBodyPartContent。我不明白为什么 JVM 会调用finalize().

我尝试提取相关代码并在我自己的机器上紧密循环运行它，但我无法重现该问题。我们可以在一台开发服务器上可靠地重现高负载的问题，但任何创建较小的可重现测试用例的尝试都失败了。代码在Java 7下编译，但在Java 8下执行。如果我们切换回Java 7而不重新编译，则不会出现该问题。

作为解决方法，我使用 Java Mail MIME 库重写了受影响的代码，问题已经消失（大概 Java Mail 不使用finalize()）。然而，我担心其他finalize()应用程序中的方法可能被错误调用，或者 Java 正在尝试对仍在使用的对象进行垃圾收集。

我知道当前的最佳实践建议不要使用finalize()我可能会重新访问这个本土图书馆以删除finalize()方法。话虽这么说，以前有人遇到过这个问题吗？有人对原因有任何想法吗？

这里有点猜测。即使堆栈上的局部变量中有对对象的引用，并且即使存在active调用堆栈上该对象的实例方法！要求是该对象是无法到达的。即使它在堆栈上，如果后续代码没有触及该引用，它也可能无法访问。

See 这个另一个答案有关如何在引用对象的局部变量仍在范围内时对对象进行 GC 的示例。

下面的示例说明了如何在实例方法调用处于活动状态时最终确定对象：

class FinalizeThis {
    protected void finalize() {
        System.out.println("finalized!");
    }

    void loop() {
        System.out.println("loop() called");
        for (int i = 0; i < 1_000_000_000; i++) {
            if (i % 1_000_000 == 0)
                System.gc();
        }
        System.out.println("loop() returns");
    }

    public static void main(String[] args) {
        new FinalizeThis().loop();
    }
}

虽然loop()方法处于活动状态，任何代码都不可能对引用执行任何操作FinalizeThis对象，因此无法访问。因此它可以被最终确定并被 GC 处理。在 JDK 8 GA 上，这会打印以下内容：

loop() called
finalized!
loop() returns

每次。

类似的事情可能会发生MimeBodyPart。它是否存储在局部变量中？ （看起来是这样，因为代码似乎遵守字段以m_字首。）

UPDATE

在评论中，OP 建议进行以下更改：

    public static void main(String[] args) {
        FinalizeThis finalizeThis = new FinalizeThis();
        finalizeThis.loop();
    }

通过此更改，他没有观察到最终确定，我也没有。但是，如果进行进一步的更改：

    public static void main(String[] args) {
        FinalizeThis finalizeThis = new FinalizeThis();
        for (int i = 0; i < 1_000_000; i++)
            Thread.yield();
        finalizeThis.loop();
    }

最终确定再次发生。我怀疑原因是没有循环，main()方法是解释的，而不是编译的。解释器对于可达性分析可能不太积极。随着产量循环的到位，main()方法被编译，并且 JIT 编译器检测到finalizeThis已变得无法访问，而loop()方法正在执行。

触发此行为的另一种方法是使用-XcompJVM 的选项，强制方法在执行前进行 JIT 编译。我不会以这种方式运行整个应用程序——即时编译所有内容可能会非常慢并且占用大量空间——但它对于在小测试程序中清除此类情况非常有用，而不是修补循环。