Under load, a call to ServerSocketChannel.accept() can return an identical SocketChannel (same protocol, client IP/port and server IP/port) to the SocketChannel returned from the previous accept() call. This should not be possible.

A test case is available at:
https://github.com/markt-asf/duplicate-socket

The steps to reproduce are:
- Start the NetworkTest java application
- From separate console windows, run at least two instance of the following: `for i in {1..50}; do /opt/wrk/wrk -t 2 -c 1000 -d 5s --latency --timeout 1s --script ./myPost.lua http://localhost:8080/post; done`

Adjust path to wrk as appropriate.

There does appear to be a timing element to this test and running more instances of the above wrk loop in additional console windows may increase the likelihood of triggering the error.

Sample output is attached.

openjdk-17-console.txt shows that two SocketChannel instances were returned and both were for the same protocol, client IP/port and server IP/port combination. The client port is 33314

openjdk-17.pcapng shows the wireshark capture of all traffic to server port 8080 during the test. Filtering for "tcp.port=33314" shows only a single network connection from that client port to the server.

openjdk-17.hprof is the heap dump generated as soon as the error was detected. It shows two SocketChannel instances (NetworkTest.currentConnection and NetworkTest.previousConnection) both with client port 33314 as expected from the console output. An examination of the heap dump shows the SocketChannel instance have sequential file descriptors. Otherwise both appear to be identical. Both SocketChannels are valid and open.

I have been able to recreate this with the latest:
- OpenJDK Java 17 EA build
- Adopt OpenJDK Java 15 release
- Adopt OpenJDK Java 11 release
- Adopt OpenJDK Java 8 release

This issue was originally observed as part of the investigation into this Spring WebFlux / Apache Tomcat issue:
https://github.com/spring-projects/spring-framework/issues/26434