小李最近是真头疼，愁得头发都快掉几根了。

他管的那个后端服务，之前一直跑得顺风顺水，没出过啥大毛病。可自从对接了一个第三方数据接口，系统就跟中了邪似的，时不时就“卡死”——用户反馈说页面半天打不开，运维那边的告警短信更是一条接一条，响得他心发慌。

他查来查去，熬了两个通宵，总算找到问题根源了：罪魁祸首就是那个第三方接口的代理服务器，响应慢得能急死人，有时候几十秒过去了，一点数据都返回不了。而小李写的代码，就跟个死等的愣头青似的，一直傻等着对方响应，线程被死死占住，一个请求没处理完，后面的请求就跟排队似的越堆越多，到最后，整台服务器直接被拖垮罢工了。

这个场景，做开发、搞运维的朋友，是不是觉得特别眼熟？

其实说白了，这就是“慢代理”搞出来的雪崩效应——一个环节慢半拍，整个系统链条都得跟着遭殃。而要解决这个麻烦，说起来简单，做起来也不难，最直接、最有效的办法，就四个字：设置超时。

超时是什么？说白了就是“不等了”

所谓超时，说白了就是给你的代码定一个“等待上限”，别让它无限制地傻等。举个例子，你调用一个远程接口，正常情况下1秒钟就能拿到结果，那你就可以设置一个规矩：最多等3秒，超过3秒还没反应，对不起，不等了，直接报错，或者走备用方案。

这样一来，不管对方的代理再慢、再拖，也不可能把你的线程死死拽住不放。该放弃就放弃，该释放资源就释放资源，不至于让一个慢请求，拖垮整个系统。

这里得提醒一句，超时一般分两种，千万别搞混，也别偷懒只设一个，两个都得安排上：

连接超时：就是你的代码和对方服务器建立连接的最大等待时间。要是连连接都建立不上——比如对方IP不通、端口被墙，这种情况根本没必要傻等，几秒钟没反应就直接放弃。

读取超时：连接成功之后，你发了请求过去，等着对方返回数据的最大时间。对方处理得慢、网络传输卡壳，都属于这种情况。

很多刚入行的新手，最容易犯的错就是只设其中一个。比如只设了连接超时，没设读取超时，结果连接是很快建好了，但对方返回数据用了30秒，你的线程照样被卡得动弹不得。所以这两个超时，缺一不可，少一个都可能出大问题。

设多长时间才合理？别瞎定

至于超时时间设多久合适，没有统一的标准答案，但有几个小原则，你照着来，基本不会出错。

第一，看你的业务能忍多久。比如用户在你网页上点一个按钮，你让他等超过3秒，他大概率就没耐心了，直接关掉页面走人。那你的超时时间，最好就别超过3秒。但如果是后台的批量任务，比如半夜自动同步数据，对时间没那么敏感，那就可以适当放宽一点。

第二，看正常情况下的P99响应时间。可能有人不知道P99啥意思，简单说就是99%的请求，都能在这个时间内完成。比如你统计了一下，正常情况下，99%的请求都能在500毫秒内返回，那你就可以设1秒作为超时时间——留一倍的余量，既给了对方一点缓冲空间，也不会让自己的系统被拖慢。

第三，层层超时，层层递减。如果你的请求链路比较长，比如用户请求你的服务，你的服务再调用A服务，A服务再调用B服务，那超时时间就得一层比一层短。比如用户到你这里设3秒，你到A服务就设2.5秒，A到B就设2秒，这样最外层的超时才能兜住，不至于出现“外层等3秒，内层等5秒”的尴尬情况。

超时之后怎么办？别扔个异常就完事

设置超时只是第一步，不是说设完就万事大吉了。超时之后该怎么办，你得提前想好，不能扔个异常就不管不顾，那样还是会出问题。

常见的处理办法有三种，大家可以根据自己的业务情况选：

第一种，重试。如果超时只是偶尔一次，可能是网络抖动导致的，那重试一次说不定就成功了。但记住，别无限重试，一般1到2次就够了，而且重试的间隔，最好比正常的超时时间短一点，别越重试越拖。

第二种，降级。超时了，说明对方的服务不可靠，这时候就别死磕了，可以返回一个缓存的旧数据，或者返回一个默认结果。比如你调用天气接口超时了，就可以告诉用户“暂无最新天气数据，这是上次查询的结果”，总比让用户一直等、最后报错强。

第三种，熔断。如果连续好几次都超时，说明对方的服务大概率是出问题了，这时候就干脆别再调用了，直接快速失败，等过一段时间再尝试恢复。这就跟家里的保险丝一样，过载了就自动断开，避免烧坏电器，这就是常说的“熔断器”模式。

别让你的“好心”，害了整个系统

很多开发的朋友，可能会有这样的心理：我把超时时间设长一点，是不是更稳妥？万一对方只是稍微慢一点，多等一会儿，说不定就能成功了，也能减少报错。

这个想法，乍一听好像挺有道理，实际上就是坑自己、坑系统。

你好好想想，要是你把超时时间设成60秒，一个慢请求就能占住一个线程60秒。你的服务器要是有200个工作线程，理论上只要200个这样的慢请求同时进来，所有线程就全被占满了。后面来的正常请求，要么排队，要么直接被拒绝，整个系统就彻底瘫痪了。

这就是典型的“好心办坏事”——你给了慢代理足够的时间，却牺牲了整个系统的可用性。

正确的思路应该是：快失败，而不是慢成功。与其让一个请求拖60秒，最后还是失败，不如3秒就让它失败，把释放出来的资源，去处理其他正常的请求，这样整个系统才能稳定运行。

总结

其实慢代理并不可怕，可怕的是你的代码没有超时保护，硬生生被它拖垮。

记住这几点，就能避开大部分坑：

- 连接超时和读取超时，两个都要设；

- 超时时间别瞎定，结合业务容忍度和正常响应时间来设；

- 如果是链路调用，超时时间要层层递减，外层才能兜住；

- 超时之后别不管，做好重试、降级、熔断这三个应对策略；

- 宁可快失败，也不要慢成功，别因小失大。

回到小李的例子，他后来给每个外部调用都加上了合适的超时时间——连接超时2秒，读取超时3秒，超时后自动重试一次，还配上了降级缓存。从那以后，不管那个慢代理再怎么拖，也再也拖不垮他的系统了。

最后提醒一句，你的系统，也该检查一下了。看看代码里的HTTP客户端、RPC调用、数据库查询，有没有设置超时。要是没有，今天就去改，别等到线上出了故障，用户投诉、运维追责，再后悔就晚了。