In Java9, finalizers have been deprecated, instead cleaners have been introduced. What is the difference between the two? [closed]

Question

In Java9, finalizers have been deprecated and new concept of cleaners have been introduced. What was the specific reason for it? Is there any particular scenario or reason where cleaners should be preferred over finalizer(given that none of them are recommended).?

Marylou

Answer 1

The Deprecation of Finalizer in registers state the reason for the decision :-

Finalizers are inherently problematic and their use can lead to performance issues, deadlocks, hangs, and other problematic behavior.

Furthermore, the timing of finalization is unpredictable with no guarantee that a finalizer will be called. Classes whose instances hold non-heap resources should provide a method to enable explicit release of those resources, and they should also implement java.lang.AutoCloseable if appropriate.

The proposed solution as an alternative to using the Finalizers were the introduced Cleaners which would provide easy registration and cancellation of cleanup functions for objects.

The Cleaner and PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable.

Applications create a cleanup service for their own use and the service terminates when it is no longer in use.

Use: Once an object has become Phantom reachable the cleanup actions performed on the same are registered and managed by a Cleaner. Registering an object reference and corresponding cleaning action returns a Cleanable. The most efficient use is to explicitly invoke the clean method when the object is closed or no longer needed.

Note: Prior to Java9, a similar implementation of a Cleaner has been residing under sun.misc package as well.

Liszt

Answer 2

I recommend really trying not to use either finalizers or cleaners. Make the class AutoCloseable instead and do any cleanup in the close() method.

Cleaners are an attempt to have a finalizer like routine that is less prone to finalizer attacks. But Cleaners are very tricky to write correctly.

What is a Finalizer attack?
A Finalizer is run even when an object is not completely constructed (like if it throws an exception inside the constructor) An attacker can subclass your vulnerable class and override it's finalize method possibly bypassing security or invariant checks made inside the constructor.

So why use a cleaner.

1. Doesn't pollute the public API of the class (since the Cleaners and related objects are private)
2. Doesn't need to make an empty final finalize method even when you don't need it to prevent subclasses from overriding it as part of an attack.
3. Prevents Finalizer attacks.
4. Cleaner only runs once

EDIT: After consideration, I realized Cleaners don't prevent a finalizer attack. So even if you use a cleaner in a non-final class, please make an empty final finalize method.

Benefice

Confused with Point4. Does that mean finalizers can run more than once? – Marylou

I’m surely not going pollute my code with empty finalize() methods. Your scenario is only relevant, if 1) your code is security relevant at all, 2) you allow untrusted code to subclass your class and 3) your constructor brings the object into an exploitable state before verifying the arguments. If you are verifying the arguments before allocating resources, all the attacker’s finalize() method will see, are null references. If you reject invalid arguments before calling the super class constructor, there won’t be a finalization at all. – Aldas

@Aldas 0) The legacy code you're dealing with is guaranteed to be bug-free. :-/ Yeah, you'd have to actively go out of your way to mess up a simple constructor, and IMO a complex constructor that could hide bugs is a rank code stench to begin with, but sometimes you have to deal with the code you've been given. – Telic

@AndrewHenle in the meanwhile, the deprecation has been elevated to “for removal” So this problem will disappear automatically in the future anyway. – Aldas