ThreadPoolExecutor and finalization

Peter Levart peter.levart at
Tue Oct 31 07:36:45 UTC 2017


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> 
>> 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.

Regards, Peter

> David
> -----
> [1] 

More information about the core-libs-dev mailing list