面经策

Java 11 的标准 HttpClient 相比 HttpURLConnection 有什么改进？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

Java 11 标准 HttpClient（替代 HttpURLConnection）的改进，按业务痛点讲：

  1. HTTP/2 原生支持：多路复用（一个连接跑多个并发请求）、头部压缩——高并发调用下游服务的连接数与延迟双降；HttpURLConnection 只能 HTTP/1.1；
  2. 同步/异步/响应式一体：send() 同步阻塞、sendAsync() 返回 CompletableFuture——异步编排（并行调多个下游再聚合）零依赖就能写，不再必须引 Apache HttpClient 或 Jersey；
  3. API 设计现代化：Builder 模式构建请求、不可变对象、方法链——对比 HttpURLConnection 的抽象设计（getOutputStream 之前 setDoOutput 之类的顺序陷阱）是天壤之别；
  4. WebSocket 内置：标准库直接支持；
  5. 超时与连接池可配置：连接超时、请求超时一设置即可，HttpURLConnection 的超时配置晦涩且不完整。

业务视角的选型建议：

  • 轻量场景直接用它：调第三方 API、微服务间简单调用——少一个第三方依赖就少一份供应链风险（Log4j 事件后企业对依赖治理敏感度大增）；
  • 复杂场景仍看生态：需要精细连接池治理、拦截器体系、服务熔断集成（Resilience4j/Sentinel）时，Spring WebClient/OkHttp 生态更顺手——但 2026 年配合虚拟线程，"同步 HttpClient+虚拟线程"的组合正在回潮：同步代码的可维护性+虚拟线程的吞吐，比响应式 WebClient 更受团队欢迎。

一句话：标准 HttpClient 把"JDK 自带能干好 HTTP"变成现实，是 Java 11 升级清单里容易被忽略但实在的收益。

🏗 系统架构师 ​

Java 11 标准 HttpClient = 替代 HttpURLConnection 的现代 HTTP 客户端，改进对比（架构师视角）：

  • API 设计：Builder 模式 + 不可变对象（HttpRequest/HttpClient 不可变、线程安全可复用）；HttpURLConnection 的设计停在 2000 年代（单线程使用的可变状态、checked exception 泛滥、API 反直觉 setDoOutput）；
  • HTTP/2 原生支持：多路复用（同连接并发请求）、头部压缩、服务器推送——高并发调用下游时连接数大减（HTTP/1.1 keep-alive 池也要 N 条连接，H2 一条搞定并发）；自动协议协商（ALPN）；
  • WebSocket 内置：标准库直接支持（newWebSocketBuilder）；
  • 同步/异步双模：send()（阻塞，配虚拟线程是绝配）与 sendAsync()（返回 CompletableFuture，响应式编排）——虚拟线程时代：同步 send + 每请求虚拟线程 = 最简单的高并发客户端，CompletableFuture 链的回调地狱可以退役；
  • 超时体系完整：连接超时、请求超时分级设置（HttpURLConnection 的超时语义残缺）；
  • 依赖治理：JDK 自带——无第三方依赖（Apache HttpClient/OkHttp 的轻量替代），对库作者和 CLI/Agent 类小工具尤其有价值（零依赖分发）。

选型权衡：标准 HttpClient 覆盖 90% 场景；重拦截器体系、精细连接池治理、resilience 特性（重试/熔断）依然配 Resilience4j 或用框架客户端（Spring WebClient/RestClient）；注意：标准 HttpClient 没有内置自动重试与连接池高级配置——生产要自己包一层治理（超时、重试幂等、指标）。

💻 全栈开发专家 ​

Java 11 的 HttpClient（JEP 321）相比 HttpURLConnection 的改进，按工程痛点排：

1. API 设计现代化：

  • Builder 模式 + 不可变客户端：HttpClient.newHttpClient() 或定制超时/HTTP 版本/重定向策略；
  • 请求/响应分离（HttpRequest/HttpResponse），同步 send() 与异步 sendAsync()（CompletableFuture）双模式——HttpURLConnection 的 connect/read 超时设置、GET/POST 方法字段、错误流读取那套上世纪 API 终于退役。

2. HTTP/2 原生支持：

java
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)      // 自动协商
    .connectTimeout(Duration.ofSeconds(3))
    .followRedirects(Redirect.NORMAL).build();

HttpRequest req = HttpRequest.newBuilder(URI.create(api))
    .timeout(Duration.ofSeconds(5))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(json)).build();

HttpResponse<String> resp = client.send(req, BodyHandlers.ofString());
// 或异步：
client.sendAsync(req, BodyHandlers.ofString())
      .thenApply(HttpResponse::body)
      .thenAccept(System.out::println);

HTTP/2 多路复用省连接、服务器推送、头部压缩——对高并发调用下游的服务吞吐有实际收益。

3. 其他实打实的改进：响应体处理器灵活（ofString/ofFile/ofInputStream/ofByteArray/推入自定义 Subscriber——流式处理大响应不用全量进内存）；异步基于 NIO 不阻塞线程；WebSocket 客户端内置。

仍然欠缺（清醒点）：无内置连接池配置细节与拦截器、重试要自己包、无自动 JSON 序列化——生产微服务间调用还是 OkHttp/WebClient/RestClient 顺手；但JDK 自带、零依赖的场景（工具类、中间件 SDK、镜像裁剪的 native 应用）HttpClient 是首选。