In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord).

                socketLock.lock();
                try {
                    plainText = decode(buffer);
                } finally {
                    socketLock.unlock();
                }

If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode()) could be blocked if socket level locks are used.

This is not an easy to reproduce bug because readApplicationRecord() will try to read the TLS header at first, and then lock the socket. Normally, a TLS record could be delivered in one package, and thus the socket level lock in readApplicationRecord() does not block. But if the TLS record is delivered in multiple packages, the socket level lock may take a while and thus could block other APIs.

The decode() method is used in two places. One for the initial handshaking, and one for application data reading. The application data reading does not start before the initial handshaking completed. So it is not necessary to have a lock to synchronize the initial handshaking and application data reading.