OpenJDK11.0.6 HttpClient接收204响应时CLOSE_WAIT连接泄漏问题问询

We've hit a tricky socket leak issue using the java.net.http HTTP/1.1 client in OpenJDK 11.0.6. After running the application for extended periods, performance tanks dramatically—even when there's no active work, the CPU stays pinned at 100%. Digging into it, we found the root cause: a flood of sockets stuck in the CLOSE_WAIT state that aren't being cleaned up properly.

While the related OpenJDK bugs were supposed to be fixed and backported to 11.0.6, we've been able to consistently reproduce the issue in a minimal test project. The kicker? This leak only triggers when the client receives a 204 NO-CONTENT response from the server.

Minimal Reproduction Code #

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpClient.Version;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;

public class BasicFetcherApp {
    public static void main(String[] args) throws Exception {
        System.out.println("App is running... pid: " + ProcessHandle.current().pid());
        HttpClient client = HttpClient.newBuilder().version(Version.HTTP_1_1).build();
        for (int i = 0; i < 10; ++i) {
            HttpRequest request = HttpRequest.newBuilder(URI.create("http://localhost:4001/nocontent")).build();
            HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
            System.out.println(String.format("Response HTTP status: %s", response.statusCode()));
        }
        System.out.println("Finish");
        System.in.read();
    }
}

Run Output #

App is running... pid: 23306
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Finish

Socket Status Verification #

Running the ss command confirms the leaked sockets:

ss -np | grep 23306
u_str ESTAB 0 0 * 4121660 * 0 users:("java",pid=23306,fd=13)
u_str ESTAB 0 0 * 4121047 * 0 users:("java",pid=23306,fd=6)
tcp ESTAB 0 0 [::ffff:127.0.0.1]:56666 [::ffff:127.0.0.1]:40177 users:("java",pid=23306,fd=7)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58592 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=24)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58570 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=18)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58572 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=19)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58564 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=15)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58560 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=14)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58574 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=20)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58582 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=21)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58590 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=23)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58594 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=25)
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58584 [::ffff:127.0.0.1]:4001 users:("java",pid=23306,fd=22)

Notes on Reported Fixes #

Official OpenJDK bug records indicate this issue was resolved and backported to OpenJDK 11.0.6, but our reproduction clearly shows the problem persists specifically when handling 204 responses.

Temporary Workarounds #

If you're stuck on 11.0.6, here are a few quick fixes to mitigate the leak:

• Switch the client to use HTTP/2 (if your server supports it) by updating the client builder:

  HttpClient client = HttpClient.newBuilder().version(Version.HTTP_2).build();
  

• Explicitly close the response body stream (even for empty 204 responses):

  try (var ignored = response.body()) {
      // Ensures the underlying stream is closed properly
  }
  

• Upgrade to a newer minor version of OpenJDK 11 (like 11.0.7 or later), which likely includes a proper fix for this edge case.

内容的提问来源于stack exchange，提问作者Gregoire