问题排查

由于现场已被破坏，只能先看监控和日志

 

监控

除了上述监控外，翻看了 B 服务 CPU 和内存等基础监控，发现故障的几台机器内存上涨比较多，都达到了 80% 的水平线，且 CPU 消耗也变多

这时比较怀疑内存问题，于是看了下 JVM 的 fullGC 监控

经过测试果然复现了，如 issue 所说，当 kill -9 掉第一个 provider 时，消费者全局 ExecutorService 被关闭，当 kill -9 第二个 provider 时，SHARED_EXECUTOR 也被关闭。

 

那么这个线程池是用来干什么的呢？

 

它在 HashedWheelTimer 中被用来检测 consumer 发出的请求是否超时。

 

HashedWheelTimer 是 dubbo 实现的一种时间轮检测请求是否超时的算法，具体这里不再展开，改天可以详细写一篇 dubbo 中时间轮算法。

 

当请求发出后，如果可以正常返回还好，但如果超过设定的超时时间还未返回，则需要这个线程池的任务来检测，对已经超时的任务进行打断。

 

如下代码为提交任务，当这个线程池被关闭后，提交任务就会抛出异常，超时也就无法检测。

到这里恍然大悟：如果请求一直发送，不超时，那是不是有可能撑爆内存？于是我又模拟了一下，并且开了 3 个线程一直请求  provider，果然复现出内存被撑爆的场景，而当不触发这个问题时，内存是一直稳定在一个低水平上。