High contention on provider.getService() with large number of TLS connections

ADDITIONAL SYSTEM INFORMATION :
Linux mailarchiva-usa-h 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
All methods in Provider.getService() are synchronized. This causes significant contention. On systems that are performing a large number of TLS connections, Provider.getService() can take up to 32 seconds to complete.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This issue happens in systems with large amount of TLS connections. See: https://i.stack.imgur.com/KVM79.jpg for a demo of the same.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We do not expect to see contention in the Provider.getService class.
ACTUAL -
You can see that monitors are blocked for a long period of time.
Java Monitor Blocked
 at java.security.Provider.getService(String, String)
 at sun.security.jca.ProviderList$ServiceList.tryGet(int)
 at sun.security.jca.ProviderList$ServiceList.access$200(ProviderList$ServiceList, int)
 at sun.security.jca.ProviderList$ServiceList$1.hasNext()
 at javax.crypto.KeyGenerator.nextSpi(KeyGeneratorSpi, boolean)
 at javax.crypto.KeyGenerator.<init>(String)
 at javax.crypto.KeyGenerator.getInstance(String)
 at sun.security.ssl.JsseJce.getKeyGenerator(String)
 at sun.security.ssl.HandshakeMessage$Finished.getFinished(HandshakeHash, int, SecretKey)
 at sun.security.ssl.HandshakeMessage$Finished.<init>(ProtocolVersion, HandshakeHash, int, SecretKey, CipherSuite)
 at sun.security.ssl.ServerHandshaker.sendChangeCipherAndFinish(boolean)
 at sun.security.ssl.ServerHandshaker.clientHello(HandshakeMessage$ClientHello)
 at sun.security.ssl.ServerHandshaker.processMessage(byte, int)
 at sun.security.ssl.Handshaker.processLoop()
 at sun.security.ssl.Handshaker.process_record(InputRecord, boolean)
 at sun.security.ssl.SSLSocketImpl.readRecord(InputRecord, boolean)
 at sun.security.ssl.SSLSocketImpl.performInitialHandshake()
 at sun.security.ssl.SSLSocketImpl.startHandshake(boolean)
 at sun.security.ssl.SSLSocketImpl.startHandshake()
 at org.subethamail.smtp.command.StartTLSCommand.execute(String, Session)
 at org.subethamail.smtp.server.CommandHandler.handleCommand(Session, String)
 at org.subethamail.smtp.server.Session.runCommandLoop()
 at org.subethamail.smtp.server.Session.run()
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run()
 at java.lang.Thread.run()

CUSTOMER SUBMITTED WORKAROUND :
There is no workaround. This is a critical performance issue in the Java libraries. The Java Provider class needs to be refactored with modern concurrent programming principles. Several bugs have been raised in the past regarding this issue, and each time it gets ignored by Oracle.

FREQUENCY : always