Java 服务发布期超时与 CPU 飙高问题排查实践

一、背景：发布期告警的典型场景

在 Java 服务的发布或重启过程中，经常会出现一类规律性很强的现象：服务进程启动成功后，监控系统在几分钟内持续产生超时告警，随后又逐渐恢复。这类问题看似与发布动作直接相关，但只靠表面现象很难判断根因。它可能来源于流量接入过早、连接池尚未预热、缓存未加载、JIT 未生效、线程池大量初始化、下游依赖恢复延迟等多种因素。

本文讨论的场景正属于这一类。某服务在每次发布或重启时，都会在启动完成后的数分钟内集中出现接口超时、CPU 使用率升高和线程数突增等问题。团队最初怀疑是流量接入过快导致，但在将流量接入时间延后 30 秒后，告警并没有消失。这说明问题并不只是“什么时候接入流量”这么简单，而是需要深入 JVM 运行状态和线程行为进行分析。

二、问题表象：发布后的四个典型信号

为了定位问题，我们先对一次典型发布过程进行时间线还原。服务启动、健康检查、延迟等待、流量恢复等节点均有日志记录，但真正值得关注的是流量恢复之后的表现。

2.1 下游接口超时集中出现

在 HTTP 流量恢复后，服务调用下游 Dubbo 接口开始出现大量超时。以某个画像查询接口为例，超时告警从流量恢复后约 30 秒开始，持续约三分半钟，期间累计超时请求数达到数百次。这说明服务并不是无法调用下游，而是在某个时间段内调用能力严重下降。

2.2 HTTP 接口响应时间显著上升

同一时间段内，本服务对外提供的 HTTP 接口也出现明显劣化。P95 响应时间从正常情况下的几十毫秒飙升至数秒级别。请求量并未显著变化，因此可以初步判断，服务内部处理能力出现了瓶颈，而不是单纯的下游网络问题。

2.3 CPU 使用率接近满载

发布前后的 CPU 监控显示，启动阶段存在短时突刺，而在流量接入后，CPU 使用率再次迅速上升到接近 100%，并持续数分钟，随后逐步回落。CPU 长期接近满载通常与线程空转、频繁 GC、锁竞争、序列化压力或无效计算有关。

2.4 活跃线程数与阻塞线程数突增

线程监控进一步显示，在健康检查通过前后，活跃线程数从几百急增到上千，并在流量接入后继续增加，直到故障结束时才趋于稳定。更关键的是，Runnable 和 Blocked 状态的线程数量也同步上升，说明系统不仅线程数量多，而且大量线程在争抢资源或等待锁。

三、初步判断：为什么延迟接入流量没有解决问题

最初团队假设：健康检查一通过就接入线上流量，导致服务在尚未完成预热的情况下接收大量请求，从而引发超时。于是将流量接入延迟 30 秒，但问题依旧存在。

从结果反推，原因可能包括：

1. 服务启动阶段虽然已经完成，但内部组件仍未完成预热，30 秒并不足以覆盖所有资源初始化；
2. 真正的问题并不是“请求来得太早”，而是“某些线程或资源争用导致处理能力下降”；
3. 流量接入方式本身可能不是瓶颈，而是流量恢复后触发了某种集中初始化或资源竞争。

因此，问题的核心从“何时接入流量”转向“流量接入后系统内部发生了什么”。

四、排查思路：从线程栈和资源争用入手

对于这类发布期偶发但可复现的问题，最有效的方法是抓取故障期间的线程栈，结合 CPU、线程状态和锁信息进行分析。

4.1 抓取高 CPU 时的线程状态

在 CPU 接近满载的时间窗口内，可以周期性执行线程 dump。重点关注以下信息：

• RUNNABLE 线程是否集中在某几类任务上；
• 是否存在大量线程处于 BLOCKED 状态；
• 锁持有者是谁，是否有长任务持锁不释放；
• 是否存在线程池队列积压、拒绝策略触发等情况。

通过对比多次 dump 结果，可以判断线程是持续在计算，还是在等待锁或者等待下游响应。

4.2 分析线程名与任务来源

Java 应用中，线程名往往能直接反映任务来源。发布期线程数激增，可能与以下因素有关：

