java - HttpsServer 使用 curl 导致 100% CPU 负载

Question

我围绕 Java 的 HttpsServer 创建了一个最小的应用程序.

我已经安装了一个 HttpHandler用短文本消息回复请求:

return exchange -> {
    try {
        OutputStream responseBodyStream = exchange.getResponseBody();

        byte[] response = "Trouble with HTTPS and curl\n"
                .getBytes(StandardCharsets.UTF_8);

        exchange.getResponseHeaders().set("Content-Type", "text/plain");

        exchange.sendResponseHeaders(200, response.length);

        responseBodyStream.write(response);

        responseBodyStream.close();

        // Note that exchange.close() also closes the exchange's input stream
        // and output stream

    } catch (Exception e) {
        log.warn("Could not handle request", e);
    }
};

当使用 curl 连接到服务器时，服务器有响应，但 Java 进程一直在使用整个核心，从而导致服务器无响应。

正是这一行触发了问题:

responseBodyStream.close();

如果我们删除该行，服务器将继续工作。

来自docs :

In order to correctly terminate each exchange, the output stream must be closed, even if no response body is being sent.

我创建了 a project to reproduce问题。

到目前为止我发现的一些潜在线索:

• 高 CPU 使用率仅在使用 curl 连接到服务器时出现。与 Firefox 连接时，CPU 使用率保持低水平
• 使用没有 TLS 的常规 HTTP 服务器时，curl 不会出现此问题
• 使用 Flight Recorder 收集的数据表明线程HTTP-Dispatcher中的SSLEngineImpl#writeRecord分配了很多对象

我在 Arch Linux 5.1.7 上使用 OpenJDK 12.0.1+12。 curl的版本是7.65.1。

这是 JDK 中的错误吗？还是我使用 HttpsServer 的方式不对？

Answer 1

我也可以重现这个问题。
SSLStreams.doClosure 中存在无限循环 - 这绝对是 JDK 错误。

HttpsServer 在 JDK 10 中运行良好，但在 JDK 11 中开始循环。我猜问题是 HttpsServer 实现尚未适应 JDK 11 中出现的 TLS v1.3 半关闭策略。

幸运的是，有一个解决方法。添加 -Djdk.tls.acknowledgeCloseNotify=true JVM 选项。使用此选项 HttpsServer 将按预期工作。参见 JDK-8208526了解详情。