Question

According to this post, in .Net,

Finalizers are actually even worse than that. Besides that they run late (which is indeed a serious problem for many kinds of resources), they are also less powerful because they can only perform a subset of the operations allowed in a destructor (e.g., a finalizer cannot reliably use other objects, whereas a destructor can), and even when writing in that subset finalizers are extremely difficult to write correctly. And collecting finalizable objects is expensive: Each finalizable object, and the potentially huge graph of objects reachable from it, is promoted to the next GC generation, which makes it more expensive to collect by some large multiple.

Does this also apply to JVMs in general and to HotSpot in particular?

Answer 1

Here are some select quotes from Effective Java 2nd Edition: Item 7: Avoid finalizers:

Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems. Finalizers have few valid uses, […] as a rule of thumb, you should avoid finalizers.

You should really make sure that in fact, you DO need finalizers; most of the time you DON’T.

C++ programmers are cautioned not to think of finalizers as Java’s analog of C++ destructors. In C++, destructors are the normal way to reclaim the resources associated with an object, a necessary counterpart to constructors. In Java, the garbage collector reclaims the storage associated with an object when it becomes unreachable, requiring no special effort on the part of the programmer. C++ destructors are also used to reclaim other nonmemory resources. In Java, the try-finally block is generally used for this purpose.

The semantics of when finalizers are invoked is also important to consider:

JLS 12.6 Finalization of Class Instances

The Java programming language does not specify how soon a finalizer will be invoked […nor] which thread will invoke the finalizer for any given object. […] If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates. (JLS 12.6.2) Finalizer Invocations are Not Ordered

Moreover, the only mechanism to run finalizer on demand is broken. The following quotes are from Effective Java 2nd Edition:

[…] The only methods that claim to guarantee finalization are System.runFinalizersOnExit and its evil twin, Runtime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.

Bloch went further to comment on the performance penalty (emphasis his):

Oh, and there’s one more thing: there is a severe performance penalty for using finalizers. On my machine, the time to create and destroy a simple object is about 5.6ns. Adding a finalizer increases the time to 2,400ns. In other words, it is about 430 times slower to create and destroy objects with finalizers.

With such little details on the benchmarking methodology, I don’t think the specific numbers mean much, but it does confirm what have been widely documented: finalizers are very costly.

The book does explain the rare scenarios under which using finalizers is valid. The omission of those quotes from this answer is intentional.