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()方法。

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

就我个人而言，除了在一种罕见的情况下，我几乎从不使用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是我做的一个接口，让你指定你已经实现了很少实现的对象方法，如#finalize()， #hashCode()和#clone()))

因此，使用姐妹方法# setdestructivelyfinalizer(布尔值)，使用我的集合的程序可以(帮助)确保销毁对该集合的引用也会销毁对其内容的引用，并处理可能在无意中保持JVM活动的任何窗口。我也考虑过停止任何线程，但这打开了一个全新的蠕虫罐头。

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

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

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

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

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

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

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

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

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

编辑:好吧，这真的不管用。我实现了它，并认为如果它有时失败了，这对我来说是可以的，但它甚至没有调用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);
}

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

对象具有终结器(不管它执行什么代码)这一事实本身就足以导致相当大的垃圾收集开销。

摘自Brian Goetz的一篇文章:

Objects with finalizers (those that have a non-trivial finalize() method) have significant overhead compared to objects without finalizers, and should be used sparingly. Finalizeable objects are both slower to allocate and slower to collect. At allocation time, the JVM must register any finalizeable objects with the garbage collector, and (at least in the HotSpot JVM implementation) finalizeable objects must follow a slower allocation path than most other objects. Similarly, finalizeable objects are slower to collect, too. It takes at least two garbage collection cycles (in the best case) before a finalizeable object can be reclaimed, and the garbage collector has to do extra work to invoke the finalizer. The result is more time spent allocating and collecting objects and more pressure on the garbage collector, because the memory used by unreachable finalizeable objects is retained longer. Combine that with the fact that finalizers are not guaranteed to run in any predictable timeframe, or even at all, and you can see that there are relatively few situations for which finalization is the right tool to use.