一文搞懂SpringBoot的核心概念上周排查一个线上问题时，发现SpringBoot应用在流量突增时频繁Full GC

上周排查一个线上问题时，发现SpringBoot应用在流量突增时频繁Full GC，最终定位到是自动配置的Tomcat线程池配置不合理。你有没有遇到过类似问题？为什么一个看似简单的spring-boot-starter-web依赖，在高压下会暴露出这么多隐藏问题？今天我们就从这次事故出发，聊聊SpringBoot那些你必须掌握的"核心套路"。

1. 自动配置：你以为的便利，可能是定时炸弹

场景*：某次大促期间，订单服务QPS从200暴涨到3000，应用响应时间从50ms飙升到2s以上，最终因频繁Full GC导致服务不可用。
根因*：SpringBoot默认的Tomcat线程池配置（server.tomcat.threads.max=200）在大流量下成为瓶颈，请求堆积导致内存暴涨。更致命的是，我们误以为引入了spring-boot-starter-web就会自动适配生产环境，实际上它的默认配置只适合开发环境。

// 错误示范：完全依赖默认配置
@SpringBootApplication
public class OrderApp { ... }

// 正确姿势：显式调整关键参数
@Bean
public TomcatServletWebServerFactory tomcatFactory() {
    TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
    factory.addConnectorCustomizers(connector -> {
        ProtocolHandler handler = connector.getProtocolHandler();
        if (handler instanceof Http11NioProtocol) {
            Http11NioProtocol protocol = (Http11NioProtocol) handler;
            protocol.setMaxConnections(10000);
            protocol.setMaxThreads(500);
            protocol.setAcceptCount(1000); // 关键：队列长度
        }
    });
    return factory;
}

性能对比*：

默认配置（max=200）：QPS 3000时，99线响应时间 2.1s
优化后（max=500）：99线降至 320ms

避坑清单*：

线程池参数（maxThreads/acceptCount）必须随宿主机器CPU核数调整（建议公式：maxThreads = CPU核数 * 2 + 预留buffer）
永远不要使用server.tomcat.threads.min-spare（可能引发线程泄露）
警惕spring.main.lazy-initialization=true与Tomcat的兼容性问题

2. 条件装配：你的@Bean为什么没生效？

场景*：在数据迁移工具中新增了MongoDB支持，明明添加了@Configuration和@Bean，运行时却提示MongoTemplate not found。
根因*：SpringBoot的条件装配（@Conditional）机制在起作用。当你同时引入Redis和MongoDB时，如果误用@ConditionalOnClass，可能导致Bean加载顺序不符合预期：

// 错误写法：依赖类存在性判断
@Configuration
@ConditionalOnClass(MongoClient.class) // 只检查类是否存在
public class MongoConfig { ... }

// 正确写法：结合属性配置判断
@Configuration
@ConditionalOnClass(MongoClient.class)
@ConditionalOnProperty(prefix = "spring.data.mongodb", name = "uri")
public class MongoConfig {
    @Bean
    @ConditionalOnMissingBean // 避免重复创建
    public MongoTemplate mongoTemplate(MongoClient client) {
        return new MongoTemplate(client, "order_db");
    }
}

关键机制*：

@Conditional系列注解的检查顺序由AutoConfigureOrder控制
spring-autoconfigure-metadata.properties中的exclusions会覆盖你的显示定义

3. 配置优先级：你确定你知道最终生效的值？

场景*：在K8s环境中，应用读取到的spring.datasource.url始终不是预期的值，尽管你在三个地方都做了配置。
根因*：SpringBoot的配置源优先级常常被低估。以下是实测的优先级链（从高到低）：

命令行参数（--spring.datasource.url=jdbc:mysql://primary）
JNDI属性
Java系统属性（System.getProperties()）
操作系统环境变量（全大写+下划线格式，如SPRING_DATASOURCE_URL）
application-{profile}.yml
application.yml
@PropertySource注解

典型误区*：

以为application.yml中的prod profile会覆盖application-prod.yml（实际相反）
在K8s中同时使用ConfigMap和环境变量时，环境变量优先级更高

4. 健康检查：你的/actuator/health真的可靠吗？

事故还原*：某次数据库主从切换后，虽然/actuator/health显示UP，但实际业务SQL全部失败。原因是：

# 错误配置：默认只检查连接池
management:
  endpoint:
    health:
      show-details: never
  health:
    db:
      enabled: true # 仅验证连接池

# 生产级配置
management:
  health:
    db:
      enabled: true
      query: SELECT 1 FROM orders LIMIT 1 # 真实业务表检查
    diskspace:
      threshold: 10MB
    readinessstate:
      enabled: true # 区分就绪/存活状态

最佳实践*：

对MySQL/Oracle等关键组件，必须配置自定义查询语句
使用ReadinessStateHealthIndicator实现分级下线
警惕HealthIndicator的阻塞调用（建议超时设置）

5. 启动速度：为什么你的应用启动要30秒？

优化案例*：一个包含20个微服务的系统，通过以下调整将平均启动时间从28s降至9s：

组件扫描杀手：

// 致命陷阱：全包扫描
@SpringBootApplication // 默认扫描同级所有包
public class App { ... }

// 正确姿势：限定范围
@SpringBootApplication(scanBasePackages = "com.your.business")

延迟初始化代价：

# 虽然启动快了，但可能引发运行时雪崩
spring.main.lazy-initialization: true 

# 折中方案：仅lazy特定Bean
@Lazy
@Service
public class HeavyService { ... }

版本陷阱：

SpringBoot 2.3+ 才支持spring.config.import的惰性加载
低于2.4版本在加载大量PropertySource时存在性能瓶颈

写在最后

SpringBoot的"约定优于配置"是把双刃剑：新手觉得开箱即用，但老手必须穿透表象掌握其决策机制。记住一个铁律：生产环境永远不要完全信任默认配置。

你在项目中还遇到过哪些SpringBoot的"暗坑"？欢迎在评论区分享你的实战经验。