Promptly freeing the per-thread cached direct buffers when a thread exits

Tony Printezis tprintezis at
Fri Apr 6 14:08:12 UTC 2018

Hi Alan,

Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is
why I proposed some type of exit hook (maybe I overthought this?). But
that’d be OK, could make this change a lot simpler. :-) And, yes, I came
across the issue of not being able to query whether a ThreadLocal exists on
a Thread when I implemented my prototype. Which is why I think introducing
an exit hook on ThreadLocal, instead of Thread, is probably the better
approach (it will only be called if the ThreadLocal exists).


Tony Printezis | @TonyPrintezis | tprintezis at

On April 6, 2018 at 4:02:56 AM, Alan Bateman (alan.bateman at

On 05/04/2018 22:45, Tony Printezis wrote:
> Hi all,
> We recently hit another interesting issue with the NIO thread-local
> DirectByteBuffer cache. One of our services seems to create and drop
> threads at regular intervals. I assume this is due to a thread pool
> dynamically resizing itself.
> Let's say a thread starts, lives long enough for its Thread object to be
> promoted to the old gen (along with its cached direct buffer), then
> This will result in its cached direct buffer(s) being unreachable in the
> old gen and will only be reclaimed after the next full GC / concurrent GC
> cycle.
Right, if a short lived thread does I/O with a buffer backed by an array
in the heap then any direct buffers in its thread local cache won't be
freed until there is a GC and reference processing. It's something that
I've prototyped a few times and always leaned towards not exposing
anything in the API, instead just hooking into the thread exit to clear
the buffer cache. One thing to watch out for is that the buffer cache
may not exist (as the thread didn't do any I/O with heap buffers) so
you'll end up creating (an empty) buffer cache at thread exit. That is
benign of course but still unsettling to have additional code executing
at this time.


More information about the core-libs-dev mailing list