[concurrency-interest] Stopping a java.lang.ref.Cleaner's background thread

Roger Riggs Roger.Riggs at Oracle.com
Thu Sep 7 10:50:01 EDT 2017


Hi Gene,

Right, I didn't think to mention the baseline of needing to completely 
free all objects
related to the library or subsystem.  That's a necessary step to avoid 
leaks in any unloading
scenerio and bottoms out in the classloaders and statics.

Thanks, Roger

On 9/7/2017 10:28 AM, Gil Tene wrote:
> I think David is asking about "leaking" the associated cleaner thread 
> if it was created by a servlet (e.g. as a shared static member if the 
> servlet׳s class or library), and the servlet gets unloaded. The key 
> wording for the Javadoc about this is:
>
> "...The thread runs until all registered cleaning actions have 
> completed and the cleaner itself is reclaimed by the garbage collector."
>
> So when the last strong reference from the servlet to the cleaner goes 
> away (when the servlet is unloaded), the cleaner itself will be 
> presumably be cleaned (using some other systemic cleaner), and that 
> will stop the thread and eventually collect up.
>
> Sent from my iPad
>
> On Sep 7, 2017, at 6:40 AM, Roger Riggs <Roger.Riggs at Oracle.com 
> <mailto:Roger.Riggs at Oracle.com>> wrote:
>
>> Hi David,
>>
>> It should not be necessary to do anything to the Cleaner thread.
>> The thread is set to be a daemon, so it will not inhibit a clean 
>> return from main.
>> Also, the Cleaner thread will stop itself when all of the cleaner 
>> functions have done their cleanup.
>>
>> Regards, Roger
>>
>>
>> On 9/7/2017 4:55 AM, Dávid Karnok wrote:
>>> Hello.
>>>
>>> Java 9 introduced the handy and official Cleaner infrastructure to 
>>> replace the functionality of finally(). It allows us to create the 
>>> thread it is going to use for the cleanup, which is set to daemon so 
>>> that the JVM can quit.
>>>
>>> However, when running in an "app" container such as Tomcat, I'm not 
>>> sure how to cleanup the Cleaner itself when the servlet gets 
>>> unloaded. (We had similar issues with RxJava's own set of standard 
>>> schedulers which made us expose the shutdown of the underlying 
>>> thread pools so a servlet can stop them when it gets unloaded.)
>>>
>>> I'm not sure what the effect of such shutdown should be beyond 
>>> stopping the underlying threadpool. Calling clean() on all 
>>> registered Cleanables and rejecting further register() calls? 
>>> Returning all registered Cleanables?
>>>
>>> -- 
>>> Best regards,
>>> David Karnok
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu 
>> <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170907/ff030a3f/attachment-0001.html>


More information about the Concurrency-interest mailing list