Lightweight finalization for the JDK without any drawbacks was: Why is finalize wrong?

Doug Lea dl at
Thu Aug 7 11:22:59 UTC 2014

On 08/07/2014 03:43 AM, Jaroslav Tulach wrote:
> Dne Čt 7. srpna 2014 08:17:16, Andrew Haley napsal(a):
>> I'm wondering whether it's really worth your time applying band-aids to
>> a broken mechanism.
> Under the assumption WeakReference and ReferenceQueue are flawless, there is no
> reason to call a mechanism based on WeakReference and ReferenceQueue synergy
> "broken".
>> An object can be
>> "really gone" even when one of its instance methods is still executing.
> That would probably signal a major flaw in the JVM.

Finalization is not broken in the sense of not meeting its specs
but some surprising and undesirable cases are allowed,
and actually occur, in highly concurrent programs.
Including cases where finalizers may run concurrently with
the final invocation of a method on the target.
Because the specs interact with the details of the memory model,
we have been discussing (on jmm-dev list) possible changes
and  improvements. But in the mean time (or in any case), the best
practice is to consider finalization as a last resort, after
ruling out all other possible cleanup strategies.
Finalization is easy to spec, implement, and control in
purely sequential systems, but is a questionable idea in
concurrent ones.


More information about the core-libs-dev mailing list