为什么要实现finalize()？

Question

我阅读了很多关于 Finalize() 的 Java 新手问题，发现没有人真正明确表示 Finalize() 是一种不可靠的资源清理方法，这让我感到有点困惑。 。 我看到有人评论说他们用它来清理连接，这真的很可怕，因为接近保证连接关闭的唯一方法是最后实现 try (catch)。

我没有接受过计算机科学方面的教育，但我已经从事 Java 专业编程近十年了，而且我从未见过有人在生产系统中实现 finalize()。 这仍然并不意味着它没有用处，也不意味着与我共事的人一直在做正确的事情。

所以我的问题是，实现 Finalize() 的用例有哪些无法通过语言中的其他进程或语法更可靠地处理？

请提供具体的场景或您的经验，简单地重复Java教科书，或最终确定的预期用途是不够的，因为不是这个问题的意图。

Answer 1

接受的答案很好，我只是想补充一点，现在有一种方法可以在不实际使用它的情况下获得 Finalize 功能。

查看“参考”课程。 弱引用、幻像引用和弱引用 软参考。

您可以使用它们来保留对所有对象的引用，但仅此引用不会停止 GC。 这样做的巧妙之处在于，您可以让它在删除时调用一个方法，并且可以保证调用该方法。

至于最终确定：
我使用过一次 Finalize 来了解哪些对象被释放。 你可以用静态、引用计数等玩一些巧妙的游戏——但这只是为了分析，但要注意这样的代码（不仅仅是在 Finalize 中，但这是你最有可能看到它的地方）

public void finalize() {
  ref1 = null;
  ref2 = null;
  othercrap = null;
}

：表明某人不知道自己在做什么。 实际上从来不需要像这样的“清理”。 当类被 GC 时，这是自动完成的。

如果你在finalize中发现这样的代码，那么编写它的人肯定会感到困惑。

如果它在其他地方，则该代码可能是对错误模型的有效补丁（一个类会保留很长时间，并且由于某种原因，在对象被 GC 之前必须手动释放它引用的东西）。 一般来说，这是因为有人忘记删除侦听器或其他东西，并且无法弄清楚为什么他们的对象没有被 GC，所以他们只是删除它引用的东西，然后耸耸肩走开。

它不应该被用来“更快”地清理东西。

Answer 2

我从 1998 年开始专业从事 Java 工作，但从未实现过 finalize()。 不止一次。

Answer 3

我不确定你能对此做些什么，但是......

itsadok@laptop ~/jdk1.6.0_02/src/
$ find . -name "*.java" | xargs grep "void finalize()" | wc -l
41

所以我猜太阳发现了一些案例（他们认为）应该使用它。

Answer 4

删除已添加到全局/静态位置（不需要）并且需要在删除对象时删除的内容可以很方便。 例如：

    private void addGlobalClickListener() {
        weakAwtEventListener = new WeakAWTEventListener(this);

        Toolkit.getDefaultToolkit().addAWTEventListener(weakAwtEventListener, AWTEvent.MOUSE_EVENT_MASK);
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();

        if(weakAwtEventListener != null) {
            Toolkit.getDefaultToolkit().removeAWTEventListener(weakAwtEventListener);
        }
    }

Answer 5

嗯，我曾经用它来清理没有返回到现有池的对象。

它们被多次传递，因此无法判断它们何时可以安全返回泳池。 问题在于，它在垃圾收集期间带来了巨大的损失，远远大于通过对象池节省的任何费用。 它已经制作了大约一个月，然后我拆掉了整个池，使一切变得动态并完成了。

Answer 6

当编写供其他开发人员使用的代码时，需要调用某种“清理”方法来释放资源。 有时，其他开发人员忘记调用您的清理（或关闭、销毁或其他）方法。 为了避免可能的资源泄漏，您可以检查 Finalize 方法以确保该方法被调用，如果没有被调用，您可以自己调用它。

许多数据库驱动程序在其 Statement 和 Connection 实现中执行此操作，以便为忘记调用 close 的开发人员提供一点安全性。

Answer 7

编辑：好吧，这确实行不通。 我实现了它，并认为如果它有时失败对我来说没关系，但它甚至没有调用一次 Finalize 方法。

我不是专业程序员，但在我的程序中，我认为这是使用 Finalize() 的一个很好的例子，即一个缓存，它在销毁之前将其内容写入磁盘。 因为没有必要每次销毁时都执行它，它只会加速我的程序，我希望我没有做错。

@Override
public void finalize()
{
    try {saveCache();} catch (Exception e)  {e.printStackTrace();}
}

public void saveCache() throws FileNotFoundException, IOException
{
    ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("temp/cache.tmp"));
    out.writeObject(cache);
}

