Spring Boot升级后JVM内存过高：AutoConfiguredCompositeMeterRegistry堆积

可能的原因 #

• Actuator Metrics自动配置重复实例化
  Spring Boot 2.5.x版本对Actuator Metrics的自动配置逻辑做了调整，相比2.3.x，AutoConfiguredCompositeMeterRegistry的创建触发条件更敏感。结合Spring Cloud 2020.0.x（Ilford）的组件集成，若项目中存在自定义Metrics配置、第三方组件（如Sleuth）的集成逻辑变化，可能导致上下文初始化或特定事件触发时，重复创建该类实例且未复用单例。

• Sleuth与Micrometer集成兼容性问题
  升级后Spring Cloud Sleuth从2.0.0（对应Boot 2.3）变为3.0.5（对应Cloud 2020.0.5），3.x版本的Sleuth与Micrometer的集成逻辑完全重构。若Sleuth的TraceMetricsAutoConfiguration与Boot的Metrics自动配置存在冲突，可能导致AutoConfiguredCompositeMeterRegistry被多次注册，且因引用链问题无法被GC回收。

• 自定义Metrics配置冲突
  若项目中有自定义MeterRegistry的@Bean定义，在2.3.x版本中可能能正常覆盖默认配置，但2.5.x版本的@ConditionalOnMissingBean条件更严格。如果自定义Bean未标记@Primary，或配置逻辑未适配新的自动配置条件，会导致Spring容器中同时存在多个MeterRegistry实例，AutoConfiguredCompositeMeterRegistry会持续聚合这些实例，最终导致对象堆积。

• Bean生命周期绑定错误
  若AutoConfiguredCompositeMeterRegistry被意外绑定到短生命周期Bean（如request-scoped Bean），或被ThreadLocal、Trace上下文等强引用持有，会导致每次请求或事件触发时创建新实例，且这些实例无法被及时GC回收，最终堆积在堆内存中。

排查建议 #

• 分析堆转储的引用链，确认持有AutoConfiguredCompositeMeterRegistry实例的对象类型，定位是长生命周期Bean、ThreadLocal还是请求级对象导致的引用泄漏。
• 检查项目中的自定义Metrics配置，确认是否存在未标记@Primary的MeterRegistry Bean，或配置逻辑与Boot 2.5.x的自动配置条件冲突。
• 临时禁用Sleuth的Metrics集成（设置spring.sleuth.metrics.enabled=false），观察内存占用是否下降，快速定位是否为Sleuth集成问题。
• 对比Spring Boot 2.3.x与2.5.x的AutoConfiguredCompositeMeterRegistryAutoConfiguration类，查看条件注解（如@ConditionalOnMissingBean）的变化，确认是否因配置条件变更导致重复实例化。

内容的提问来源于stack exchange，提问作者rbn