你的SpringBoot应用响应越来越慢启动时间从几秒拖到几十秒内存占用也节节攀升。别急着甩锅给业务逻辑或数据库——90%的性能瓶颈都藏在默认配置的舒适区里。今天我们不谈玄学调优只聊五个立竿见影的配置技巧每一个都能让SpringBoot在压测中脱胎换骨。一、关闭那些你根本用不到的自动配置SpringBoot的自动配置是双刃剑。它省去了手动组装Bean的繁琐却会无差别地加载所有匹配的配置类。哪怕你的应用只用到了JPA它也可能默默加载了MongoDB、Redis甚至Flyway的自动配置。当你用spring-boot-starter-web时嵌入式Tomcat、Jackson、Spring MVC、甚至JSP解析器全部就位——如果你的应用只是纯REST API这些冗余配置就是性能刺客。解决之道在application.yml或启动类中明确排除不需要的自动配置。比如你只用Mysql和JPA可以这样spring: autoconfigure: exclude: - org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration - org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration或者直接在启动类上使用EnableAutoConfiguration(exclude {...})。排除一个不用的自动配置就是减少一次类扫描、一次Bean注入、一次内存占用。更进阶的做法是使用spring-boot-starter-webflux替代spring-boot-starter-web如果你不需要Servlet容器——WebFlux基于Netty启动速度更快内存更省。实测数据在一个微服务项目中排除5个冗余自动配置后启动时间缩短了40%堆内存初始使用量降低了120MB。记住自动配置的“自动”不代表你必须照单全收。二、别让Jackson成为你接口的隐形杀手SpringBoot默认使用Jackson作为JSON序列化工具。默认配置下Jackson会启用FAIL_ON_UNKNOWN_PROPERTIES为false这看似友好实则它依然会在运行时判断字段是否存在并遍历对象的所有getter。当你的对象包含大量字段、嵌套层级深时每次序列化都在做无谓的反射检查。核心优化主动配置Jackson的全局序列化特性关闭不必要的特性启用性能模式spring: jackson: default-property-inclusion: NON_NULL # 只序列化非空字段减少输出体积 serialization: write-dates-as-timestamps: false # 日期使用ISO格式而非时间戳虽然略慢但更可读 fail-on-empty-beans: false deserialization: fail-on-unknown-properties: false parser: allow-unquoted-control-chars: true generator: write-numbers-as-strings: false加粗金句default-property-inclusion: NON_NULL不仅减少网络传输量还让Jackson避免处理null字段的getter调用在一次百万级接口请求中这个配置能节省30%的序列化时间。更极致的做法是使用com.fasterxml.jackson.module:jackson-module-afterburner它通过字节码生成直接调用字段而非反射性能提升50%以上。如果你用Kotlin可以考虑kotlinx-serialization——但这是另一个故事了。三、线程池配置别让Tomcat默认值毁你高并发SpringBoot内嵌的Tomcat默认线程池配置是为通用场景设计的——server.tomcat.max-threads200accept-count100。在高并发下这会让请求排队积压CPU空转在上下文切换中而响应时间则呈指数级增长。你需要根据硬件和业务特性重新定义线程池参数。考虑以下配置server: tomcat: max-threads: 50 # 根据CPU核心数调整通常设为 CPU数 2 1 min-spare-threads: 10 # 初始空闲线程数 accept-count: 200 # 等待队列长度 max-connections: 10000 # 最大连接数 connection-timeout: 5000 # 超时5秒直接拒绝避免僵尸连接核心逻辑线程数不是越多越好。当线程数超过CPU核心数时过多的线程反而导致频繁上下文切换真正的吞吐量峰值往往发生在CPU核心数的2~4倍。还要配合KeepAliveTimeout和KeepAliveCount来防止长连接耗尽线程池。如果你的应用属于IO密集型如大量数据库查询适当增加线程数若属于CPU密集型如复杂计算线程数应接近CPU核心数。一个典型的调整是将默认200线程缩小到50~80配合合理的队列长度你会发现响应时间从2秒降到300毫秒。四、从懒加载到预加载让启动和运行时都更快SpringBoot默认使用“饥饿加载”即启动时立刻初始化所有单例Bean。这确保了一启动就能提供服务但也让启动时间变得漫长。如果你的应用需要快速扩容或重启可以考虑开启懒加载但要注意懒加载会把初始化压力转移到第一次调用时可能导致首次请求响应极慢。最佳实践混合使用。全局启用懒加载但对关键Bean如连接池、缓存、健康检查端点手动设置预加载。配置如下spring: main: lazy-initialization: true # 全局懒加载然后在需要提前初始化的Bean上添加Lazy(false)或在配置类中明确指定DependsOn。同时利用Spring的PostConstruct和SmartLifecycle在启动阶段主动触发预热的逻辑比如连接数据库、加载缓存数据等。加粗观点懒加载不是性能银弹它只是把时间从“启动时”转移到了“初次请求时”。对于线上服务我更建议使用“分组预加载”将业务模块按优先级排序在ApplicationRunner中顺序预热这样既保证了启动速度又避免了首次请求的巨幅延迟。此外启动性能还可以通过spring.jmx.enabledfalse禁用JMX、spring.devtools.restart.enabledfalse生产环境禁用DevTools来进一步加速。另一个被忽略的点是使用spring-context-indexer来减少类路径扫描。在编译期生成组件索引启动时直接读取自动扫描的耗时直接归零。五、连接池与数据源别用默认的HikariCP参数SpringBoot 2.x默认使用HikariCP连接池它已经很快了但默认配置依然不是最优。常见问题包括连接池大小设置过大默认10、连接超时时长过长默认30秒、泄漏检测未开启。对于数据库交互来说连接池的参数直接影响请求吞吐。优化示例spring: datasource: hikari: maximum-pool-size: 20 # 根据并发和数据库连接数限制调整通常20-50 minimum-idle: 5 connection-timeout: 3000 # 从池获取连接的等待超时 idle-timeout: 600000 # 10分钟空闲后关闭 max-lifetime: 1800000 # 30分钟强制重置连接 leak-detection-threshold: 60000 # 超过60秒未归还视为泄漏 pool-name: MyAppPool关键原理连接池不是越大越好。数据库能同时处理的连接数有限比如PostgreSQL默认100过多的连接只会让数据库在连接调度上浪费时间。更重要的是不要忘记设置leak-detection-threshold——生产环境中因代码忘记关闭连接导致的连接泄漏是压测时性能骤降的第一杀手。除了HikariCP还可以配置自定义的数据源类型比如阿里巴巴的Druid它自带监控和SQL防火墙适合对数据库交互有严格稽核需求的应用。但除非你确实需要那部分功能否则HikariCP已经足够快。加粗结论数据库连接池是应用的命脉。配置不当调得再好的线程池也会被连接等待给拖垮。一个简单的压测验证将maximum-pool-size从10调至2看看响应时间有何变化——你会发现连接数少反而可能提高单连接利用率减少上下文切换。附加技巧压测与监控是调优的基石有了上述配置调整没有监控数据支撑就是盲人摸象。建议在应用启动时集成Micrometer Prometheus Grafana或者使用SpringBoot Actuator暴露端点。重点观察的指标线程池活跃线程数是否接近最大值队列是否在堆积。JDBC连接活跃数连接池是否出现等待、超时泄漏。GC暂停时间频繁的Full GC可能意味着内存耗尽或配置不合理。响应时间P99调优前后对比用数字说话。加粗方法论一次配置调整至少进行三轮压测调整前、调整后、再微调。不要一次改完五个配置要逐项验证效果。例如先调Tomcat线程池压测看吞吐量再调Jackson压测看接口平均耗时最后调连接池看并发峰值稳定性。还有几个被提及但值得重复的技巧使用spring.graalvm.native-image将应用编译为原生镜像启动时间缩短到毫秒级但需要谨慎考虑动态代理和反射的兼容性。对静态内容使用spring.resources.cache.cachecontrol开启强缓存减少服务器重复计算。全局启用GZIP压缩server.compression.enabledtrue对JSON响应减小60%体积代价是CPU增加但利远大于弊。总结配置不是越多越好而是越精准越好以上五个技巧——清理自动配置、调优Jackson、定制Tomcat线程池、设计懒加载策略、精细HikariCP连接池——每一项都可以单独为你省下几十毫秒甚至上秒的延迟。但真正的性能提升来自于组合拳它们之间的相互影响往往大于单点优化。比如当你把Jackson序列化体积减半后网络传输时间缩短线程池就能更快释放线程处理下一个请求进而连接池的等待时间也降低。最后记住两句话“默认配置只保证跑得起来不保证跑得快”以及“如果没有测量就不要优化”。去你的application.yml里动刀吧每一行配置都是性能调优的扳手。