Answer 8

请小心您在 finalize() 中所做的事情。 特别是如果您将它用于调用 close() 等操作以确保资源得到清理。 我们遇到过几种情况，将 JNI 库链接到正在运行的 Java 代码，并且在任何使用 Finalize() 调用 JNI 方法的情况下，我们都会遇到非常严重的 Java 堆损坏。 损坏不是由底层 JNI 代码本身引起的，本机库中的所有内存跟踪都很好。 事实上，我们根本就是从 Finalize() 调用 JNI 方法。

这是在 JDK 1.5 中进行的，该版本仍在广泛使用。

直到很久以后我们才发现出了问题，但最终罪魁祸首始终是使用 JNI 调用的 Finalize() 方法。

Answer 9

finalize() 对于捕获资源泄漏很有用。 如果资源应该关闭但没有将其未关闭的事实写入日志文件并关闭它。 这样您就可以消除资源泄漏，并让自己知道它已经发生，以便您可以修复它。

我从 1.0 alpha 3 (1995) 就开始用 Java 编程，但我还没有重写任何东西的 Finalize...

Answer 10

您不应该依赖 Finalize() 来清理您的资源。 Finalize() 在类被垃圾回收之前不会运行（如果那时）。 当您使用完资源后，最好显式释放它们。

Answer 11

强调上面答案中的一点：终结器将在单独的 GC 线程上执行。 我听说过一个主要的 Sun 演示，开发人员在一些终结器中添加了一个小睡眠，并故意使原本精美的 3D 演示崩溃。

最好避免，但测试环境诊断可能除外。

Eckel 的《Java 思维》中有关于此的很好的章节。

Answer 12

class MyObject {
    Test main;

    public MyObject(Test t) {    
        main = t; 
    }

    protected void finalize() {
        main.ref = this; // let instance become reachable again
        System.out.println("This is finalize"); //test finalize run only once
    }
}

class Test {
    MyObject ref;

    public static void main(String[] args) {
        Test test = new Test();
        test.ref = new MyObject(test);
        test.ref = null; //MyObject become unreachable，finalize will be invoked
        System.gc(); 
        if (test.ref != null) System.out.println("MyObject still alive!");  
    }
}

====================================

结果：

This is finalize

MyObject still alive!

============ =========================

因此，您可以在 Finalize 方法中使无法访问的实例变得可访问。

Answer 13

接受的答案列出了可以在最终确定期间关闭资源。

然而 这个答案表明，至少在使用 JIT 编译器的 java8 中，您会遇到意想不到的问题，有时甚至会调用终结器在完成从对象维护的流中读取数据之前。

因此，即使在这种情况下，也不建议调用 Finalize。

Answer 14

一旦我们使用完资源（文件、套接字、流等），就需要关闭它们。 它们通常有 close() 方法，我们通常在 try-catch 语句的 finally 部分调用该方法。 有时，少数开发人员也可以使用 Finalize() ，但在我看来，这不是一个合适的方法，因为不能保证 Finalize 总是被调用。

在 Java 7 中，我们有 try-with-resources 语句可以这样使用：

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
  // Processing and other logic here.
} catch (Exception e) {
  // log exception
} finally {
  // Just in case we need to do some stuff here.
}

在上面的示例中，try-with-resource 将通过调用 close() 方法自动关闭资源 BufferedReader。 如果我们愿意，我们还可以实现 Closeable在我们自己的课程中并以类似的方式使用它。 IMO 看起来更简洁、更容易理解。

Answer 15

作为旁注：

覆盖 Finalize() 的对象会被垃圾收集器特殊对待。 通常，当对象不再处于范围内时，该对象会在收集周期中立即销毁。 然而，可终结的对象会被移动到队列中，其中单独的终结线程将排空队列并在每个对象上运行 Finalize() 方法。 一旦finalize()方法终止，该对象最终将为下一个周期的垃圾回收做好准备。

来源：finalize() 在 java-9 上已弃用

Answer 16

iirc - 您可以使用 Finalize 方法作为实现昂贵资源池机制的一种手段 - 这样它们也不会得到 GC。

Answer 17

就我个人而言，我几乎从未使用过 Finalize() ，除非在一种罕见的情况下：我制作了一个自定义泛型类型集合，并编写了一个自定义的 Finalize() 方法来执行以下操作：以下：

public void finalize() throws Throwable {
    super.finalize();
    if (destructiveFinalize) {
        T item;
        for (int i = 0, l = length(); i < l; i++) {
            item = get(i);
            if (item == null) {
                continue;
            }
            if (item instanceof Window) {
                ((Window) get(i)).dispose();
            }
            if (item instanceof CompleteObject) {
                ((CompleteObject) get(i)).finalize();
            }
            set(i, null);
        }
    }
}

