finalize()是对JVM的一个提示，建议在未指定的时间执行代码。当您希望代码莫名其妙地无法运行时，这是很好的方法。

在终结器中做任何重要的事情(基本上除了日志)在三种情况下也很好:

您希望打赌其他已完成的对象仍然处于程序其余部分认为有效的状态。 您希望向所有具有终结器的类的所有方法添加大量检查代码，以确保它们在终结后行为正确。 您希望意外地复活已完成的对象，并花费大量时间试图弄清楚为什么它们不起作用，和/或为什么它们在最终释放时没有最终完成。

If you think you need finalize(), sometimes what you really want is a phantom reference (which in the example given could hold a hard reference to a connection used by its referand, and close it after the phantom reference has been queued). This also has the property that it may mysteriously never run, but at least it can't call methods on or resurrect finalized objects. So it's just right for situations where you don't absolutely need to close that connection cleanly, but you'd quite like to, and the clients of your class can't or won't call close themselves (which is actually fair enough - what's the point of having a garbage collector at all if you design interfaces that require a specific action be taken prior to collection? That just puts us back in the days of malloc/free.)

Other times you need the resource you think you're managing to be more robust. For example, why do you need to close that connection? It must ultimately be based on some kind of I/O provided by the system (socket, file, whatever), so why can't you rely on the system to close it for you when the lowest level of resource is gced? If the server at the other end absolutely requires you to close the connection cleanly rather than just dropping the socket, then what's going to happen when someone trips over the power cable of the machine your code is running on, or the intervening network goes out?

免责声明:我以前在JVM实现上工作过。我讨厌终结者。

公认的答案是好的，我只是想补充的是，现在有一种方法来实现finalize的功能，而不实际使用它。

看看“Reference”类。弱引用，幻影引用和软引用。

您可以使用它们来保存对所有对象的引用，但是这个引用ALONE不会停止GC。这样做的好处是，当它被删除时，你可以让它调用一个方法，并且这个方法可以保证被调用。

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

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

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

如果你在finalize中发现这样的代码，那肯定是编写它的人搞糊涂了。

如果它在其他地方，可能是代码是一个坏模型的有效补丁(一个类存在很长一段时间，由于某种原因，它引用的东西必须在对象GC之前手动释放)。一般来说，这是因为有人忘记删除监听器或其他东西，不知道为什么他们的对象没有被GC，所以他们只是删除它引用的东西，耸耸肩然后离开。

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

自1998年以来，我一直在从事Java专业工作，但我从未实现过finalize()。一次也没有。

接受的答案列出了在finalize期间关闭资源的操作。

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

所以即使在这种情况下，也不建议调用finalize。

删除已经添加到全局/静态位置(不需要)的东西，并在对象被删除时需要删除，这是很方便的。例如:

    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);
        }
    }

Be careful about what you do in a finalize(). Especially if you are using it for things like calling close() to ensure that resources are cleaned up. We ran into several situations where we had JNI libraries linked in to the running java code, and in any circumstances where we used finalize() to invoke JNI methods, we would get very bad java heap corruption. The corruption was not caused by the underlying JNI code itself, all of the memory traces were fine in the native libraries. It was just the fact that we were calling JNI methods from the finalize() at all.

这是JDK 1.5，它仍然在广泛使用。

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