Spring Rest Client使用SimpleClientHttpRequestFactory时读取超时不符合预期

为什么实际耗时远超预期？ #

你遇到的问题核心在于SimpleClientHttpRequestFactory基于Java原生HttpURLConnection，仅配置connectionTimeout和readTimeout无法覆盖所有耗时环节：

• DNS解析无超时限制：HttpURLConnection的DNS解析依赖系统默认设置，无单独超时配置，遇到DNS服务响应慢时会消耗秒级时间
• 请求体写入无超时：POST请求写入请求体的过程未被现有超时参数覆盖，网络波动时这一步可能卡住
• 底层隐性等待逻辑：HttpURLConnection存在一些未暴露的重试、握手等待逻辑，这些环节的耗时不受当前配置约束

如何实现700ms总超时？ #

方案1：给现有代码快速添加全局超时（无需更换请求工厂） #

不用手动管理线程，直接用CompletableFuture包装请求流程，设置硬总超时，代码简洁：

var fac = new SimpleClientHttpRequestFactory();
fac.setConnectionTimeout(Duration.ofMillis(100));
fac.setReadTimeout(Duration.ofMillis(500));

var restClient = RestClient.builder().requestFactory(fac).build();

try {
    ResponseEntity<String> response = CompletableFuture.supplyAsync(() -> 
        restClient.post()
            .uri("...")
            .header("...", "123")
            .body("Some text")
            .retrieve()
            .toEntity(String.class)
    ).get(700, TimeUnit.MILLISECONDS);
    // 处理正常响应
} catch (TimeoutException e) {
    // 触发700ms总超时的处理逻辑
} catch (Exception e) {
    // 其他异常处理
}

这种方式直接给整个请求生命周期加了超时上限，无论中间哪个环节卡住，到700ms都会触发超时。

方案2：换用OkHttp请求工厂（全面覆盖所有超时环节） #

如果要从底层彻底管控所有可能的耗时点，推荐使用OkHttp3ClientHttpRequestFactory，它支持配置总调用超时、DNS超时、写入超时等全链路参数：

1. 先引入OkHttp依赖（Maven示例）：

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>4.11.0</version>
</dependency>

2. 配置全链路超时：

OkHttpClient okHttpClient = new OkHttpClient.Builder()
    .callTimeout(Duration.ofMillis(700)) // 整个请求的总超时（核心配置）
    .connectTimeout(Duration.ofMillis(100)) // TCP连接超时
    .readTimeout(Duration.ofMillis(500)) // 响应读取超时
    .writeTimeout(Duration.ofMillis(200)) // 请求体写入超时
    .build();

var restClient = RestClient.builder()
    .requestFactory(new OkHttp3ClientHttpRequestFactory(okHttpClient))
    .build();

// 正常发起请求，总耗时被严格限制在700ms内
ResponseEntity<String> response = restClient.post()
    .uri("...")
    .header("...", "123")
    .body("Some text")
    .retrieve()
    .toEntity(String.class);

callTimeout参数直接定义了从请求发起至响应接收的总时长，完全满足你的700ms要求，同时覆盖了所有可能的耗时环节。

总结 #

• SimpleClientHttpRequestFactory的默认配置存在超时盲区，会导致偶尔出现超长耗时
• 快速实现总超时可以用CompletableFuture的超时API，代码成本极低
• 追求更严谨的超时控制，换用OkHttp请求工厂是最优解

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