Apparently there is a deadlock happening in JRE 9 which does not appear to happen in JRE 8u66. Hence I assume this to be a new bug introduced by JRE 9. The bug is happening sporadically, and apparently it looks like it happens more often on Windows 7 (64 Bit) and less often on Windows 8 (64 Bit) according to several weeks of manual testing. As the bug only happens sporadically, no automatic test is possible for this.

Steps to reproduce:
* Open SSLSocket.
* Several threads write into the socket.
* Keep the application running
* Put Windows in hibernation mode
* Wait for about 24 hours
* Resume Windows from hibernation mode
* Thread A tries to write into the socket
* Thread B tries to close the socket

Expected behaviour:
* Thread A will throw an exception as the TCP connection is broken due to timeout while the PC was hibernated
* Thread B will succeed as it shouldn't be a problem to explicitly close a socket which is invalid due to the OS's timeout.

Actual behaviour:
* A deadlock accurs between thread A and thread B.
* See attached stack trace / deadlock report

Note: A real-world application was used for about one month in daily field use, both on JRE 8u66 and JRE 9-ea on several PCs. The problem never happened on JRE 8u66. The problem ALWAYS happened on JRE 9-ea (Windows 7). The problem OFTEN happened on JRE 9-ea (Windows 8).

I assume a race condition and / or mixed sequence of locks: One lock might be set by the OS, another lock by the JRE. Depending on the champion of the race, there might be a deadlock between .close() and .write(), or not.