RFR: 8278270: ServerSocket is not thread safe

[Alan Bateman]

On Mon, 6 Dec 2021 11:28:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are several thread safety issues in java.net.ServerSocket, issues that go back to at least JDK 1.4.
>> 
>> The issue of most concern is async close of a ServerSocket that is initially created unbound and where close may be called at or around the time the underlying SocketImpl is created or the socket is bound.
>> 
>> The summary of the changes are:
>> 
>> 1. The "impl" field is changed to be final field.
>> 2. The closeLock is renamed to stateLock and is required to change the (now volatile) created, bound or closed fields.
>> 3. The needless synchronization has been removed from xxxSoTimeout and xxxReceiveBufferSize.
>> 
>> There are many redundant checks for isClosed() and other state that could be removed. Removing them would subtle change the exception thrown when there are two or more failure conditions. So they are left as is.
>
> src/java.base/share/classes/java/net/ServerSocket.java line 712:
> 
>> 710:      */
>> 711:     public void close() throws IOException {
>> 712:         synchronized (stateLock) {
> 
> Maybe makes some sense to check `closed` outside the lock here? Looks like we don't need to re-acquire the lock for repeated `close()` calls.

That would be okay too although I wouldn't expect it is very common to attempt to close a ServerSocket more than once (the only scenario that comes to mind is where there is an async close which triggers a shutdown to server and the shutdown invokes close too).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6712