ThreadPoolExecutor and finalization

Roger Riggs Roger.Riggs at
Tue Oct 31 13:43:19 UTC 2017

Hi David,

On 10/31/2017 12:37 AM, David Holmes wrote:
> Hi Roger,
> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>> Hi David,
>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>> Hi Andrej,
>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>> Hi David,
>>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at> 
>>>>> wrote:
>>>>> Hi Roger,
>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>> Hi,
>>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>>> uses too see if they can be removed or mitigated.
>>>>> So the nice thing about finalize was that it followed a 
>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>>> support such usages?
>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>> ThreadPoolExecutor.terminated.
>>> True. Though overriding shutdown() would be the semantic equivalent 
>>> of overriding finalize(). :)
>>> In the general case though finalize() might be invoking a final method.
>>> Anyway I'm not sure we can actually do something to try to move away 
>>> from use of finalize() in TPE. finalize() is only deprecated - it is 
>>> still expected to work as it has always done. Existing subclasses 
>>> that override finalize() must continue to work until some point 
>>> where we say finalize() is not only deprecated but obsoleted (it no 
>>> longer does anything). So until then is there actually any point in 
>>> doing anything? Does having a Cleaner and a finalize() method make 
>>> sense? Does it aid in the transition?
>> As you observe, the alternatives directly using PhantomRefs or the 
>> Cleanup do not provide
>> as nice a model.  Unfortunately, that model has been recognized to 
>> have a number of
>> issues [1].  Finalization is a poor substitute for explicit shutdown, 
>> it is unpredictable and unreliable,
>> and not guaranteed to be executed.
> I'm not trying to support/defend finalize(). But it does support the 
> very common OO pattern of "override to specialize then call super".
>> ThreadPoolExecutor has a responsibility to cleanup any native 
>> resources it has allocated (threads)
>> and it should be free to use whatever mechanism is appropriate. 
>> Currently, the spec for finalize
>> does not give it that freedom.
> I suppose in hindsight we (JSR-166 EG) could have described automatic 
> shutdown without mentioning the word "finalize", but that ship has 
> sailed. We did specify it and people can expect it to be usable and 
> they can expect it to work. While encouraging people to move away from 
> finalization is a good thing you have to give them a workable 
> replacement.
>> The initiative is to identify and remediate existing uses of 
>> finalization in the JDK.
>> The primary concern is about subclasses that reply on the current spec.
>> If I'm using grepcode correctly[2], it does not show any subclasses 
>> of ThreadPoolExecutor that
>> override finalize; so it may be a non-issue.
> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
> indicator of whether there are subclasses of TPE that override 
> finalize. Only a small fraction of source code is in the open.
Not cited as authoritative, just one data point.
> And I have to agree with Martin that the current documentation for 
> finalize() in TPE is somewhat inappropriate. If you deprecate 
> something you're supposed to point the user to the preferred way of 
> doing something other than the deprecated method - but there is none. 
> finalize() in TPE should not have been deprecated until we provided 
> that alternative.
In all the years of hand wringing over finalize no perfect replacement 
has been discovered.
Deprecating and providing some advice, though not perfect for every 
situation is a way
to get people thinking about alternatives that work in various cases.
> I think the way forward here would be to:
> 1. Change TPE.finalize() to final to force any subclasses to migrate 
> to the new mechanism going forward.
> 2. Implement the new mechanism - presumably Cleaner - and document how 
> to achieve the effect of "override to specialize then call super" 
> (presumably by overriding shutdown() instead).
> then in a few releases we remove TPE.finalize() (at the same time as 
> we remove it from Object).
The first step is to deal with our own uses with in the JDK and try out 
some workable alternatives
without breaking everything all at once.  It is expected to take a while 
to mitigate all the uses.
In the meantime, reducing the uses and overhead due to finalization 
gives a performance benefit.


> Cheers,
> David
>> Regards, Roger
>> [1]
>> [2] 

More information about the core-libs-dev mailing list