你的Spring Boot应用在线上突然“卡顿”接口响应时间从毫秒级飙升到秒级CPU和内存占用居高不下。别急着甩锅给硬件或网络90%的性能瓶颈其实都藏在代码和配置的细节里。Spring Boot开箱即用的特性让我们习惯了“拿来主义”但真正要让应用跑得飞快必须对每个关键环节进行手术刀式的优化。下面这十个实用技巧每一个都是我在生产环境中反复验证过的“止血方案”。连接池别让数据库连接成为你的死穴很多新手直接使用Spring Boot默认的HikariCP连接池觉得“够用了”。但默认的maximumPoolSize10对高并发场景简直是灾难。想象一下100个请求同时涌入只有10个连接可用其余90个只能排队等待。更隐蔽的问题是连接池太小会导致频繁创建和销毁连接而数据库端也会有最大连接限制。实战优化方案根据你的并发量和数据库类型调整参数。对于MySQL建议maximumPoolSize不超过(CPU核心数 2) 1比如4核CPU设为9。同时设置connectionTimeout3000030秒超时防止请求无限等待。另外强烈建议开启leakDetectionThreshold比如设置为60000ms一旦连接泄露超过60秒未归还HikariCP会自动打印堆栈跟踪——这能帮你快速定位未关闭的Connection。spring: datasource: hikari: maximum-pool-size: 18 connection-timeout: 30000 leak-detection-threshold: 60000 pool-name: MyPool注意不要盲目增大连接数过多的连接反而会增加数据库锁竞争和上下文切换。连接池的核心价值不是“多”而是“快”——快速获取、快速释放。缓存从高频查询中榨取毫秒级响应业务系统里总有一些数据“万年不变”比如国家列表、商品分类、系统配置。每次请求都去查数据库就是典型的资源浪费。Spring Boot对缓存的支持极其优雅一个Cacheable注解就能搞定本地缓存或Redis。但很多人踩过这样的坑缓存穿透——查询一个根本不存在的数据导致每次都要穿透到数据库。解决方案是缓存空值null值并设置较短的过期时间。更致命的是一级缓存与二级缓存的数据一致性问题。如果你用Redis做分布式缓存同时又用Caffeine做本地缓存更新操作必须同时失效所有节点的本地缓存。推荐组合读多写少场景用Caffeine作为一级缓存堆内Redis作为二级缓存分布式。配置时注意设置合理的过期时间TTL避免缓存雪崩——可以给不同key设置随机偏移量。启用Cacheable的sync true防止缓存击穿热点key重建时加锁。使用CacheEvict时务必指定allEntries true来清空所有相关缓存如果业务允许。代码示例Cacheable(value user, key #id, sync true) public User getUserById(Long id) { // 数据库查询 return userMapper.selectByPrimaryKey(id); }性能提升立竿见影一个QPS 1000的查询接口加缓存后CPU占用能下降60%以上。异步处理把“慢操作”踢出主线程文件上传、发送邮件、生成报表——这些耗时的操作如果同步执行用户的请求会被活活“拖死”。Spring Boot的Async注解让异步变得极其简单但很多人只加了注解却没配置线程池导致默认的SimpleAsyncTaskExecutor为每个任务创建新线程最终引发内存溢出。正确做法自定义一个线程池并设置合适的核心线程数、最大线程数、队列容量和拒绝策略。对于IO密集型任务如发短信建议核心线程数 CPU核心数 2对于CPU密集型任务如加密核心线程数 CPU核心数。同时一定要定义明确的拒绝策略比如CallerRunsPolicy让主线程自己执行防止任务丢失。Configuration EnableAsync public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }注意事务问题异步方法默认会被独立出当前事务如果你需要保证一致性要么把异步调用放在事务提交之后要么使用Transactional(propagation Propagation.REQUIRES_NEW)手动管理。一种更优雅的做法是使用事件驱动先提交事务再发布事件监听器处理异步任务。压缩传输让网络带宽发挥10倍效率如果你的API返回的是JSON尤其是包含大量文本或列表数据网络传输时间可能占据接口总耗时的70%以上。开启HTTP压缩gzip或brotli能瞬间将响应体积压缩80%。但很多人在Spring Boot中只配置了server.compression.enabledtrue这是不够的——默认只压缩超过2KB的响应且MIME类型只包含text/html等少数几种。强化配置server: compression: enabled: true min-response-size: 1024 # 降低阈值1KB就开始压缩 mime-types: application/json,application/xml,text/html,text/plain更进阶的技巧是使用ResponseBody配合自定义压缩过滤器或者对静态资源开启预压缩.gz文件。但要注意压缩会增加CPU消耗对于纯内网通信可以关闭压缩对于公网API务必开启并监控CPU使用率。还有一个容易被忽略的点如果前端也在做解压缩记得确认它们支持gzip。大多数现代浏览器和HTTP客户端都支持但老旧系统可能需要兜底。数据库索引一个字段可能让查询快100倍你加了SpringBootApplication用JPA自动生成表结果上生产后一个简单查询跑了10秒。不用怀疑肯定是索引缺失。Spring Boot默认的ddl-auto配置如update不会帮你创建高效索引在开发阶段就应该把索引设计纳入数据库脚本中。核心原则为WHERE、ORDER BY、GROUP BY涉及的列建立索引。联合索引遵循“最左前缀”原则比如(a, b, c)可以匹配a、a,b、a,b,c但无法匹配b,c。不要在索引列上使用函数例如WHERE DATE(create_time) 2023-01-01会导致索引失效应该用范围查询create_time ? AND create_time ?。实际案例一个订单查询接口过滤条件包括status、create_time、user_id。之前没索引全表扫描耗时8秒建立联合索引(user_id, status, create_time)后耗时降到20毫秒。索引优化是成本最低的“核武器”。推荐做法用Table(indexes ...)在实体上声明索引或者直接在schema.sql中定义。对于JPA的懒加载查询确保关联字段有索引否则会产生N1问题带来的额外性能损耗。JVM调优让垃圾回收不再“拖后腿”很多人觉得JVM调优是运维的事但错误的GC策略会让Spring Boot应用频繁“世界停顿”。默认的G1 GC虽然自适应但遇到大量对象的短期创建比如瞬时请求对象依然可能发生Full GC。关键参数-Xms和-Xmx设置为相同的值避免动态扩容开销。对于Spring Boot应用建议根据内存实际用量设置比如4GB堆。-XX:UseG1GC大多数场景下G1优于ParallelGC。-XX:MaxGCPauseMillis200期望最大停顿时间但不要设得太低否则G1会频繁执行垃圾回收。-XX:MetaspaceSize256m元空间初始大小防止频繁扩容。开启-XX:PrintGCDetails和-XX:PrintGCDateStamps通过日志观察GC频率和时长。如果年轻代GC频繁且耗时较长可以调大-XX:G1NewSizePercent。一个典型错误把堆内存设得过大比如16GB但物理内存只有16GB导致操作系统大量使用交换分区swap性能急剧下降。堆内存不要超过物理内存的80%并预留给操作系统、线程栈和直接内存。最佳实践使用-Xlog:gc:filegc.log:time,level,tagsJDK9记录GC日志配合GCEasy等工具分析。定期检查老年代占用率如果持续缓慢增长说明存在内存泄露或对象被误引用。线程池与协程从“等”到“并”的跨越除了异步任务的线程池Web服务器Tomcat、Jetty本身也依赖线程池。Spring Boot默认的Tomcat max-threads200看似不少但在高并发下每个请求都会占用一个线程。如果请求中存在IO阻塞如HTTP call、数据库查询线程会一直“睡着”导致线程池迅速耗尽。两个方向优化增加Tomcat线程数根据你的响应时间公式是max-threads 目标QPS × 平均响应时间(秒)。例如目标是1000 QPS平均响应200ms则需200个线程。但注意线程数增加会带来上下文切换开销不要超过CPU核心数的10倍。采用异步Servlet或WebFluxSpring WebFlux基于Reactor的响应式模型用少量线程处理大量请求。关键点如果业务代码中存在阻塞调用如JDBCWebFlux会阻塞其工作线程得不偿失。所以纯响应式JDBC如R2DBC才能发挥WebFlux优势。一个更轻量的选择JDK21的虚拟线程Project Loom。开启方式Spring Boot 3.2配置spring.threads.virtual.enabledtrue。虚拟线程非常轻量可以创建百万级适合IO密集场景。注意使用虚拟线程时java.util.concurrent中的ReentrantLock、synchronized等会锁定载体线程导致性能下降应优先使用支持虚拟线程的同步机制如Semaphore、CompletableFuture。依赖瘦身与懒加载摒弃“不需要的”负担很多Spring Boot项目在pom.xml里乱加依赖比如spring-boot-starter-web会默认引入Tomcat和Jackson但你的项目可能用Undertow配Gson。每个多余的Jar包都会增加类加载时间、内存占用和启动时间。技巧使用spring-boot-maven-plugin的excludes移除不需要的自动配置。开启Spring Boot的懒加载spring.main.lazy-initializationtrue这样所有Bean会在首次被调用时才初始化。对大型项目启动时间能从30秒降到5秒但注意这会导致第一个请求变慢可以配合预热机制如PostConstruct中的预热缓存。使用spring-boot-starter-undertow代替TomcatUndertow的吞吐量更高内存更低。删除不需要的Spring Boot starter比如如果没有使用JPA就不要引入spring-boot-starter-data-jpa。终极武器Spring NativeGraalVM——将Spring Boot应用编译成二进制可执行文件启动时间缩短到毫秒级内存占用降低50%。但有两个坑需要大量反射配置且一些库如某些JDBC驱动不支持。适合微服务和无服务器场景。数据库查询从ORM的“甜蜜陷阱”里爬出来JPA和MyBatis-plus的便利性让我们忍不住滥用findAll和updateById。但每次查询都select每次更新都update所有字段性能差是必然的。更可怕的是N1问题查询一个用户列表时每个用户又去数据库查询其订单。优化方法强制指定返回字段使用JPA的EntityManager.createNativeQuery或MyBatis的ResultMap只select需要的列。例如SELECT id, name FROM user而不是SELECT。使用BatchSize在OneToMany或ManyToMany关系上加BatchSize(size 10)批量加载子实体避免N1。开启SQL日志spring.jpa.show-sqltrue并配合logging.level.org.hibernate.SQLDEBUG观察实际的SQL语句。避免使用JOIN查询关联太多的表超过3张表的JOIN考虑用缓存或冗余字段。一个真实教训一个报表接口使用了JPA的findAll然后循环调用20次其他查询总共发了21条SQL。改成手动编写原生SQL的LEFT JOIN后发了一条SQL接口耗时从3秒降到80毫秒。监控与诊断没有度量就没有优化最后一个技巧不需要改代码但可能是最重要的——建立完善的性能监控体系。没有数据支撑所有优化都是“盲人摸象”。Spring Boot Actuator配合Micrometer能暴露大量指标但很多人只配了/health和/info。实战配置management: endpoints: web: exposure: include: # 暴露所有端点生产环境谨慎 metrics: export: prometheus: enabled: true # 集成Prometheus然后安装Prometheus Grafana导入Spring Boot Dashboard模板如ID 12900。重点关注以下指标JVM内存堆内存使用率、老年代占用率、GC次数和耗时。Tomcat线程活跃线程数、最大线程数、队列长度。如果活跃线程接近最大线程数说明系统负载高。数据库连接池活跃连接数、等待获取连接的平均时间。如果等待时间超过100ms说明连接池太小。接口响应时间P99、P90、平均耗时。P99超过500ms就需要警惕。快速定位线上问题配合ArthasAlibaba开源诊断工具实时查看方法耗时、线程堆栈、甚至修改日志级别。一个简单的watch命令就能揪出慢方法的调用链。优化没有尽头但每个技巧都能带来立竿见影的改变。从连接池到JVM从缓存到线程模型你每“折腾”一次应用就离“丝滑”更近一步。别怕动手生产环境的每一次降级文档都是你下一次优化的起点。