在实际的开发中，网络超时是一个比较常见的问题，比如说针对支付系统，超时就需要进行和三方人员进行核对订单状态，是否人工介入处理。
但其实在设计网络框架的时候，一般都有两个超时参数
连接超时参数 ConnectTimeout，让用户配置建连阶段的最长等待时间；
读取超时参数 ReadTimeout，用来控制从 Socket 上读取数据的最长等待时间。
一般来说连接超时，除非是网络不通，否则的话 TCP三次握手都是很快就可以建立连接的。所以对于连接超时时间一般配置比较短。
1.对于读取超时，认为服务端的处理会中断
@RestController
@RequestMapping("/clientreadtimeout")
@Slf4j
public class HttpController {
private String getResponse(String url, int connectTimeout, int readTimeout) throws IOException {
return Request.Get("http://localhost:8088/clientreadtimeout" + url)
.connectTimeout(connectTimeout) //连接时间1S
.socketTimeout(readTimeout)//读取时间2S
.execute()
.returnContent()
.asString();
}
@GetMapping("/client")
public String client() throws IOException {
log.info("client1 called");
//服务端5s超时，客户端读取超时2秒
return getResponse("/server?timeout=20000", 1000, 15000);
}
@GetMapping("/server")
public void server(@RequestParam("timeout") int timeout) throws InterruptedException {
log.info("server called");
TimeUnit.MILLISECONDS.sleep(timeout);
log.info("Done");
}
}
2023-12-02 16:39:20.405 INFO 51914 --- [nio-8088-exec-2] c.q.spingboot.controller.HttpController : Done
在code中，设置了15S的读取超时时间，1S的连接时间，但是整个方法的执行sleep了20S，虽然调用超时了，但是方法还是正确执行完毕了。所以不能轻易的下结论认为超时就一定执行失败了，可能只是服务端处理任务比较久，超过了设置了最大socket读取时间。
2.第二个误区，以为读取超时只是socket层面的概念
通常连接超时大多是网络不通或者服务不在线。而读取超时是服务处理超时，客户端向socket写入数据后，等待服务端写入数据给socket。也即是服务端处理业务逻辑的时间。
3.合理参考实际业务情况 设置超时时间
一般来说，如果下游服务处理过久，我们可以设置一个合理的超时时间，比如平均处理20S，那么久可以设置30S。通过HTTP请求获取结果都是同步调用，所以如果超时时间设置太久，就可能出现超时等待，当有大流量请求进来，那么就会出现大量线程的等待，最终拖垮服务。
所以建议是，对于定时任务或者异步任务，读取超时配置可以配置长一点，但是对于面向客户或者有大流量接口的同步接口，并发量比较大，所以不推荐设置太长的超时时间。一般建议是30S。
设置时间太短，比如2S，但是实际下游处理3S，那么就永远获取不到结果。所以设置一个合理的中位数是需要结合具体的业务场景考虑。
小结
超时一般对应的重试机制，但是需要下游有幂等。所以在对接一些上下游服务的时候，需要考虑多种异常情况，而不能只完成需求层面的东西，不关注技术点上的异常设计。