线上Java服务启动后告警频发？用Arthas精准定位超时根因

一、问题背景：一次典型的启动后告警

最近，我们的服务在每次发布或重启后都会产生大量异常告警。告警并非随机出现，而是呈现出高度规律性：从发版动作开始，一直持续到发版结束后几分钟内，随后自行恢复。

起初，团队将怀疑重点放在流量接入过快上。按照现有发布流程，持续集成/持续部署（CICD）流水线在服务启动后会主动探测 check.do 接口，确认服务进程是否已就绪。我们推测，check.do 返回成功的那一刻，CICD 随即接入线上真实流量，而此时应用内部的各项资源（如线程池、数据库连接池、缓存客户端等）可能尚未完全预热或初始化完毕，从而引发大量异常。

为验证这一假设，我们与运维团队沟通，尝试将流量接入的时机统一延迟 30 秒。然而，这一措施并未奏效：告警依然持续不断，且时间窗口并未因为延迟而缩短。这迫使我们放弃“流量接入过快”的初步假设，开始深入分析问题表象背后的真实原因。

二、问题表象的完整还原

为了澄清问题，我们选取了线上某一台机器作为观察对象，完整的启动日志时间线如下：

2024-09-04 16:09:50  INFO - 启动应用，执行成功
2024-09-04 16:12:36  WARN - 检查接口: check.do, 响应结果: ok
2024-09-04 16:13:07  INFO - 启动后等待时间(秒): 30
2024-09-04 16:13:07  INFO - 恢复 Dubbo 流量成功
2024-09-04 16:13:39  INFO - 恢复 HTTP 流量成功

从时间线上可以清晰看到，check.do 接口在应用启动后约 2 分 46 秒即返回成功，但真正的 HTTP 流量恢复发生在 3 分 49 秒后。也就是说，即便预留了近 1 分钟的空窗期，问题依旧存在。

2.1 Dubbo 接口超时集中爆发

在 HTTP 流量恢复后，大量调用下游服务的 Dubbo 接口出现超时。以画像接口为例，告警开始时间为 16:14:07，结束时间为 16:17:31，期间累计超时请求数高达 578 次。这一持续时长约 3 分半的异常窗口，与应用的“启动后恢复期”高度吻合。

2.2 HTTP 接口响应时间飙升

不仅是 Dubbo 调用，大部分 HTTP 接口同样出现严重的响应延迟。正常情况下 P95 响应时间维持在几十毫秒量级，而在问题窗口内飙升至数秒，直到 16:17:30 之后才逐步回落至正常水位。

综合来看，这一现象并非单一接口的偶发问题，而是整个应用在启动后的一段时间内处于“亚健康”状态，所有依赖该应用的上下游链路均受到波及。

三、初步排查方向与手段

面对上述现象，我们首先排除了网络抖动和下游服务故障的可能性——告警集中在同一时间窗口且规律性极强，网络因素难以解释如此整齐的故障曲线。

接下来，我们尝试从 JVM 层面寻找线索。常规手段包括：

1. 查看 GC 日志：确认是否存在频繁的 Full GC 或长时间的 Stop-The-World 停顿；
2. 监控 CPU 与内存：观察应用启动后 CPU 使用率、堆内存与非堆内存的波动情况；
3. 检查线程池状态：重点观察 Dubbo 与 Tomcat 线程池是否出现队列积压。

然而，上述手段只能提供宏观层面的数据，无法精确回答一个核心问题：当超时发生时，业务线程究竟阻塞在什么代码路径上？

要回答这个问题，我们需要一把能够深入 JVM 内部、实时观测线程执行状态的“手术刀”。此时，我们决定引入开源诊断工具 Arthas。

四、Arthas 在本次排查中的关键应用

Arthas 是 Java 领域广泛使用的在线诊断工具，其核心价值在于：无需重启应用、无需修改代码，即可对运行中的 JVM 进行实时观测与干预。以下是我在此次排查中实际用到的一组关键命令。

4.1 使用 dashboard 建立全局视图

问题发生时，我们首先在故障机器上启动 Arthas，并执行 dashboard 命令。该命令以仪表盘形式展示 JVM 的整体运行状态，包括：

• 各线程的 CPU 占用率与状态；
• 堆内存与非堆内存的使用情况；
• GC 次数与耗时；
• 类加载数量等关键指标。

通过观察 dashboard 输出，我们很快注意到一个异常特征：在超时窗口内，CPU 占用并未出现明显的尖峰，但部分业务线程长时间处于 WAITING 或 BLOCKED 状态，且线程数量显著增加。这提示我们，问题大概率并非由 CPU 密集型计算引起，而是线程在等待某种资源或锁。

4.2 使用 thread 命令聚焦线程状态

dashboard 提供了宏观视图，但要精确定位问题线程的具体阻塞位置，需要进一步使用 thread 命令。

thread -n 3 可以打印出当前 CPU 占用最高的前 3 个线程的堆栈。然而在本次场景下，由于问题并非 CPU 密集，我们改为执行：

