在最近与终结器方法搏斗之后(为了在测试期间处理连接池)，我不得不说终结器缺少很多东西。使用VisualVM来观察以及使用弱引用来跟踪实际的交互，我发现以下事情在Java 8环境中是正确的(Oracle JDK, Ubuntu 15):

Finalize is not called immediately the Finalizer (GC part) individually owns the reference elusively The default Garbage Collector pools unreachable objects Finalize is called in bulk pointing to an implementation detail that there is a certain phase the garbage collector frees the resources. Calling System.gc() often does not result in objects being finalized more often, it just results in the Finalizer getting aware of an unreachable object more rapidly Creating a thread dump almost always result in triggering the finalizer due to high heap overhead during performing the heap dump or some other internal mechanism Finalization seams to be bound by either memory requirements (free up more memory) or by the list of objects being marked for finalization growing of a certain internal limit. So if you have a lot of objects getting finalized the finalization phase will be triggered more often and earlier when compared with only a few There were circumstances a System.gc() triggered a finalize directly but only if the reference was a local and short living. This might be generation related.

最后认为

最后确定方法是不可靠的，但只能用于一件事。您可以确保在垃圾收集之前关闭或释放对象，从而在正确处理涉及生命结束操作的更复杂生命周期的对象时实现故障安全。这是我能想到的一个值得我们去推翻它的原因。

protected void finalize() throws Throwable {} every class inherits the finalize() method from java.lang.Object the method is called by the garbage collector when it determines no more references to the object exist the Object finalize method performs no actions but it may be overridden by any class normally it should be overridden to clean-up non-Java resources ie closing a file if overridding finalize() it is good programming practice to use a try-catch-finally statement and to always call super.finalize(). This is a safety measure to ensure you do not inadvertently miss closing a resource used by the objects calling class protected void finalize() throws Throwable { try { close(); // close open files } finally { super.finalize(); } } any exception thrown by finalize() during garbage collection halts the finalization but is otherwise ignored finalize() is never run more than once on any object

引用自:http://www.janeg.ca/scjp/gc/finalize.html

你也可以看看这篇文章:

对象终结和清理

Sometimes when it is destroyed, an object must make an action. For example, if an object has a non-java resource such as a file handle or a font, you can verify that these resources are released before destroying an object. To manage such situations, java offers a mechanism called "finalizing". By finalizing it, you can define specific actions that occur when an object is about to be removed from the garbage collector. To add a finalizer to a class simply define the finalize() method. Java execution time calls this method whenever it is about to delete an object of that class. Within the finalize method() you specify actions to be performed before destroying an object. The garbage collector is periodically searched for objects that no longer refer to any running state or indirectly any other object with reference. Before an asset is released, the Java runtime calls the finalize() method on the object. The finalize() method has the following general form:

protected void finalize(){
    // This is where the finalization code is entered
}

使用protected关键字，finalize()类之外的代码可以阻止对finalize()的访问。 务必要理解finalize()是在垃圾收集之前调用的。例如，当对象离开作用域时，它不会被调用。这意味着您无法知道finalize()何时或是否将执行。因此，程序必须提供其他方法来释放系统资源或对象使用的其他资源。不应该依赖finalize()来实现程序的正常运行。

在最近与终结器方法搏斗之后(为了在测试期间处理连接池)，我不得不说终结器缺少很多东西。使用VisualVM来观察以及使用弱引用来跟踪实际的交互，我发现以下事情在Java 8环境中是正确的(Oracle JDK, Ubuntu 15):

Finalize is not called immediately the Finalizer (GC part) individually owns the reference elusively The default Garbage Collector pools unreachable objects Finalize is called in bulk pointing to an implementation detail that there is a certain phase the garbage collector frees the resources. Calling System.gc() often does not result in objects being finalized more often, it just results in the Finalizer getting aware of an unreachable object more rapidly Creating a thread dump almost always result in triggering the finalizer due to high heap overhead during performing the heap dump or some other internal mechanism Finalization seams to be bound by either memory requirements (free up more memory) or by the list of objects being marked for finalization growing of a certain internal limit. So if you have a lot of objects getting finalized the finalization phase will be triggered more often and earlier when compared with only a few There were circumstances a System.gc() triggered a finalize directly but only if the reference was a local and short living. This might be generation related.

最后认为

最后确定方法是不可靠的，但只能用于一件事。您可以确保在垃圾收集之前关闭或释放对象，从而在正确处理涉及生命结束操作的更复杂生命周期的对象时实现故障安全。这是我能想到的一个值得我们去推翻它的原因。

Java allows objects to implement a method called finalize() that might get called. finalize() method gets called if the garbage collector tries to collect the object. If the garbage collector doesn't run, the method doesn't get called. If the garbage collector fails to collect the object and tries to run it again, the method doesn't get called in the second time. In practice, you are highly unlikely to use it in real projects. Just keep in mind that it might not get called and that it definitely won't be called twice. The finalize() method could run zero or one time. In the following code, finalize() method produces no output when we run it since the program exits before there is any need to run the garbage collector.

源

一般来说，最好不要依赖finalize()来做任何清理等。

根据Javadoc(值得一读)，它是:

当垃圾回收确定对象不再有引用时，由垃圾回收器在对象上调用。

正如Joachim指出的，如果对象总是可访问的，那么在程序的生命周期中，这可能永远不会发生。

此外，垃圾收集器不保证在任何特定时间运行。一般来说，我想说的是finalize()可能不是最好的方法，除非有特定的事情需要它。