Java处理第三方服务超时需设connectTimeout（2–5秒）和readTimeout（略大于P95，如3–4秒），捕获ResourceAccessException并按cause分类处理，结合CompletableFuture异步超时控制、重试与熔断降级提升韧性。
Java 中处理第三方服务调用超时异常，核心是“提前设限、主动拦截、分级响应”。不能等它卡住线程再补救，而要在发起请求前就明确连接和读取的等待边界，并对超时后的行为有预案。
明确区分 connectTimeout 和 readTimeout
超时不是笼统的一个值，而是两个独立阶段：
- connectTimeout：建立 TCP 连接（含 DNS 解析、三次握手）的最大等待时间。设太短会误判网络波动，设太长会让失败请求迟迟不返回。建议 2–5 秒，DNS 不稳时可略上浮。
- readTimeout：连接建立后，等待服务端返回完整响应数据的时间。它应略大于第三方接口的 P95 响应时间，但必须小于你自身接口的 SLA。例如对方平均耗时 800ms，P99 是 2.3s，你可设为 3–4s。
用 RestTemplate 示例：
HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();factory.setConnectTimeout(3000);
factory.setReadTimeout(4000);
RestTemplate restTemplate = new RestTemplate(factory);
捕获并分类处理 ResourceAccessException
RestTemplate 超时统一抛出 ResourceAccessException（其根因通常是 SocketTimeoutException 或 ConnectException）。不要只 catch Exception，要针对性识别：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 检查异常 cause 是否为
SocketTimeoutException→ 明确是 readTimeout 触发； - 检查是否为
ConnectException或UnknownHostException→ 属于 connectTimeout 或 DNS 问题； - 日志中记录具体类型、URL、耗时，便于后续归因（比如全是 ConnectException，大概率是 DNS 或防火墙问题）。
示例处理逻辑：
try {ResponseEntity
return res.getBody();
} catch (ResourceAccessException e) {
if (e.getCause() instanceof SocketTimeoutException) {
log.warn("read timeout for {}, fallback to default", url);
return getDefaultData();
} else if (e.getCause() instanceof ConnectException) {
log.error("connect failed for {}, check network or DNS", url);
throw new ServiceException("third-party unreachable");
}
}
引入异步+超时控制增强可控性
当你的接口本身不能长时间阻塞（如 Web 接口要求 2s 内返回），但第三方又偶有慢响应，同步等待不可行。此时用 CompletableFuture + get(timeout) 是更安全的选择：
- 把 RestTemplate 调用包装进 supplyAsync，交由独立线程池执行；
- 主线程调用
future.get(2, SECONDS)，超时即中断任务，不阻塞主流程； - 注意：需手动 shutdown 线程池或使用 Spring 管理的 TaskExecutor，避免内存泄漏。
关键点：这个 2 秒是你对外承诺的总耗时上限，和内部 RestTemplate 的 4 秒 readTimeout 是两层控制，形成兜底。
配合重试与降级策略提升韧性
单次超时不等于失败，尤其对偶发网络抖动或服务瞬时过载：
- 简单场景可用 Spring Retry（@Retryable），配指数退避（如初始 100ms，最多 3 次）；
- 关键业务建议加熔断（如 Resilience4j），连续超时 N 次后自动熔断一段时间，直接走降级逻辑；
- 降级方案要真实可用：缓存旧数据、返回静态默认值、异步补偿、引导用户稍后重试等，避免“假成功”（比如返回空数据却没提示）。
不复杂但容易忽略。
