ThreadPoolExecutor and finalization

[David Holmes]

On 31/10/2017 5:36 PM, Peter Levart wrote:
> On 10/31/17 05:12, David Holmes wrote:
>> On 31/10/2017 1:02 AM, David Lloyd wrote:
>>> On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> 
>>> wrote:
>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>> resources it
>>>> has allocated (threads) and it should be free to use whatever 
>>>> mechanism is appropriate.
>>>
>>> I wonder though whether TPE.finalize() is ever actually hit in
>>> practice: TPE is (by definition) a thread pool, and every live thread
>>> in that pool has (by way of TPE.Worker) a strong reference to the TPE
>>> itself via an outer class reference which is passed around in enough
>>> places to make me think that it would never actually be collectable in
>>> a real-world situation, unless all core threads were allowed to time
>>> out.
>>
>> The docs for TPE cover this in detail: [1]
>>
>> Finalization
>>     A pool that is no longer referenced in a program AND has no 
>> remaining threads will be shutdown automatically. If you would like to 
>> ensure that unreferenced pools are reclaimed even if users forget to 
>> call shutdown(), then you must arrange that unused threads eventually 
>> die, by setting appropriate keep-alive times, using a lower bound of 
>> zero core threads and/or setting allowCoreThreadTimeOut(boolean).
> 
> I'm trying to understand the purpose of finalize() in TPE, but can't. 
> I'm surely missing something. If the pool is no longer referenced AND 
> there are no active threads, what is there left to shutdown() actually? 
> All that remains is garbage that will eventually be GCed.

Ummmmm .... I'm going to have to do some archaeology here ...

David

> Regards, Peter
> 
>>
>> David
>> -----
>>
>> [1] 
>> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html
>>
>