dubbo导致mysql连接数太多_不可忽视的Dubbo线程池

问题描述线上突然出现Dubbo超时调用，时间刚好为Consumer端设置的超时时间。

有好几个不同的接口都报超时了

第1次调用超时，第2次(或第3次)重试调用非常快(正常水平)

Dubbo调用超时的情况集中出现了3次，每次都是过一会自动恢复

排查

排查日志

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

此时系统活动情况

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

查看Dubbo线程活动情况

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

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

该接口是否存在阻塞的代码？

硬着头皮重新看代码每一个分支，突然发现底层的一个方法中有http调用！会不会是这个http调用导致的超时？如果是的话，那么不同的接口调用超时的情况就说的通了，因为上层大部分接口都会调用这个底层方法。

怀揣着激动的心，仔细看了http调用的逻辑：用的是JDK提供的HttpURLConn