^{（CompleteObject 是我制作的一个接口，可让您指定已实现很少实现的 Object 方法，例如 #finalize()、#hashCode() 和 #clone())}

因此，使用姐妹 #setDestructivelyFinalizes(boolean) 方法，使用我的集合的程序可以（帮助）保证销毁对此集合的引用也会销毁对其内容的引用，并处置任何可能无意中使 JVM 保持活动状态的窗口。 我也考虑停止任何线程，但这引发了一个全新的蠕虫问题。

Answer 18

您可以将其用作持有外部资源（套接字、文件等）的对象的后盾。 实现一个 close() 方法并记录需要调用的方法。

如果您检测到尚未完成，请实现 finalize() 来执行 close() 处理。 也许将一些东西转储到 stderr 来指出您正在清理有问题的调用者。

它在特殊/有缺陷的情况下提供额外的安全性。 并非每个调用者每次都会执行正确的 try {} finally {} 操作。 不幸的是，但在大多数环境下都是如此。

我同意很少需要它。 正如评论者所指出的，它会带来 GC 开销。 仅当您在长时间运行的应用程序中需要“腰带和吊带”安全时才使用。

我看到从 Java 9 开始， < code>Object.finalize() 已弃用！ 他们向我们指出 java.lang。 ref.Cleaner 和 java.lang.ref.PhantomReference 作为替代方案。

Answer 19

finalize() 是对 JVM 的一个提示，表明在未指定的时间执行代码可能会更好。 当您希望代码神秘地无法运行时，这非常有用。

在终结器中做任何重要的事情（基本上除了日志记录之外的任何事情）在三种情况下也很好：

• 你想赌其他终结对象仍将处于程序其余部分认为有效的状态。
• 您想要向所有具有终结器的类的所有方法添加大量检查代码，以确保它们在终结后行为正确。
• 您想要意外地复活最终确定的对象，并花费大量时间试图找出它们不起作用的原因，和/或为什么它们在最终发布时没有最终确定。

如果您认为需要 Finalize()，有时您真正想要的是幻像引用（在给出的示例中，它可以保存对其引用对象使用的连接的硬引用，并在幻像之后关闭它）参考已排队）。 这还有一个属性，它可能神秘地永远不会运行，但至少它不能调用或复活最终对象的方法。 因此，它非常适合以下情况：您绝对不需要完全关闭该连接，但您很想这样做，并且您的班级的客户不能或不会自己调用关闭（这实际上是足够公平的 -如果您设计的接口需要在收集之前采取特定操作，那么拥有垃圾收集器有什么意义呢？这只会让我们回到 malloc/free 的时代。）

其他时候您需要您认为您正在设法变得更加强大的资源。 例如，为什么需要关闭该连接？ 它最终必须基于系统提供的某种I/O（套接字、文件，等等），那么为什么不能在最低级别的资源被 gced 时依赖系统为您关闭它呢？ 如果另一端的服务器绝对要求您彻底关闭连接而不是仅仅断开套接字，那么当有人被运行代码的机器的电源线绊倒或中间网络中断时会发生什么？

免责声明：我过去曾参与过 JVM 实现。 我讨厌终结器。

Answer 20

一个简单的规则：永远不要使用终结器。

仅对象具有终结器这一事实（无论它执行什么代码）就足以导致垃圾收集的相当大的开销。

来自 Brian Goetz 的文章：

带有终结器的对象（那些
有一个不平凡的 Finalize() 方法）
与相比有显着的开销
没有终结器的对象，并且应该
谨慎使用。 可最终确定的
对象的分配速度都较慢
并且收集速度较慢。 分配时
时间，JVM必须注册任何
带有垃圾的可终结对象
收集器，并且（至少在
HotSpot JVM 实现）
可终结的对象必须遵循
分配路径比大多数其他路径慢
对象。 同样，可最终确定
收集物体的速度也较慢。 它
至少需要两次垃圾收集
之前的周期（在最好的情况下）
可终结的对象可以被回收，
垃圾收集器必须做的
调用终结器的额外工作。
结果花费的时间更多
分配和收集对象以及
垃圾处理压力更大
收集器，因为使用的内存
无法到达的可终结对象是
保留时间更长。 将其与
事实上终结器不是
保证在任何可预测的情况下运行
时间范围，甚至根本没有，你可以
看到数量比较少
最终确定的情况
使用正确的工具。

Answer 21

我在生产代码中使用 Finalize 的唯一一次是检查给定对象的资源是否已清理，如果没有，则记录一条非常明确的消息。 它实际上并没有尝试自己做这件事，只是如果做得不好它就会大喊大叫。 事实证明非常有用。