一次线上扩容实验，揭开隐藏在@RefreshScope背后的性能杀手
问题现场：扩容反而引发告警风暴
最近，我们的服务在业务高峰进行一次常规扩容，新增了两个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事件
当Nacos客户端监听到Nacos服务端发生配置变化时AbstractSharedListener被触发：
SpriongCloud的RefreshEventListener监听到RefreshEvent事件在Spring中感知到Nacos的配置变化执行RefreshScope的refreshAll()方法：销毁了被@RefreshScope所标识的所有Bean实例(除非Bean的实例曾经被销毁并且没有被创建)。也就是说：只要有一个配置的key发生变更，所有带有这个注解的Bean都会被销毁而且不会创建新的Bean实例！注意看此方法注释：
当下次请求进来时该Bean会向服务启动时一样拿取最新配置实例化，从而做到了配置热更新。
读写锁
get/destory方法都用了读写锁；并发情况下导致请求都阻塞在等待配置缓存就绪；
源码分析总结
从注解的注释中可以看到
@RefreshScope注解的设计并非是用来做配置热更新，而是在运行时重新初始化新的实例，而且初始化新实例的过程中是阻塞的，所有被注入这个Bean的Service都必须等待RefreshScope注解标识的Bean实例初始化完成。而配置热更新的最佳实践是只更新配置所在的key的属性值即可，而非Bean实体，甚至是业务Bean实体，因为通常情况下，Bean的实例默认是单例，运行时更新业务Bean实体(比如Controller、Service)代价非常高；
RefreshScope的实现逻辑：
get/destory方法都用了读写锁；并发情况下导致请求都阻塞在等待配置缓存就绪；- 启动时实例化机制：是在
ContextRefreshedEvent事件发布后才会触发所标识的Bean的实例化(lazyinit)； - 运行时实例化机制：如果Nacos配置变更，只是过期当前缓存，也不会立刻刷新最新配置项；要等到下次请求/调用才会销毁当前实例对象，通过CGLIG代理创建新的对象并获取最新配置。
真相大白：两个问题的根因
| 问题现象 | 根本原因 |
|---|---|
| 启动后接口响应慢 | @RefreshScope懒加载 + 读写锁，导致流量进入时Bean还未初始化，请求串行等待。 |
| 启动后频繁Full GC | 请求大量阻塞，临时对象无法及时释放，内存水位飙升触发频繁GC。 |
| 运行时配置变更也卡顿 | refreshAll销毁所有Bean，下次请求重走初始化锁流程，同样阻塞。 |
一句话总结：@RefreshScope根本不是为配置热更新设计的，它是个“重型”运行时Bean重建机制。把它当配置刷新工具，就是拿大炮打蚊子，还把自己人炸了。
正确的“优雅启动”姿势
问题找到了，解决方案也很明确：
使用@ConfigurationProperties作为配置类实现自动更新属性。
具体改造步骤：
- 剥离配置：将散落在各处的
@RefreshScope从业务Bean上移除，统一收拢到XxxProperties配置类中。 - 配置类加注解：在配置Properties类上增加
@ConfigurationProperties。 - 业务Bean正常注入：其他Bean通过注入Properties对象，Properties内部属性变更时，业务Bean无需重建，直接拿到新值。
经过上述改造，我们重新进行扩容以及重启实验：
- 启动后接口耗时恢复为毫秒级，再无P1超时告警；
- Full GC次数回归正常水平；
- 运行时发布配置也不再引发任何抖动。
写在最后
技术没有银弹，但很多“知名”框架的特性容易被误用。@RefreshScope本身没有错，错的是我们把它的使用场景理解错了。
如果你的线上服务也遇到扩容即超时、启动即Full GC、配置发布就报警的怪象，不妨检查一下项目里是不是到处飘着@RefreshScope。
优雅启动，从告别滥用RefreshScope开始。
📢 你的项目里还在滥用@RefreshScope吗？欢迎留言分享你踩过的坑。