SpringBoot自动配置差点让我加班到凌晨

周五晚上10点，预发布环境突然报警：新上线的支付服务频繁Full GC。监控显示堆内存以每秒50MB的速度泄漏，离上线截止时间只剩2小时。而这一切的罪魁祸首，居然是SpringBoot自动配置中一个隐蔽的@Conditional条件。

现象：无伤大雅的依赖引发内存泄漏

问题出现在一个日均交易量2000万+的支付系统中。我在本地启动服务时一切正常，但预发布环境刚跑完流量回放测试就OOM。通过jmap -histo抓取堆内存快照，发现近80%的内存被TomcatURLStreamHandlerFactory的静态Map占用------这个类明明和我们的业务代码毫无关联！

java 复制代码

// 堆内存分析结果片段
num     #instances         #bytes  class name
1:      2587921      1254785920  [Ljava.util.HashMap$Node;
2:      2587904      828134912   org.apache.tomcat.util.collections.ConcurrentCache$1

根因：被忽视的自动装配链条

*根本原因是SpringBoot自动装配的"多米诺骨牌效应"**：

新引入的第三方支付SDK依赖了org.apache.tomcat:embed-core（虽然我们用的是Undertow）
SpringBoot的ServletWebServerFactoryAutoConfiguration检测到classpath存在Tomcat类
该配置类通过@ConditionalOnClass触发了Tomcat相关Bean的初始化
TomcatURLStreamHandlerFactory在初始化时会注册JVM级别的URL协议处理器，且无法卸载

关键问题在于：@ConditionalOnClass只检查类是否存在，而不管是否真的需要它 。哪怕你显式配置了server.servlet=undertow，只要Tomcat的jar在classpath上，这套机制就会启动。

解决：用"排除法"精准控制自动配置

正确解法是在@SpringBootApplication中排除特定自动配置类：

java 复制代码

// 错误：只排除Tomcat依赖还不够
implementation('com.payment:sdk') {
    exclude group: 'org.apache.tomcat', module: 'embed-core'
}

// 正确：必须显式关闭自动配置
@SpringBootApplication(exclude = {
    ServletWebServerFactoryAutoConfiguration.class,
    TomcatServletWebServerFactory.class
})

性能对比*：排除前JVM启动后常驻内存增加约200MB（Tomcat线程池+协议处理器），排除后回归正常水平。

深度排查：如何锁定隐藏的自动配置

遇到类似问题可以用这些手段诊断：

查看生效的自动配置：

bash 复制代码

# 启动时添加debug参数
java -jar your-app.jar --debug

# 在日志中搜索"Positive matches"
Positive matches:
   ServletWebServerFactoryAutoConfiguration matched:
      - @ConditionalOnClass found required classes 'javax.servlet.Servlet', 'org.springframework.web.servlet.DispatcherServlet' (OnClassCondition)

依赖树分析：

bash 复制代码

# 找出是谁引入了Tomcat
gradle dependencies --configuration runtimeClasspath | grep tomcat

避坑清单：自动配置的黑暗森林法则

依赖冲突的连锁反应

即使你不用Tomcat，只要它的jar存在于classpath，相关自动配置就可能被激活。建议用gradle dependencyInsight定期检查冗余依赖。
条件注解的"近视眼"问题

@ConditionalOnClass就像个开关------它只关心"能不能开"，不关心"该不该开"。遇到Bean冲突时优先考虑@AutoConfigureBefore调整顺序。
测试环境与生产环境的差异陷阱

本地用spring-boot-starter-web没发现问题？生产环境可能因为多了个spring-boot-starter-data-rest触发完全不同的配置路径。永远在类生产环境测试内存占用。
第三方库的"悄悄话"

有些库会通过META-INF/spring.factories注册自己的自动配置，比如某著名消息队列SDK会偷偷初始化连接池。用--debug参数抓出这些"幕后黑手"。

结语

SpringBoot自动配置就像自动驾驶------平时让你省心，但一旦出问题就是惊天动地。我的血泪教训是：永远对@Conditional保持怀疑，在POM文件里装个"雷达"。

你们团队有没有遇到过更诡异的自动配置问题？欢迎在评论区分享你的"惊魂夜"故事。