Dubbo线程池你不得不会的知识

问题描述

线上突然出现Dubbo超时调用，时间刚好为Consumer端设置的超时时间。
有好几个不同的接口都报超时了
第1次调用超时，第2次（或第3次）重试调用非常快（正常水平）
Dubbo调用超时的情况集中出现了3次，每次都是过一会自动恢复

排查

排查日志
看到调用超时，首先就拿着traceId去服务提供方查日志。 奇怪的是，在服务提供方的业务日志里面，只有正常的调用日志（耗时正常），没有超时调用的日志。 从正常的调用日志里面看，一切都是正常的，看不出所以然。 给人的感觉就是超时那次请求的调用没有达到服务提供方。

此时系统活动情况
通过系统历史监控，我们发现除了gc比平时稍微高一点外（也在正常水位），没有其他的异常；CPU、内存、网络等指标都在正常范围。

查看Dubbo线程活动情况
第2次系统集中超时报警的做的第一件事就是登录到那台服务器查看dubbo线程活动情况：看下能不能找到阻塞在哪一行代码。很遗憾，所有的dubbo线程都没有阻塞，都是正常的WAITING状态。

并没有明显表明阻塞在某段代码，这可难倒我们了：如果没有阻塞的话，为什么dubbo调用方会报超时？继续看代码

该接口是否存在阻塞的代码？
硬着头皮重新看代码每一个分支，突然发现底层的一个方法中有http调用！会不会是这个http调用导致的超时？如果是的话，那么不同的