为什么java和c#中有终结器？

Question

我不太明白为什么java和c#等语言中有终结器。 AFAIK，它们：

• 不保证运行（在java中）
• 如果它们确实运行，它们可能会在相关对象成为最终确定的候选对象后运行任意时间
• 并且（至少在java中），它们会产生惊人的巨大性能甚至坚持上课。

那么为什么要添加它们呢？我问了一位朋友，他含糊地说“你希望有一切可能的机会清理数据库连接之类的东西”，但在我看来这是一种不好的做法。为什么您应该依赖具有上述属性的东西来处理任何事情，即使是作为最后一道防线？尤其是，如果任何 API 中都设计了类似的东西，那么该 API 就会被嘲笑为不存在。

Answer 1

嗯，在某些情况下它们非常有用。

在 .NET CLR 中，例如：

• 不保证运行

如果程序没有被终止，终结器最终将始终运行。只是不确定何时运行。

• 如果它们确实运行，它们可能会在相关对象成为最终确定的候选对象后运行任意时间

这是事实，但是它们仍然运行。

在.NET 中，这非常非常有用。在 .NET 中，将本机非 .NET 资源包装到 .NET 类中是很常见的。通过实现终结器，您可以保证正确清理本机资源。如果没有这个，用户将被迫调用方法来执行清理，这会大大降低垃圾收集器的效率。

确切地知道何时释放您的（本机）资源并不总是那么容易 - 通过实现终结器，您可以保证它们将被正确清理，即使您的类以不太完美的方式使用。

• 并且（至少在 Java 中），即使坚持在一个类上，它们也会造成惊人的巨大性能损失

同样，.NET CLR 的 GC 在这里具有优势。如果您实现了正确的接口 (IDisposable)，并且开发人员正确实现了它，您就可以防止发生昂贵的终结部分。完成此操作的方法是，执行清理的用户定义方法可以调用 GC.SuppressFinalize，绕过终结器。

这为您提供了两全其美的效果 - 您可以实现终结器和 IDisposable。如果您的用户正确处理您的对象，则终结器不会产生任何影响。如果不这样做，终结器（最终）将运行并清理您的非托管资源，但在运行时您会遇到（小）性能损失。

Answer 2

嗯，你在这里画的图画有点太乐观了。也不保证终结器能够在 .NET 中运行。典型的事故是终结器抛出异常或终结器线程超时（2 秒）。

当 Microsoft 决定在 SQL Server 中提供 .NET 托管支持时，这就出现了问题。重新启动应用程序以解决资源泄漏的应用程序类型不被认为是可行的解决方法。 .NET 2.0 获得了关键终结器，通过从 CriticalFinalizerObject 类派生来启用。此类的终结器必须遵守约束执行区域 (CER) 的规则，CER 本质上是抑制异常的代码区域。您在 CER 中可以做的事情非常有限。

回到你原来的问题，终结器对于释放内存以外的操作系统资源是必要的。垃圾收集器很好地管理内存，但不会执行任何操作来释放笔、画笔、文件、套接字、窗口、管道等。当对象使用此类资源时，必须确保在使用完后释放该资源它。终结器确保这种情况发生，即使程序忘记这样做。你几乎从来不会自己编写带有终结器的类，操作资源是由框架中的类包装的。

.NET 框架还有一种编程模式来确保尽早释放此类资源，以便该资源不会在终结器运行之前徘徊。所有具有终结器的类还实现 IDisposable.Dispose() 方法，允许您的代码显式释放资源。 .NET 程序员经常忘记这一点，但这通常不会导致问题，因为终结器确保它最终会完成。许多 .NET 程序员彻夜难眠，担心所有 Dispose() 调用是否都得到处理，并且论坛上已启动大量与此相关的主题。爪哇人一定是比较幸福的一群人。

---

跟进您的评论：终结器线程中的异常和超时是您不必担心的事情。首先，如果您发现自己正在编写终结器，请深呼吸并问问自己是否走在正确的道路上。终结器是针对框架类的，您应该使用这样的类来使用操作资源，您将免费获得内置于该类中的终结器。一直到 SafeHandle 类，它们都有一个关键的终结器。