• 启动时大量初始化线程池；
• 定时任务集中触发；
• 流量恢复后缓存加载任务批量执行；
• 连接池在首批请求到来时才真正建立连接。

如果发现大量线程名指向缓存加载、连接建立或资源初始化相关逻辑，就说明预热逻辑可能存在缺陷。

4.3 检查锁竞争与同步块

Blocked 线程突增通常意味着某个同步资源被长时间占用。需要重点排查：

• 是否存在大对象初始化被放入锁内；
• 是否有单例对象的初始化在高并发下出现竞争；
• 是否使用了全局锁保护了耗时操作；
• 是否存在多个线程同时触发同一个懒加载逻辑。

这类问题在发布后集中暴露，是因为进程刚启动时大量懒加载逻辑尚未执行，首批请求会同时触发这些逻辑，从而形成锁竞争。

五、根因定位：启动后首次请求触发的资源集中初始化

结合线程栈和代码走查，最终定位到以下几类问题：

5.1 下游连接池未预热

服务启动时，下游连接池虽然完成对象创建，但并未真正建立网络连接。当首批请求到达时，大量线程同时尝试创建连接。由于连接建立本身有一定耗时，且连接池可能配置了最大连接数限制，导致线程在获取连接时阻塞。此时下游接口超时、本服务 CPU 升高等现象会同时出现。

解决思路是增加连接池预热逻辑，在健康检查通过前主动建立若干连接，而不是等到业务请求到来时再创建。

5.2 本地缓存懒加载集中触发

部分本地缓存在首次访问时才触发加载。发布后首批请求集中访问热点数据，导致缓存加载任务密集执行。如果加载逻辑中存在锁或线程池复用，可能进一步加剧线程堆积。

解决思路是将缓存预热前移，在启动阶段完成核心数据的加载，或者对缓存加载任务进行限流和去重。

5.3 线程池初始化与任务提交不匹配

启动阶段虽然创建了大量线程池，但部分线程池初始线程数为零。业务请求到来后，线程池需要频繁创建新线程，线程创建本身会消耗 CPU 和内存资源。当请求量较大时，线程数量和上下文切换开销迅速上升。

解决思路是根据业务场景设置合理的核心线程数，并在启动阶段预创建核心线程。

六、优化措施：从“延迟接入”转向“主动预热”

如果只关注“何时接入流量”，可能会忽略服务内部是否真正准备好。更合理的策略是：在健康检查通过前，完成尽可能多的预热工作，并让健康检查真实反映系统的就绪状态。

6.1 建立启动预热清单

将连接池、线程池、缓存、配置加载、下游探测等资源初始化纳入统一预热流程。启动完成后，依次执行预热任务，并在预热完成后再将健康检查置为通过状态。

6.2 健康检查应包含关键资源状态

健康检查接口不能仅返回“进程存活”，还应检查下游连接是否可用、缓存是否完成加载、线程池是否创建等关键状态。这样可以避免在系统尚未就绪时接入流量。

6.3 对首批请求进行削峰

如果业务上无法完全避免冷启动流量冲击，可以在流量恢复后的短时间内进行限流或降级，等待核心资源逐步进入稳定状态后再放开。也可以对部分非核心逻辑延迟初始化，避免集中在发布后触发。

6.4 增加发布期线程与 CPU 监控

发布期问题往往持续时间短，常规监控粒度可能不足以捕捉细节。应增加发布期间的线程 dump、CPU 采样和锁竞争指标采集，便于事后回放分析。

七、总结：发布期稳定性需要从“启动即就绪”入手

Java 服务发布后短时间内的超时和 CPU 飙升，往往不是单一原因造成，而是启动未完成、资源懒加载、线程池预热不足、连接建立延迟等多重因素叠加的结果。仅仅延后流量接入时间，并不能解决“系统未真正就绪”这一核心问题。

更有效的做法是：

• 建立明确的启动就绪标准；
• 在健康检查通过前完成关键资源预热；
• 将健康检查与真实可用状态绑定；
• 对发布后的短暂流量冲击进行削峰；
• 保留线程栈、CPU 与锁竞争等排查数据。

通过这些措施，可以把发布期从“故障高发期”转变为“可观测、可控制、可恢复”的稳定过程。对于 Java 服务而言，掌握线程栈分析、资源预热设计和发布期监控方法，是提升线上稳定性的重要能力。