一次内存泄漏排查，把我逼到了字节码层面
上周四凌晨三点，生产环境突然开始疯狂 Full GC，然后就是雪崩式的服务不可用。我们查了俩小时死活找不到原因，最后我鬼使神差地把 dump 文件扔进 JProfiler，才发现Spring Boot 内置的 Tomcat 竟然悄悄把请求参数缓存到了堆里，而且没设上限——说出来都丢人，就这个问题，让我们一个日均 PV 过亿的接口挂了整整 18 分钟。
这事促使我重新审视 Spring Boot。说实话，这玩意儿我们用了快五年，自以为了如指掌，结果连最基本的自动配置到底在干嘛都说不清楚。多数人只知道 @SpringBootApplication 是个组合注解，知道它背后有 @EnableAutoConfiguration，但再往下呢？自动配置类的筛选逻辑、条件装配的匹配算法、以及那该死的 spring.factories 加载机制，这些才是真正决定你应用生死的东西。
我给你捋一捋。当 Spring Boot 启动时，它会从 META-INF/spring.factories 文件中读取所有的自动配置类全限定名，注意是所有，一个 Starter 可能带进来几十个配置类。然后针对每个配置类，用 ConditionalOnClass、ConditionalOnBean 这些注解上的条件去匹配——这个过程叫做条件装配。但关键是，匹配不是一次性全做完的，而是嵌在整个 Bean 的创建生命周期里。Spring Boot 底层用的是 Spring Framework 的 ConfigurationClassParser，它用一个递归的解析器去处理 @Import 和这些条件注解，内部有个不小的 if-else 森林。最要命的是，条件匹配用到了 org.springframework.boot.autoconfigure.condition.ConditionEvaluator，它会反射调用那些 OnClassCondition、OnBeanCondition 的 matches 方法，而且每次调用都会生成一个 ConditionOutcome 对象记录下来。我遇到的那次内存泄漏，就是因为某个自定义的 Condition 没写好，导致每次匹配都留一个强引用，随着热重启次数增加，老年代差点被撑爆。
内嵌容器到底快在哪儿？一组对比数据
去年公司技术委员会有人拍桌子说：Spring Boot 就是花架子，内嵌 Tomcat 吞吐量肯定比不上独立部署的 Tomcat。我当场没反驳，回来默默搭了两套环境测了一把。结果很有意思——先交代机器配置：AWS c5.2xlarge，8核16G，同一台机器的不同端口，JDK11，压测工具 wrk，连接数 200，持续 60 秒。
传统 Spring MVC 项目打成 war 丢进独立 Tomcat 9，最佳线程数配到 200 时 QPS 是 12400 左右，而且 CPU 使用率飙到 85%，线程堆栈里大量 BLOCKED。换成 Spring Boot 2.3.2 + 内嵌 Tomcat 默认配置，QPS 直接跑到 21500，CPU 才 60%。为什么？因为传统 Tomcat 的线程模型太老实了，一个请求一个线程，处理完才归还，阻塞 IO 一多，线程池迅速耗尽，后面排队。而 Spring Boot 内嵌模式默认启用了 NIO 连接器，再配合 Servlet 3.1 的非阻塞特性，虽然还不是真正的响应式，但它对连接和请求做了分离处理，线程只负责处理耗时短的业务逻辑，IO 等待扔给了内核。不过，这里有个天大的误会：很多人都以为内嵌 Tomcat 就是速度的代名词，但如果你直接在 Spring Boot 里把 server.tomcat.threads.max 调大、把 accept-count 调高，性能反而会断崖式下跌——因为线程上下文切换的成本超过了收益。压测中最优值往往在 40 到 80 之间，具体看业务。
再说个反直觉的数字：我们有个日志托管服务，用 Spring Boot 默认的线程池跑了半年，平均延迟一直在 200ms 左右，后来我把 max 改小到 50，反而降到 80ms。原因是排队比线程切换更高效。这背后的数学其实就是利特尔法则的变体：L = λW，但加了上下文切换开销后，非线性变化剧烈。所以别再迷信“线程越多越好”了，也别被 Spring Boot 的简单配置骗了——它简单并不意味着你可以无脑用。
三个把你坑哭的陷阱
陷阱一：循环依赖的幽灵
Spring Boot 2.6 之后默认禁止了循环依赖，好多人在升级时直接傻眼。我以前遇到一个案例：订单服务依赖用户服务，用户服务又引用订单的某个 DTO，两个类都用 @Autowired 注入对方，启动就报 BeanCurrentlyInCreationException。网上一堆教程教人开启 spring.main.allow-circular-references=true，千万别！这是饮鸩止渴。真正该做的是用 @Lazy 打破循环，或者更彻底地，把双向依赖改成事件驱动——你想想，为什么订单模块非得在初始化时拿到用户模块的引用？发个事件不行吗？设计上的问题别用配置掩盖。
陷阱二：类路径上的定时炸弹
因为 spring.factories 会加载所有 Starter 里的配置类，所以类冲突防不胜防。上个月我们有个项目引入了一个第三方 Excel 组件，那玩意内部带了旧版的 commons-lang，结果把系统里新版的一个工具类覆盖了，导致一个很远的模块报 NoSuchMethodError。排查了两天，最后用 Maven helper 插件一看依赖树，满屏红色冲突。解决办法很简单粗暴：在 Maven 的 dependencyManagement 里统一管理版本，或者用 exclusion 排除传递依赖。不过我最推荐的还是用 mvn dependency:tree 配合 conflict 标记做 CI 检查，一开始就拦住。
陷阱三：默认连接池的沉默暴击
HikariCP 是 Spring Boot 2.x 的默认连接池，号称光速，但它的 connection-timeout 默认是 30000 毫秒。你知道这在高并发下意味着什么吗？一旦数据库出现瞬间抖动，所有等待连接的线程会堵住 30 秒才超时，然后 Tomcat 线程池跟着一起堵，雪崩就这么来了。我们线上曾因为一个慢 SQL 把连接池耗尽，Hikari 硬等了 30 秒，导致上游调用方大面积报 502。现在我把这个值调到了 2000ms，并且配合 maximumPoolSize 的合理设置——通常是 CPU 核心数*2 + 硬盘数，但具体还得用 JMeter 压出连接等待分布来校准。
工程美感和那句脏话
Spring Boot 的设计确实有美感。它把“约定大于配置”做到了极简，自动装配的本质是一套基于条件的动态拼装系统，就像乐高积木，只要你在类路径上放了正确的东西，它就能自动拼出你想要的对象图。这种设计减少了 80% 的配置工作量，但代价就是把复杂性转移到了启动阶段和隐式规则里。可悲的是，一堆人学了三天 Spring Boot 就敢上生产，遇到问题只会加配置、搜百度，不愿去翻源码。我经常在半夜一边修 bug 一边骂，但骂完了还是得承认——这破玩意儿，真香。
