Consider making TerminatingThreadLocal public

Norman Maurer norman.maurer at
Tue Jul 10 10:06:57 UTC 2018

Hi all,

It came to my attention that you introduced TerminatingThreadLocal in openjdk lately as an “internal class”: <>

I would like to take the chance to ask if you ever considered to make this “non-internal” as I think it would super helpful for some use cases.  To give you some more context let me give you an example of why we would love it in netty.

So in netty we sometimes pool “direct memory” in ThreadLocals [1]  and have to do some tricks to ensure this direct memory is really released once a Thread exit. Which I think is also exactly one use-case you have here. Sure we can do this with a WeakReference + ReferenceQueue , Cleaner or finalizer but I feel exposing TerminatingThreadLocal would be a lot more elegant. Another advantage would be that we can be sure that the cleanup action would be called in the Thread that holds the value of the ThreadLocal, which is not really possible with using WeakReference + ReferenceQueue , Cleaner or finalizer.

What we currently doing in netty is basically have our own ThreadLocal [1] implementation and out own Thread sub-class [2] that will ensure we call some method on our TheadLocal that gives us the chance to do the cleanup by wrapping the Runnable[3] that is passed in. This works great but we can not always guarantee that our sub-class of Thread is used to access our ThreadLocal implementation, which means the cleanup action will not run in this case.


[1] <>
[2] <>
[3] <>

More information about the core-libs-dev mailing list