ADDITIONAL SYSTEM INFORMATION :
openjdk version "11.0.14.1"

A DESCRIPTION OF THE PROBLEM :
Hello, I am seeing heavy lock contention in PhantomCleanable when files are opened and closed under high concurrency. Please see sample stack trace below:

jdk.internal.ref.CleanerImpl$PhantomCleanableRef
jdk.internal.ref.PhantomCleanable.insert
jdk.internal.ref.PhantomCleanable.<init>
java.io.FileCleanable.<init>
java.io.FileCleanable.register
java.io.RandomAccessFile.<init>

Another stack trace example showing the close path is below:
jdk.internal.ref.CleanerImpl$PhantomCleanableRef
jdk.internal.ref.PhantomCleanable.remove
jdk.internal.ref.PhantomCleanable.clear
java.io.FileDescriptor.unregisterCleanup
java.io.FileDescriptor.close
java.io.RandomAccessFile$1.close
java.io.FileDescriptor.closeAll
java.io.RandomAccessFile.close

Would it be possible to update the implementation so it can have higher throughput by not relying on an exclusive lock in PhantomCleanable.insert() and PhantomCleanable.remove()? For example, perhaps a concurrent data structure could be used. If that is not an option, would it be possible to have a system property option that determines whether or not the FileDescriptor is registered and unregistered with the Cleaner? It would then be the burden of the caller to ensure the File is closed, otherwise leaks can occur. However, this tradeoff might be acceptable to reduce the lock contention.

Thanks!

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open, write, close and read RandomAccessFile (similar with FileChannel as well) under high concurrency and observe the performance impact with a profiler.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Minimal lock contention
ACTUAL -
Heavy lock contention