java.lang.ref.Finalizer locks

Milan Mimica Milan.Mimica at
Mon Mar 20 14:21:19 UTC 2017

Hello Peter

I created them a task:

You don't suppose it would be worth trying to play with RegisterFinalizersAtInit? Maybe
it could help for some reason if the registration was moved a bit earlier.

Milan Mimica, Senior Software Engineer / Division Lead
From: Peter Levart <peter.levart at>
Sent: Monday, March 20, 2017 14:37
To: Milan Mimica; core-libs-dev at
Subject: Re: java.lang.ref.Finalizer locks

Hi Milan,

On 03/20/2017 02:13 PM, Milan Mimica wrote:
> Hello
> Hope you can help me with an advice.
> I'm using a library, namely spring-jdbc, which implements java.lang.Object.finalize() in one static inner class which does get instantiated *a lot*. It creates significant contention on synchronized block in java.lang.ref.Finalizer from Object's constructor. Are there any plans to improve this (except from removing it)? I can see it's not trivial, but maybe it could be reimplemented lock-free?

There were past attempts in this area (using concurrent doubly linked
list similar to the one in java.util.concurrent.ConcurrentLinkedDeque)
that did improve the contention a bit. Another drag is also the fact
that the Finalizer.register() method that must be invoked from VM as
part of object construction prevents certain optimizations in VM that
non-finalizable object constructors enjoy.

So the most productive way would be to ask Spring developers to remove
finalization and instead employ their own PhantomReference based cleanup
and/or adopt new JDK 9 Cleaner API when time comes...

Regards, Peter

More information about the core-libs-dev mailing list