记几次 [线上环境] Dubbo 线程池占满原因分析（第二次：CompletableFuture）

[线上环境] Dubbo 线程池占满原因排查系列

记几次 [线上环境] Dubbo 线程池占满原因分析（第一次：HttpClient）
记几次 [线上环境] Dubbo 线程池占满原因分析（第二次：CompletableFuture）
记几次 [线上环境] Dubbo 线程池占满原因分析（第三次：GC STW）

---

---

前言

  某天早上9点左右收到线上故障报警，超过3个商家反馈“无法正常进入功能页面，点击相关操作提示报错”。
  经过排查定位，故障应用线上部署了30台机器（4c8g），由于代码中使用 CompletableFuture不规范引起部分机器（8/30台）dubbo 线程池耗尽出现故障。而我们的dubbo框架采用随机负载均衡策略，导致故障机器还会有流量过去，打在故障机器的请求都会出现异常。

一、问题分析

1、分析日志

  商家反馈的是“无法正常进入页面，点击操作报错”，所以第一反应就是去看看线上是否有ERROR日志，如果能够找到报错日志那么就能很快定位到问题的原因，先看前端node应用系统日志：

根据上面日志信息很快得到两个结论：
1、在9:09至9:23期间出现了较多的error日志，目前已经逐步平稳；
2、问题期间后端接口出现了dubbo线程池占满的情况。

继续查看下游后端应用日志，发现dubbo线程池占满的还是更底层的一个应用（底层应用dubbo线程池占满引起了雪崩效应）：

根据上游日志traceId（调用链ID，上下游所有相关系统都会打印，方便查找整条请求链路的日志）继续排查底层应用日志：