Reported in security-dev@openjdk, http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017538.html
----------------------------------------
Please look at the stack traces below.

The server code accept() a SSLSocket, then calls startHandshake() in a
different thread.
The client code sends the TLS handshake bytes very slowly.
The server code waits for a bit for the handshake to finish, then
attempts to close the socket, but it cannot due to the deadlock below.
The client stops sending the TLS handshake bytes and now the server is
stuck forever.

I think invoking close() should wake up the read() with an exception,
rather than trying to grab the same lock held by the read, as
asynchronous closes from other threads happen all the times.

The issue does not happen with JDK 9, 10, 11-ea+18, but does happen
with 11-ea+21.

Thanks!

---

"main@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
  java.lang.Thread.State: BLOCKED
waiting for pool-1-thread-1@2224 to release lock on <0xac7> (a
sun.security.ssl.SSLSocketImpl)
  at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:447)

"pool-1-thread-1@2224" prio=5 tid=0x19 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
blocks main@1
  at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1)
  at java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
  at java.net.SocketInputStream.read(SocketInputStream.java:168)
  at java.net.SocketInputStream.read(SocketInputStream.java:140)
  at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464)
  at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167)
  at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
  at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877)
  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810)
  - locked <0xac7> (a sun.security.ssl.SSLSocketImpl)
  at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383)