其次，终结器线程失败是严重的程序失败。类似于出现内存不足异常或被电源线绊倒并拔掉机器插头。除了修复代码中的错误或重新布线之外，您对此无能为力。对于 Microsoft 来说，设计关键的终结器非常重要，他们不能依赖所有为 SQL Server 编写 .NET 代码的程序员来获得正确的代码。如果您自己弄乱了终结器，则不承担此类责任，接到客户电话的将是您，而不是 Microsoft。

Answer 3

在 Java 中，终结器的存在是为了允许清理外部资源（存在于 JVM 外部并且当“父”Java 对象存在时无法进行垃圾收集的资源）。这一直是很少见的。例如，如果您正在与某些自定义硬件进行交互。

我认为 java 中的终结器不能保证运行的原因是它们在程序终止时可能没有机会这样做。

您可以使用“纯”java 中的终结器做的一件事是使用它来测试终止条件 - 例如检查所有连接是否已关闭，如果没有关闭则报告错误。您不能保证错误总是会被捕获，但它可能至少在某些时候会被捕获，这足以揭示错误。

大多数 Java 代码不调用终结器。

Answer 4

如果您阅读有关 Finalize() 的 JavaDoc，它会说它是“当垃圾收集确定不再有对该对象的引用时，由对象上的垃圾收集器调用。子类会重写 Finalize 方法来处理系统资源或执行其他清理工作。”

http://java.sun.com/ javase/6/docs/api/java/lang/Object.html#finalize

这就是“原因”。我想你可以争论他们的实施是否有效。

我发现 Finalize() 的最佳用途是通过释放池资源来检测错误。大多数泄漏的对象最终都会被垃圾收集，并且您可以生成调试信息。

class MyResource {
    private Throwable allocatorStack;

    public MyResource() {
        allocatorStack = new RuntimeException("trace to allocator");
    }

    @Override
    protected void finalize() throws Throwable {
        try {
            System.out.println("Bug!");
            allocatorStack.printStackTrace();
        } finally {
            super.finalize();
        }
    }
 }

Answer 5

它们的目的是释放本机资源（例如套接字、打开的文件、设备），这些资源在对对象的所有引用都被破坏之前无法释放，这是特定调用者会做的事情（一般来说）无从得知。另一种选择是微妙的、无法追踪的资源泄漏...

当然，在许多情况下，作为应用程序作者您知道只有一个对数据库连接的引用（例如） ;在这种情况下，终结器不能替代当您知道已完成它时正确关闭它。

Answer 6

在 .Net 领域，无法保证它们何时运行。但他们会跑。

Answer 7

您指的是 Object.Finalize 吗？

根据 msdn 的说法，“在 C# 代码中，Object.Finalize 不能被调用或覆盖”。事实上，他们建议使用Dispose方法，因为它更可控。

Answer 8

.NET 中的终结器还有一个额外的复杂性。如果类有终结器并且没有得到 Dispose()'d，或者 Dispose() 没有抑制终结器，则垃圾收集器将推迟收集，直到压缩第 2 代内存（最后一代）之后，因此该对象被“排序”的”，但不完全是内存泄漏。 （是的，它最终会被清理，但很可能直到应用程序终止为止。）

正如其他人提到的，如果一个对象拥有非托管资源，它应该实现 IDisposable 模式。开发人员应该意识到，如果一个对象实现了 IDisposable，那么它的 Dispose() 方法应该始终被调用。 C# 提供了一种使用 using 语句自动执行此操作的方法：

using (myDataContext myDC = new myDataContext())
{
    // code using the data context here
}

using 块在块退出时自动调用 Dispose()，甚至通过返回或引发异常退出。 using 语句仅适用于实现 IDisposable 的对象。

并注意另一个混淆点； Dispose() 是对象释放资源的一个机会，但它实际上没有释放Dispose() 后的对象。当没有对 .NET 对象的活动引用时，它们适合进行垃圾回收。从技术上讲，从 AppDomain 开始，任何对象引用链都无法访问它们。

Answer 9

C++ 中的destructor() 相当于Java 中的finalizer()。

当对象的生命周期即将结束时，它们被调用。