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

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实现上工作过。我讨厌终结者。

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

它们经常被转来转去，所以不可能知道什么时候能安全地放回泳池。问题在于，它在垃圾收集过程中带来了巨大的损失，远远超过了使用对象池节省的成本。在我拆除整个池，让所有内容都变得动态并完成之前，它已经投入了大约一个月的时间。

资源(文件，套接字，流等)需要关闭一旦我们完成他们。它们通常有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，并以类似的方式使用它。在我看来，这似乎更整洁，更容易理解。

您可以将它用作持有外部资源(套接字、文件等)的对象的支持。实现close()方法和需要调用它的文档。

如果检测到close()没有执行，则实现finalize()来执行close()处理。可能会将一些东西转储到stderr，以指出您正在清理有错误的调用者。

它在异常/有bug的情况下提供了额外的安全性。并不是每个调用者每次都会执行正确的try {} finally{}。不幸的是，但在大多数环境中都是如此。

我同意很少有人需要它。正如评论者指出的那样，它带来了GC开销。只有当你在一个长期运行的应用程序中需要“皮带和背带裤”的安全性时才使用。

我看到从Java 9开始，Object.finalize()已弃用!它们将我们指向java.lang.ref.Cleaner和java.lang.ref.PhantomReference作为替代。

我在生产代码中使用finalize的唯一一次是执行一个检查，检查给定对象的资源是否已被清理，如果没有，则记录一个非常明显的消息。它实际上并没有尝试自己去做，如果做得不好，它就会大喊大叫。结果很有用。