你的SpringBoot应用在生产环境中是否突然变得缓慢？别急着加机器，先检查那些被多数人当作“默认设置”的角落。性能提升常常不是大刀阔斧的重构，而是从几个微小但致命的选择开始。
连接池：不要只依赖HikariCP的默认配置
大多数SpringBoot开发者都知道HikariCP是目前最快的连接池，却鲜有人真正研究它的配置参数。默认的maximum-pool-size=10在流量高峰时几乎必然成为瓶颈。连接池的核心不在于“够用”，而在于“恰好在临界点之前”。你需要通过压测数据确定合适的连接数，而非经验值。比如，单核CPU下的最佳连接数约等于(核心数2)+1，但I/O密集型应用可以放大到(核心数4)+3。
更隐蔽的问题是连接泄露。如果代码中未正确关闭数据库连接，HikariCP的leakDetectionThreshold参数能帮你自动打印出泄漏的调用栈。开启这个参数（例如设为60000ms）等于给你的数据库连接上了X光机。许多团队在排查“数据库连接池耗尽”时，耗时几周才发现某次异常分支中遗漏了close()操作。
另外，connectionTimeout与idleTimeout的平衡也常被忽视。过长的连接超时会让用户等待卡死，过短又导致频繁重建连接的开销。一个反直觉的实践是：将minimumIdle设为与maximumPoolSize相同，这样池内连接始终保持活跃，避免频繁创建销毁带来的性能毛刺。这在微服务频繁自动扩缩容的场景下尤其显著。
缓存策略：本地缓存不是万能药，但不用一定是错
很多人把Spring Cache注解@Cacheable当作银弹，却从未思考过缓存击穿、穿透和雪崩的三个噩梦。“缓存的第一原则是：不要缓存那些瞬息万变的数据，除非你准备好处理一致性问题。”比如用户会话信息可以本地缓存，但库存数量最好只做分布式缓存+失效重判。
一个被低估的技巧是对热点数据使用两级缓存：一级用Caffeine（内存级，毫秒级响应），二级用Redis（共享级，可持久化）。当Caffeine中的key过期后，不直接请求数据库，而是先检查Redis；只有当Redis也没有时，才触发DB查询并回填两级缓存。这个模式能把99%的读请求拦截在毫秒级内，数据库QPS从数百瞬间降到个位数。
但注意，本地缓存无法感知其他实例的变更。如果多个节点同时修改数据，你需要在写操作后主动清除所有节点的本地缓存。可以用Redis的Pub/Sub发送失效通知，或者牺牲短暂一致性使用固定的TTL。一个常见的性能杀手是：缓存时间设置得过于均匀，导致所有key在同一秒集体失效，请求瞬间打垮数据库。解决办法是给每个缓存key增加随机偏移量（±5%），打散更新压力。
异步处理：别让主线程等网络I/O，但别滥用@Async
SpringBoot内置的@Async注解让异步执行变得简单，但它有一个致命陷阱：默认使用的SimpleAsyncTaskExecutor每次都会创建新线程，在高并发下会迅速耗尽线程资源。你必须替换成线程池，比如ThreadPoolTaskExecutor，并配置核心线程数、最大线程数和队列容量。一个常见的错误是：把异步方法写在同一个类内部，导致@Async失效——Spring AOP的自调用问题，注解不会生效。
更好的做法是将I/O密集型操作独立抽取到CompletableFuture或WebClient中。比如邮件发送、日志上报、外部API调用，这些任务可以并行执行而非串行阻塞。一条黄金法则是：任何超过5ms的I/O操作都应该考虑异步化，除非它必须影响反应结果。
但异步不是越多越好。过度异步会让业务逻辑变得像迷宫，错误处理变得异常困难。关键交易场景（如支付扣款）建议保持同步，否则异步失败后补偿逻辑会极度复杂。用一个反例：某团队将所有Service方法都标记为@Async，结果导致数据库连接池在几秒内被占满，因为每个异步线程都持有数据库连接直至返回——还不如同步。
数据库查询优化：不只是加索引，更要消除N+1与批量处理
Spring Data JPA的懒加载机制是性能杀手之一。当你遍历一个列表的每个元素去访问其关联对象时，N+1查询让数据库瞬间雪崩。解决方案有：使用@EntityGraph或JOIN FETCH显式预加载，或者在Service层用findAllWithAssociations这种自定义方法。一个直观的检查方式是：启用Hibernate的SQL日志（show-sql:true），观察查询数量是否超过预期。
另一个被忽视的是数据库连接的批量操作。默认情况下，JPA的saveAll()会逐条插入，而非真正的batch insert。需要在application.yml中设置spring.jpa.properties.hibernate.jdbc.batch_size=50，并确保启用rewriteBatchedStatements=true（对MySQL尤其重要）。这个改动能让批处理性能提升10倍以上，一条SQL语句携带50条数据发送给数据库，而非50条独立SQL。
此外，分页查询时要警惕COUNT语句的开销。如果数据量极大（例如亿级），可以考虑用SQL_CALC_FOUND_ROWS（MySQL）或count()=1的近似估算，避免每次分页都进行全表计数。更激进的做法是：缓存总记录数，定期更新，或者让前端采用“加载更多”而非分页器，从而完全绕过count。
JVM与部署调优：GC选择与内存配置是最后一道防线
很多人认为SpringBoot应用性能瓶颈在代码层面，但90%的“慢”其实是JVM的Full GC导致的。默认的G1垃圾收集器在高吞吐场景下可能不够好。如果你的应用是响应时间优先（RT敏感），考虑改用ZGC或Shenandoah，它们能将GC停顿时间控制在10ms以内。但要注意：GC调优是权衡的艺术，没有银弹。ZGC会占用更多CPU，如果CPU资源紧张，反而得不偿失。
堆内存配置也常被低估。一个典型错误是：给SpringBoot分配过大的堆空间（比如- Xms8g - Xmx8g），这可能导致GC暂停时间成倍增加。正确做法是：先通过压测找到应用的对象分配速率（每秒产生多少MB），然后确保堆大小能容纳约5-10分钟产生的对象，避免频繁触发老年代回收。建议从- Xms1g - Xmx1g起步，逐渐增加直到GC频率稳定且低延迟。
此外，元空间（Metaspace）溢出是另一个隐藏炸弹。SpringBoot框架本身会加载大量类，加上热部署或动态代理，元空间默认大小可能不够。设置-XX:MaxMetaspaceSize=512m可以防止无限扩张导致OOM。还有一个冷门但有效的JVM参数：-XX:+UseStringDeduplication（G1可用），它会自动合并重复的String对象，对SpringBoot中大量重复的字符串（如JSON key、SQL语句）效果显著，能减少10%-20%的堆内存占用。
连接与线程终局：从监控到自愈
以上五个技巧若全部落地，你的SpringBoot应用性能会有质的飞跃，但不要止步于此。性能优化是一个持续监控的过程，而非一次性手术。引入Micrometer + Prometheus + Grafana，实时监控线程池活跃数、数据库连接池水位、GC暂停时长。遇到突发流量时，能自动触发熔断或降级，比如用Resilience4j装饰异步方法。
最后一个犀利观点：在性能优化中，敢于删除无用的代码比添加优化更重要。很多App里堆积着过时的拦截器、重复的事务注解、没用的@Async调用，它们不仅消耗CPU做无用功，还增加GC压力。定期做代码性能审计，移除无用依赖和处理器，比任何调优都更直接。提升SpringBoot应用性能的终极绝招是——“少做一些事”。当你的代码变得精简、连接配置经过压测、缓存策略覆盖所有热点、异步操作只用在刀刃上、JVM参数经过实测校准，性能自然水到渠成。
请记住：性能优化的瓶颈永远在最短的那块木板，而大多数团队的第一块短板就是“以为默认配置就够了”。现在，就检查你的连接池、缓存、异步方法和JVM参数，让数据告诉你下一步该优化什么。