Why is finalize wrong?
David M. Lloyd
david.lloyd at redhat.com
Mon Aug 4 13:50:22 UTC 2014
On 08/04/2014 08:46 AM, Jaroslav Tulach wrote:
> Last week we touched topic of finalization and what is wrong with it. I proposed three
> reasons why Object.finalize is bad. Is it correct and extensive list or would you change
> it or expand it? Thanks as ...
>>> # 1 - Because of automatic JDK management thread?
>>> # 2 - Or because once finalize() is called, one still has reference to the
>>> "gone" object and can re-activate it?
>>> #3 - Or because the finalizer thread is shared between completely
>>> objects and misbehavior of one can cause problems for others?
> ...I consider #2 the worst idea:
>>> My personal top three starts with #2. That is logically invalid. #3 can be
>>> a problem, but so can be any other misbehaving thread in an application.
>>> #1 is completely OK, from my perspective
> and I think I got some support...
>> Weak references and reference queues were introduced to address some of
>> the short comings of finalization as well as providing other
>> capabilities within a GC'd environment.
> ...I just have to say that the Reference&ReferenceQueue as of JDK8 is not enough. As
> the case of activeReferenceQueue shows, the fact that each instance of
> ReferenceQueue where one uses remove() needs one dedicated thread is a big flaw.
> Fixing the flaw in an external library is not easy (see the summary from last week:
> Moreover David Holmes finds introductions of new system level threads uneasy:
>> The threading aspect is somewhat tangential. Any time you choose to
>> introduce a new thread to perform a task you have to be concerned about
>> the lifetime of the task and thus the thread.
> But when thinking about it, we can have functionality of activeReferenceQueue in JDK
> without introducing any new thread! We can reuse the existing finalizer one!
> I plan to propose a patch which will look at the activeReferenceQueue problem from a
> completely new perspective and offer "lightweight finalize" solution that will have
> above discussed properties #1 and #3, but will not suffer from #2 (the biggest
> problem with Object.finalize).
> I just wanted to ask before I start: Is somebody aware of other problems with
> Object.finalize than #1, #2 and #3?
Yup. Did you know that an object can be finalized while there are still
instance methods of that object executing? We've actually seen it
happen. Just take a few minutes to think about what that means! Almost
every remaining use case for finalize is made unsafe and/or useless by
If you still think that finalize is a good idea, given that it's
basically defective *and* there is almost always a better solution, then
I will be quite astounded I think.
More information about the core-libs-dev