RFR: 8278270: ServerSocket is not thread safe

Florian Weimer fweimer at openjdk.java.net
Mon Dec 6 13:42:17 UTC 2021


On Sun, 5 Dec 2021 16:44:05 GMT, Alan Bateman <alanb 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.

To what extent is `ServerSocket` required to be thread-safe? I don't think it's part of the specification.

This question applies to the other socket classes as well. For example, there is quite a bit of code in `SSLSocket` to make it thread-safe, but that does not seem to be required by the specification, either.

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

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


More information about the net-dev mailing list