每次看到Spring Boot性能提升这个关键词我都想先反问你一句你测过自己的接口到底慢在哪吗我见过太多团队上来就调JVM参数、换框架、上微服务结果压测数据纹丝不动。这篇文章我想用自己真实压测过的案例聊透一套能让接口响应时间下降80%甚至更多的组合打法。标题里的核武器不是玄学而是Caffeine本地缓存、连接池调优、JVM参数、压缩传输这几个手段叠加后的真实效果。适合正在做Spring Boot项目、被接口性能折腾过的后端开发也适合刚入门但想走对方向的同学。我先说一个真实案例一个订单管理后台的列表接口TP99稳定在900ms左右数据库连接池耗尽CPU时常飙到80%。通过Actuator和Arthas定位到是三个表的关联查询没有走索引再加上原来每次请求都重复查询同一批热点数据。之后加联合索引、只查询必要字段、引入Caffeine缓存热点商品信息、调整HikariCP连接池和Tomcat线程数再开启Gzip压缩最终压测TP99降到180ms吞吐量翻了接近5倍。整个过程没有动任何业务架构完全是在Spring Boot的合理配置范围内做文章。所以这篇不是科普Spring Boot怎么启动而是实打实的性能优化操作指南。我会把测量、缓存、JVM、容器、数据库、异步化这些方向逐个拆开每一步都告诉你为什么这么做、参数依据是什么、有哪些坑是我踩过的。1. 先定位瓶颈没有测量就没有提升1.1 盲目优化是灾难先让数据说话我见过不少同学看了一堆优化文章上来就把缓存、异步、消息队列全堆上结果接口没快多少系统却变得无比复杂。性能优化的第一原则永远是先找出真正的瓶颈再对瓶颈下手。否则你优化的是自己的想象不是用户感受到的延迟。在Spring Boot项目里最廉价、最有效的定位手段是下面这几样我几乎在每次优化前都会先搭起来Spring Boot Actuator快速暴露健康检查、指标信息。在pom.xml引入spring-boot-starter-actuator然后配置metrics端点开放几秒就能看到JVM内存、Tomcat线程、HTTP请求计数等基础指标。压测工具JMeter适合做复杂业务场景wrk适合快速测单个接口。我习惯本地用wrk线上回归用JMeter测出每秒请求数、平均响应时间、TP99、错误率。Arthas阿里开源诊断工具能在线观察方法调用耗时、线程栈、GC情况是定位代码级瓶颈的利器。先给一个最基础的Actuator依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency然后在application.yml里放行关键端点management: endpoints: web: exposure: include: health,metrics,prometheus metrics: export: prometheus: enabled: true启动后访问/actuator/metrics/http.server.requests就能按路径看到接口的响应时间分布。我一般先看这几个指标指标说明重点关注QPS每秒请求数低谷和峰值之间的差距RT平均响应时间用户直观感受TP9999%请求响应时间长尾请求是否异常GC耗时JVM垃圾回收时间是否频繁Full GC数据库连接池活跃数连接等待情况是否打满并排队有了这些数据再判断瓶颈在应用层、数据库层还是网络层。很多所谓性能问题其实根本不是代码慢而是线程池堵死、连接池耗尽、GC停顿或者慢SQL把数据库拖垮了。不测量就直接优化等于闭眼开车。1.2 用Arthas把慢方法揪出来如果说指标是体检报告那Arthas就是手术刀。下载arthas-boot.jar后直接java -jar arthas-boot.jar选择目标Java进程就能进入命令行界面。我日常用得最多的三个命令dashboard实时看CPU、内存、GC、线程状态第一屏就能发现哪个线程占CPU高。trace跟踪一个方法的调用路径和各节点耗时比如trace com.foo.service.OrderService listOrders执行一次请求后就能看到方法内部每一步的毫秒级耗时。thread查看线程栈配合thread -n 3查看最繁忙的线程在干什么。有一次线上接口偶发变慢压测指标看起来脉动很大用dashboard看到频繁发生Young GC又用trace定位到某个工具类每次请求都new了一个巨大的ArrayList并反复扩容。改掉那行代码后GC频率直接降下来。这种问题如果光靠代码review可能几天都查不出来。所以我会反复强调性能优化最大的成本不是改代码而是找代码。工具用好了后面每一步优化都有依据。2. 缓存实战让热点请求直连内存2.1 为什么Caffeine能被称为性能核武器如果只能选一项优化手段我建议优先做缓存。为什么因为缓存把最耗时的远程调用变成了一次几乎无成本的内存读取。数据读取延迟大概是什么量级我放一组直观数据读取方式典型耗时相对速度MySQL磁盘随机读5ms ~ 20ms1xRedis网络读0.5ms ~ 2ms约10倍损耗Caffeine本地读0.01ms ~ 0.05ms百倍到千倍注意我这里不是否定Redis。分布式环境下Redis是共享缓存的首选但Spring Boot应用访问Redis还要走一次网络IO而且还需要序列化和反序列化。Caffeine直接在应用进程内存里读天然就比网络IO快几个数量级。对读多写少、允许短暂不一致的热点数据来说Caffeine就是性价比极高的核武器。更重要的一点是Caffeine内置了高性能的淘汰算法W-TinyLFU不像传统的LRU只记录最近访问它能识别出高频但偶尔访问的数据并抵抗扫描式恶意缓存穿透。用起来也极简单Spring Boot官方对Caffeine有很好支持几乎不需要额外配置就能接入。2.2 在Spring Boot中快速落地Caffeine实际落地只需三步引入依赖、配置CacheManager、在方法上添加注解。第一步引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependency第二步创建一个Caffeine配置类设置缓存初始容量、最大容量和过期策略Configuration EnableCaching public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineObject, Object caffeine Caffeine.newBuilder() .initialCapacity(100) .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(30)) .recordStats(); return new CaffeineCacheManager(order, goods, user); } }这里expireAfterWrite表示写入后30分钟过期。为什么我常用写后过期而不是读后过期因为写后过期能保证数据有一个明确的最大存在时间对缓存与数据库一致性的管理更简单。recordStats()开启统计后面可以接上Actuator看缓存命中率这个很关键。第三步在业务方法上加CacheableService public class GoodsService { Cacheable(value goods, key #id) public Goods getGoodsById(Long id) { return goodsMapper.selectById(id); } }value对应缓存管理器里的缓存名key用SpEL表达式指定缓存键。我通常会加上缓存命中率监控然后观察一段时间的命中率是否在80%以上。如果命中率长期低于50%说明这个接口的热点程度不够或者key设计有问题不如不缓存。这里有几个最容易踩的坑我全踩过Cacheable注解的方法必须是从外部通过代理调用同类内部调用不会走缓存比如this.getGoodsById()这样调用时注解失效。方法必须是非private否则代理不会生效。方法的返回值不能是nullCaffeine默认不支持缓存null值。如果想缓存空结果做防穿透处理需要自定义CacheAspect或用Optional包装。2.3 缓存一致性别让脏数据背锅本地缓存最大的风险是数据不一致。用户A改了个商品价格用户B请求还是拿到旧值这个问题如果处理不好领导会直接让你下线缓存。我的标准做法是优先用短过期时间兜底比如30分钟或1小时。即使缓存更新失败最终也会过期自愈。数据变更时主动删除缓存而不是更新缓存。使用CacheEvict注解在写操作后失效缓存CacheEvict(value goods, key #id) public void updateGoods(Long id, Goods goods) { goodsMapper.updateById(goods); }为什么先删缓存而不是先更新缓存因为并发的场景下更新缓存的操作可能被乱序执行导致旧值覆盖新值而删除缓存可以保证下一次读取回源数据库。当然删了之后再遇到并发读可能短暂多查一次数据库但换来的是缓存不会长期脏。另外要提醒一下Caffeine是本地缓存在多实例部署下每个实例各有一份副本。如果要实时强一致就不要用纯本地缓存做这种数据。常见的折中是Caffeine Redis多级缓存本地缓存放高频热点且允许短时间不一致的数据Redis放严控一致性的数据。但多级缓存的复杂性让很多团队翻车所以我的建议是先把单层Caffeine用好命中率高、收益大再去想多级缓存。3. JVM与Web容器调优不写业务代码也能提速3.1 别用默认JVM参数直接上生产不少Spring Boot应用部署时直接java -jar app.jar一切交给JVM默认值。默认的堆大小受物理机内存影响而且垃圾回收器在JDK 8下默认是ParallelJDK 11以后默认G1但参数未必匹配你的应用特点。我通常会在启动脚本里显式指定JVM参数先给一套稳妥的模板java -Xms2g -Xmx2g -XX:MaxMetaspaceSize256m \ -XX:UseG1GC -XX:MaxGCPauseMillis50 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/ \ -jar app.jar参数含义逐一说清楚-Xms2g -Xmx2g初始堆和最大堆相同避免运行期堆反复扩容和收缩。为什么强调相同因为扩容是耗时的而且启动阶段堆太小初期频繁GC。如果服务器内存不大可以先从1g开始压测观察。-XX:UseG1GC -XX:MaxGCPauseMillis50G1是区域化收集器适合多核大内存场景。MaxGCPauseMillis只是目标值不是保证值但能让JVM在吞吐和延迟之间做权衡。如果你的应用主要是低延迟小对象也可以考虑ZGC但JDK 17以下ZGC还不太成熟新手别折腾。-XX:HeapDumpOnOutOfMemoryError内存溢出时自动dump一份堆快照方便后续分析。-XX:MaxMetaspaceSize256m限制元空间大小防止类加载过多把内存吃掉。有一个常见误区堆越大越好不是。堆太大会导致GC扫描时间变长尤其Full GC时停顿可能达到数秒。如果业务对象短命2g堆通常够用真有余力优化的是让对象尽快成为可回收对象不要随意缓存大对象。观察GC可以使用jstat -gcutil PID 1000看YGC、FGC频率和耗时。如果连续多次Full GC且耗时大优先排查内存泄漏而不是调大堆。3.2 Tomcat线程池不是越大越好Spring Boot默认内嵌Tomcat日请求量不大的时候不需要动但一旦出现接口慢然后Tomcat线程全部占满就要看线程池配置了。我见过一上来就server.tomcat.threads.max1000的同学结果数据库连接池只有10个1000个线程全在等连接CPU上下文切换倒是先爆了。正确的逻辑是线程数要配合下游资源的容量来设。先给出一套适合多数接口场景的配置server: port: 8080 tomcat: threads: max: 200 min-spare: 20 accept-count: 200 max-connections: 2000 connection-timeout: 5000解释一下max200处理请求的最大线程数。200是相对稳妥的起点如果接口平均响应20ms这200个线程可以扛10000 QPS如果平均响应200ms实际吞吐就掉到1000 QPS。所以要根据RT调整而不是盲目加大。min-spare20保持20个空闲线程接受请求避免瞬时流量涌来时现创建线程。accept-count200请求队列长度。当线程满时新请求进队列等线程队列满后连接才被拒绝或排队。这个值太大前端感知会超时太小突发流量会立刻报错。connection-timeout5000连接建立超时时间单位毫秒。调线程池一定要配合压测。我常用的方式是固定QPS逐步往上加观察RT和CPU。如果CPU还没到70%而RT开始飙升先怀疑线程阻塞如果CPU满了RT也比较差那就要考虑加机器而不是无限加线程。3.3 Gzip压缩响应体小了传输快了网络传输是非常容易被忽视的性能项。Spring Boot的响应体大多是JSON里面大量重复字段名压缩率极高。开启内嵌Tomcat的压缩后同一个JSON响应可以从30KB压缩到6KB左右带宽和网络耗时都能显著下降。配置很简单server: compression: enabled: true mime-types: application/json,application/xml,text/html,text/plain,text/css,application/javascript min-response-size: 1024min-response-size表示响应体超过1KB才压缩避免对小响应浪费CPU。这个压缩一般只影响外部调用服务间通信可以继续用二进制协议或单独控制。如果前面还挂了Nginx建议Nginx做一层压缩后端关闭或者只压缩特定类型避免重复压缩浪费CPU。我实际压测过一个返回大列表的接口开启压缩后RT降低了35%左右尤其在弱网环境下提升更明显。代价是CPU会高一点因为压缩计算有开销适合响应体大、网络带宽瓶颈明显的场景。4. 数据库访问优化慢SQL是最大拦路虎4.1 HikariCP连接池参数手把手教你设Spring Boot 2.x默认使用HikariCP这本身是性能很高的连接池但默认值不一定适合你的压力。最核心的两个参数是maximum-pool-size和maximum-pool-size还有一个connection-timeout。我给出一个参考配置spring: datasource: hikari: minimum-idle: 10 maximum-pool-size: 20 connection-timeout: 30000 max-lifetime: 1800000 idle-timeout: 600000这里maximum-pool-size20看起来不大但大多数情况足够。为什么假设单条SQL执行10ms20个连接可以支撑20 / 0.01 2000 QPS的数据库请求。如果压力还需要更高优先看SQL和缓存而不是盲目加连接。每条数据库连接都要占用内存和数据库进程资源连接数太多反而会把数据库拖垮。connection-timeout设置的是等待连接的超时时间。如果请求经常出现Connection is not available, request timed out错误说明连接池被打满尤其是线程阻塞等待。这时不要简单加连接池要先查慢SQL和锁竞争。max-lifetime要设置得比数据库服务器wait_timeout短一些否则连接会被数据库端的空闲超时杀掉应用还在用就报错。我一般设30分钟。调优连接池的关键是观察连接池的活跃数。通过Actuator的hikaricp.connections.active和hikaricp.connections.pending可以看出是否达到峰值并出现排队的现象。如果active长期接近maximum-pool-size就说明数据库访问是瓶颈或者连接回收不及时。4.2 索引和批处理让SQL变轻快数据库优化里最直接的往往是索引。我优化订单列表接口时原来的SQL长这样SELECT o.*, u.name, g.name FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN goods g ON o.goods_id g.id WHERE o.status 1 ORDER BY o.create_time DESC LIMIT 10;压测发现这个SQL平均耗时380ms问题很典型orders表数据量过百万status字段区分度不高单独建status索引没什么用排序又没走索引导致Using filesort。最终方案是组合索引(status, create_time)因为查询条件是status1排序字段是create_time走组合索引可以同时过滤和排序避免文件排序。添加索引后ALTER TABLE orders ADD INDEX idx_status_create_time (status, create_time);实际响应直接从380ms下降到12ms。这还只是加了一个索引的收益。检查SQL执行计划用EXPLAIN SELECT ...看type、key、rows字段。如果type是ALL或者rows极大说明在走全表扫描这就是性能杀手。批量操作是另一个容易被忽略的点。如果在循环里逐条INSERT每次都会产生一次网络往返和事务提交。正确的姿势是Autowired private JdbcTemplate jdbcTemplate; public void batchInsert(ListOrderItem items) { jdbcTemplate.batchUpdate( INSERT INTO order_item (order_id, goods_id, quantity) VALUES (?, ?, ?), items, 100, (ps, item) - { ps.setLong(1, item.getOrderId()); ps.setLong(2, item.getGoodsId()); ps.setInt(3, item.getQuantity()); } ); }批量500到1000条一次提交往往比一条条插入快5到10倍。如果是大事务还需要注意控制批次大小一口气插十几万条会造成undo积累和锁占用反倒容易出问题。4.3 少查字段别让ORM帮你做全表扫描很多同学写Mapper时习惯SELECT *然后代码里只用到两三个字段。这个习惯在数据量小时没感觉数据量大后就是噩梦。网络传输的字节数、数据库行游标、ORM映射的字段数都在增加变慢是必然的。我的建议是只查你需要的字段并且用明确的列名替代*。尤其在联表查询时可以用覆盖索引减少回表。比如列表中只需要订单号和状态就不要把用户、地址、备注全部查出来。另一个经典问题是N1。在JPA或MyBatis中遍历主表再逐条查子表会产生N次查询。JPA可以通过EntityGraph或join fetch一次关联查出Query(select o from Order o join fetch o.items where o.id :id) OptionalOrder findByIdWithItems(Param(id) Long id);MyBatis则可以用collection标签的嵌套ResultMap实现一次查询多表映射。压测时如果发现数据库端每秒查询次数奇高就要警惕N1。用Hibernate的话可以在application.yml里临时打开SQL日志统计logging: level: org.hibernate.SQL: debug org.hibernate.type.descriptor.sql: trace排查阶段打开线上关闭防止日志量太大。另外分页也是SQL优化的重灾区传统的LIMIT offset, size越往深翻页越慢因为数据库还是会把前面的数据扫描一遍。大数据量下推荐keyset分页记录上一页最后一条主键用WHERE id ? ORDER BY id LIMIT ?来翻页性能几乎恒定。这个优化对后台管理列表类的接口尤其明显。5. 异步化与启动加速继续榨干性能5.1 用Async处理非核心链路接口响应直接减半有些操作不必同步返回结果比如发送短信、写审计日志、调用外部通知、清理临时文件。把这些逻辑从请求主线程剥离出去接口的RT会显著下降。Spring Boot里用Async非常简单先在启动类或配置类开启异步Configuration EnableAsync public class AsyncConfig { Bean(commonAsyncExecutor) public Executor commonAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix(common-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }然后需要异步执行的方法上加Async(commonAsyncExecutor)Async(commonAsyncExecutor) public void sendSms(LoginUser user) { smsClient.send(...); }这里的线程池参数很关键queueCapacity100表示任务超过线程数和队列数时的策略。CallerRunsPolicy表示队列满后由调用线程执行这个策略能避免异步任务无限堆积导致内存溢出谁调用谁跑压力自然反馈回去。Async有几个坑必须注意被Async标注的方法和Cacheable一样必须通过代理调用同类内部调用不会生效。方法不能是static或private。异常默认不抛给调用方必须自己捕获处理否则日志很不明显。如果主流程依赖异步结果就不该用异步。比如用户下单后需要立刻返回订单号那就必须同步等待数据库插入完成。我用异步优化过一条登录流程原本登录接口要写登录日志、发欢迎短信、更新用户最后活跃时间加个Async后接口RT从340ms降到120ms效果非常立竿见影。但这只是把耗时挪到了后台系统总吞吐并没有变如果数据库本身就是瓶颈异步只会让数据库压力滞后而不是减小。5.2 Spring Boot启动速度优化部署回归都受益性能优化不全是接口RT开发迭代时启动时间也很折磨人。我有几个实用技巧第一懒加载。在application.yml中设置spring: main: lazy-initialization: true这样Spring容器启动时不再立即创建所有Bean而是首次使用时才初始化。开发环境启动时间可能从20秒降到8秒。但生产环境慎用因为懒加载会把启动时的亮剑变成请求时的延迟如果某个Bean初始化很慢第一次访问可能超时。所以这个选项适合开发不适合上线。第二排除不掉用的自动配置类。Spring Boot的自动配置虽然方便但如果你没用到邮箱、MongoDB、Redis等模块却把对应依赖引入了启动时可能加载一堆没用的初始化。在启动类上显式排除SpringBootApplication(exclude { MongoAutoConfiguration.class, MailSenderAutoConfiguration.class })排查哪些配置在启动日志中打印结合依赖去掉不需要的starter效果更好。第三启动时使用AOT和构建镜像不是这里要展开的但有一个JVM参数值得提-XX:TieredStopAtLevel1可以让JVM只使用C1编译器避免启动阶段进行C2编译。对大型应用启动时间能缩短10%-20%代价是运行期峰值性能会略低所以更适合开发和短期验证。6. 常见问题与性能排查速查表6.1 典型问题对照为什么我优化了没效果下面这些场景我至少见过十几次整理成速查表方便你排错现象常见原因解决方案Cacheable一直不生效每次还是查库没加EnableCaching或方法内部调用或方法非public确认启动类开启缓存外部Bean调用改public方法本地缓存数据总是不一致缓存过期时间太长主动失效漏了场景缩短短过期时间在写操作上加CacheEvict压测时TPS上不去但CPU很低数据库连接池太小线程都在等待连接检查hikaricp.connections.pending加索引/改SQL或适量加连接池增加Tomcat线程后RT反而升高线程过多导致大量上下文切换且下游连接池打满减少线程数优先降低单个请求RT开了Gzip后接口变慢每次压缩大量响应导致CPU飙升和Nginx重复压缩提高min-response-size只在Nginx层压缩异步任务偶尔丢失线程池队列满了任务被拒绝设置CallerRunsPolicy或改用带持久化的消息队列JVM参数没生效启动脚本里顺序错误或参数被覆盖使用ps -ef确认子进程实际参数加索引后SQL还是慢索引没有被使用可能查询条件中函数处理了索引列EXPLAIN看实际执行计划调整索引或重写SQL如果你做完某一步后感觉没变化先检查是不是前面三步测量、定位、再测量没做。性能优化不是堆功能而是验证假设。每改一项我都要重新压一遍记录QPS、RT、TP99、GC和数据库连接池活跃数对比优化前后数据而不是凭感觉说好像快了。6.2 实操心得我建议你按这个顺序开工根据我自己的项目经验性能优化有一个很实在的顺序收益从高到低通常是数据库慢SQL和索引一条全表扫描的SQL几乎能吞掉你所有的努力。先开慢查询日志找到那些执行频率高、单次耗时长的查询。缓存热点数据用Caffeine减少90%的重复查询对读多写少的接口是断崖式提升。连接池和Tomcat线程池调优确保资源能跑满但不要过载。JVM参数调整减少GC停顿稳定长尾延迟。Gzip压缩传输大JSON时收益明显。异步化把非核心链路剥离开提升单次接口体验。需要说明的一点是不要迷信某个核武器技术本身。Caffeine再快如果你的接口慢在文件IO、外部API、大量计算上它也帮不了你。所谓500%的提升一定是多个环节同时优化后的综合结果。我在那次订单列表优化中之所以能达到接近5倍是因为数据库索引消除了最大的阻塞缓存减少了80%的重复查询连接池参数避免了线程排队三件事合起来才有的数据。最后再分享一个我个人的习惯性能优化做完后把压测报告、参数配置、改动SQL都整理到一张表格里贴到项目文档上。因为性能瓶颈是会漂移的今天优化的热点接口可能下个月就不是热点参数也不是一劳永逸。下次再有人问我Spring Boot性能提升怎么搞我就会直接甩出这套流程让他先测再说。