实际上，我已经看到了Dubbo源代码中超时的处理逻辑。但是，没有记录。最近，我看到有人在某个脉搏上问这个问题，并想再次对其进行审查。
从Dubbo的请求开始，请参阅Dubbo（2.6.6）在超时期间如何处理：
可以从返回值响应图类型中可以看出，这是一种异步方法（不包括Dubbo的异步调用）。然后可以从响应future中看到呼叫超时的关键：
您可以看到这是一个接口。从请求方法中，您可以知道实现类是默认图，从构造函数开始：
可以知道，每个默认值都有一个ID，并且等于requestID。超时是从URL获得的配置。没有默认的1000ms。
从代码的注释中，您可以看到期货地图应该是关键，并且是等待地图。
DefaultFuture中还有另一种方法：
您可以看到呼叫所在的地方：
com.alibaba.dubbo.remoting.exchange.support.header.headrexchangehangehandler＃收到
com.alibaba.dubbo.remoting.exchange.support.header.headerexchangehandler＃handleresponse
返回到defaultfuture.receperive，您可以看到您通过响应ID从期货中删除默认图，然后调用doreceived方法，这意味着响应ID和请求ID是相同的。
第一个是锁，然后通过觉醒堵塞了螺纹，请参见在哪里阻止完成的条件：
这是获取方法。确实在请求请求之后确实调用了GET方法：
可以看出，GET方法的一般逻辑是首先获取锁，然后是循环判断ISDONE，并阻止条件。当条件是超时时，如果任务完成或超过超时的结束，则判断isdone。是否确定是否是客户端还是通过已发送（请求请求时间）来确定其端端或服务的超时。
ISDONE逻辑如下：
如果这是正常的响应，则可能是暂停现象。您可以看到GET方法最终被称为函数：
server_timeout（服务器超时）：这是普通的消费者端请求RPC接口。由于性能和其他原因，服务器的处理时间超出了超时配置时间。
client_timeout：我们可以查看clienttime out是否由已发送（表示已发送> 0）确定，那么何时会更改？这是发送请求的位置：
换句话说，一旦成功返回了调用，就不会考虑客户端的超时。然后Client_timeout很可能是由于客户端网络，系统和其他原因的超时。
原始：https：//juejin.cn/post/709964664427700238