排查问题的技巧：索引，GC，容器，网络抓包，全链路追踪等技能

我们常说面试造火箭，很多人对此提出质疑，相信大家看了这篇文章会明白面试造火箭的道理，这篇排查问题的技巧涉及到索引，GC，容器，网络抓包，全链路追踪等基本技能，没有这些造火箭的本事，排查这类问题往往会无从下手，本篇也能回答不少朋友的问题：为什么学 Java 却要掌握网络，MySQL等其他知识体系，这会让你成为更出色的工程师哦。

一. 问题现象

商品团队反馈，会员部分 dubbo 接口偶现超时异常，而且时间不规律，几乎每天都有，商品服务超时报错如下图：

超时的接口平时耗时极短，平均耗时 4-5 毫秒。查看 dubbo 的接口配置，商品调用会员接口超时时间是一秒，失败策略是failfast，快速失败不会重试。

会员共部署了8台机器，都是 Java 应用，Java 版本使用的是 JDK 8，都跑在 docker 容器中 。

二. 问题分析

开始以为只是简单的接口超时，着手排查。首先查看接口逻辑，只有简单的数据库调用，封装参数返回。SQL 走了索引查询，理应返回很快才是。

于是搜索 dubbo 的拦截器ElapsedFilter打印的耗时日志（ElapsedFilte r是 dubbo SPI 机制的扩展点之一，超过 300 毫秒的接口耗时都会打印），这个接口的部分时间耗时确实很长。

再查询数据库的慢 SQL 平台，未发现慢 SQL。

1. 数据库超时？

怀疑是获取数据库连接耗时。代码中调用数据库查询可以分为两步，获取数据库连接和 SQL 查询，慢SQL 平台监测的 SQL 执行时间，既然慢 SQL 平台没有发现，那可能是建立连接耗时较长。

查看应用中使用了 Druid 连接池，数据库连接会在初始化使用时建立，而不是每次 SQL 查询再建立连接。Druid 配置的 initial-size（初始化链接数）是 5，max-active（最大连接池数量）是 50，但 min-idle（最小连接池数量）只有 1，猜测可能是连接长时间不被使用后都回收了，有新的请求进来后触发建立连接，耗时较长。

因此调整 min-idle 为 10，并加上了 Druid 连接池的使用情况日志，每隔 3 秒打印连接池的活跃数等信息，重新观察。

改动上线后，还是有超时发生，超时发生时查看连接池日志，连接数正常，连接池连接数也没什么波动。

2. STW？

因此重新回到报错日志观察，ElapsedFilter 打印的耗时日志已经消失。由于在业务方法的入口和出口，以及数据库操作的前后打印了日志，发现整个业务操作耗时极短，都在几毫秒内完成。

但是调用端隔一段时