thread --state WAITING

该命令会列出所有处于 WAITING 状态的线程，并附上完整的线程堆栈。通过对堆栈的逐一查看，我们发现了大量业务线程阻塞在同一个位置——等待数据库连接池获取连接。

进一步的堆栈内容表明：

• 线程正在调用 MyBatis 的 Mapper 方法；
• 执行过程中需要从连接池获取一个连接；
• 连接池中的所有连接都已被占用，导致线程陷入等待。

换言之，数据库连接池被耗尽，是导致接口超时的直接原因之一。

4.3 使用 trace 定位方法级耗时

thread 命令帮助我们锁定了线程阻塞在“获取连接”这一动作上，但连接耗尽本身可能只是中间环节。我们继续使用 Arthas 的 trace 命令，对关键业务方法的调用链进行耗时分析。

例如，对画像查询接口的入口方法执行：

trace com.example.service.PortraitService queryPortrait

trace 会输出该方法内部每一层子调用的耗时分布。结果显示：

• 与数据库交互的 Mapper 方法耗时异常高，平均超过 2 秒；
• 而调用下游 Dubbo 服务的时间相对稳定，并非瓶颈。

综合 thread 与 trace 的输出，我们可以还原出一条清晰的故障链路：

HTTP 请求进入 → 业务方法执行 → 调用数据库 Mapper → 尝试从连接池获取连接 → 连接池已满 → 线程长时间等待 → 请求超时。

五、根因分析与修复方案

5.1 直接原因：数据库连接池配置不足

在服务启动后的短时间内，大量请求同时涌入，导致数据库连接池的活跃连接数瞬间达到上限。而连接池的初始大小与最大大小设置偏小，无法支撑启动高峰期的并发请求量。每个新请求都需要排队等待空闲连接，连接等待时间被放大，进而引发接口超时。

5.2 深层原因：启动阶段资源预热缺失

我们进一步审视了应用启动后的资源初始化逻辑，发现：

• 数据库连接池虽然配置了最小空闲连接数，但实际在启动完成后的一段时间内，连接并未全部建立，而是以懒加载方式逐步创建；
• 部分热点数据缓存（如本地 Caffeine 缓存）在启动时未执行预热操作，导致启动初期大量请求直接穿透至数据库，放大了连接池压力。

5.3 修复方案与验证

针对上述根因，我们实施了以下修复措施：

1. 调整连接池参数：将最小空闲连接数调大，确保应用启动后即可持有足够数量的空闲连接；同时将最大连接数上调，以应对启动高峰的瞬时流量冲击。
2. 显式预热数据库连接：在应用启动完成后、恢复流量之前，主动执行一次简单的数据库查询，强制连接池完成连接的创建与初始化。
3. 引入缓存预热机制：在启动阶段加载热点数据到本地缓存，避免大量请求在启动初期穿透至数据库。
4. 增加启动健康检查维度的完善性：将 check.do 接口的逻辑扩展为包含数据库连通性、缓存可用性、线程池状态等核心资源的综合检测，而不是仅返回进程存活状态。

修复后，重新执行发布流程，观测结果令人满意：

• 告警窗口完全消失；
• 接口 P95 响应时间在流量恢复后立即回到正常水平；
• 数据库连接池活跃连接数趋于稳定，未再出现耗尽情况。

六、复盘与经验总结

6.1 工具链的正确使用方式

Arthas 在此次排查中发挥了不可替代的作用。相比于日志和监控系统的宏观数据，Arthas 提供了微观层面的实时观测能力，让我们能够在问题发生时直接看到线程的执行路径和阻塞位置。它的 thread 和 trace 命令组合，几乎可以应对所有“接口变慢但日志无异常”的场景。

6.2 从表象到根因的思维链路

本次问题的排查过程也给我们带来方法论上的启示：

• 不要被时间线迷惑：延迟流量接入并不能解决根因问题，只会推迟问题的暴露时间；
• 宏观指标只能定位方向：CPU、内存、GC 数据是必要的，但往往不足以定位到具体代码行；
• 线程堆栈是最有力的证据：当系统表现“卡顿”时，首先要回答的问题是——线程到底在执行什么？

6.3 面向未来的排查体系

在后续的工程实践中，我们将 Arthas 的常用诊断命令固化到了团队内部的应急排查手册中，并配合监控告警系统，形成了一套“告警触发 → 采集线程栈 → 分析阻塞点 → 定位根因”的标准运维流程。这一做法显著缩短了故障定位时间，也降低了团队成员的问题排查门槛。

七、结语

线上服务的稳定性挑战，往往隐藏在启动阶段这一短暂而复杂的窗口期内。一个看似简单的“启动后告警”问题，背后可能交织着连接池配置、资源预热、流量调度等多个因素。掌握 Arthas 这类线上诊断工具，能够帮助开发者在纷繁复杂的表象中迅速找到问题的核心，真正做到“对症下药”。

希望本文的实战复盘，能为正在面临类似困扰的开发者提供一条清晰、可借鉴的排查路径。