Java应用启动慢、接口超时、频繁Full GC？别再把锅甩给JVM了！

问题现场：扩容反而引发告警风暴

最近，我们的服务在业务高峰进行一次常规扩容，新增了两个POD。本以为能平滑分担流量，结果启动后不久，P1级别接口超时告警和频繁Full GC告警接连爆发。

从监控图可以清晰看到：

• 新启动的POD在刚接收流量的前几分钟，接口平均耗时飙升到秒级；
• JVM的Full GC次数陡增，Old区几乎被打满；
• 运行几分钟后，一切又逐渐恢复正常。

这种现象并非第一次出现，应用启动时也会出现类似的现象。扩容或者重启变成“陪葬”，到底是谁在作祟？

结论先行：@RefreshScope的滥用

团队没有止步于表象，而是深入Spring Cloud源码，并结合Demo进行复现，最终锁定了“真凶”——@RefreshScopel滥用。

@RefreshScope的初始化“陷阱”

在我们的应用中，大量Controller、Service类上都标注了@RefreshScope，初衷是为了实现Nacos配置的热更新。然而，这个注解的初始化行为却暗藏玄机：

• 普通Bean：在Web容器初始化完成之前实例化，服务注册到Nacos时，所有依赖都已就绪。
• @RefreshScope Bean：采用懒加载模式，它要等到ContextRefreshedEvent事件（该事件发生在Web容器初始化之后）才会触发实例化。

也就是说，当Nacos完成服务注册、上游流量开始涌向新POD时，被@RefreshScope修饰的那些Bean（包括Controller、Service）可能根本还没创建完成！

锁粒度惊人：读写锁阻塞所有请求

翻看RefreshScope的源码，发现它的get()和destroy()方法都使用了读写锁。当请求并发进入时，大量线程需要等待锁释放，等到Bean实例化完成才能继续。

这个锁的粒度是整个Scope级别，相当于把一个Controller里所有接口、甚至多个Service都串行化了。启动瞬间的高并发，直接导致请求排队、响应超时。

运行时配置变更也是“定时炸弹”

你以为只在启动时卡？太天真了。

当Nacos配置发生变更时，RefreshScope会执行refreshAll()——销毁所有被@RefreshScope标注的Bean实例，但并不立即重建。等到下一次请求进来时，再走一遍加锁、实例化的重流程。于是，每次配置发布，都可能引发新一轮的请求阻塞和P1告警。

抽丝剥茧：源码分析

RefreshScope注解Bean初始化

SpringCloud提供的服务注册抽象类AbstractAutoServiceRegistration通过监听Web容器的初始化完成事件注册服务，注册中心客户端(不限于Nacos)实现这个抽象类就会在 Web容器初始化完成后向注册中心注册服务。

Nacos的服务注册NacosAutoServiceRegistration实现了这个抽象类 ，所以Nacos客户端会在Web容器初始化完成后注册服务 。

业务Bean的实例化过程分为两类

• 没有@RefreshScope修饰的Bean初始化过程

初始化完成后，在onRefresh()方法中初始化Web容器Bean

容器Ben初始化完成，发布容器初始化完成事件：ServletWebServerInitializedEvent,ServletWebServerInitializedEvent继承自WebServerInitializedEvent事件，此后Nacos客户端注册服务

• 被@RefreshScope修饰的Bean初始化过程
  被@RefreshScope修饰的Bean使用RefreshScope类监听ContextRefreshedEvent事件初始化Bean

ContextRefreshedEvent事件发生在WebServerInitializedEvent之后，此时初始化Bean时，服务已经被注册到注册中心，请求已经进来，但Bean还在初始化中，造成服务启动时接口响应慢、GC异常

RefreschScope注解Bean实现配置热更新

在上面的源码分析中知道@RefreshScope修饰的Bean使用RefreshScope类监听ContextRefreshedEvent事件初始化Bean，那它是如何做到热更新配置的？Nacos的配置中心Client类NacosContextRefresher在Spring容器发布ApplicationReadyEvent事件时预注册了一个AbstractSharedListener

在AbstractSharedListener的中发布RefreshEvent事件