SpringBoot GET接口单次调用耗时久、并发调用耗时升高的优化问题

一、先定位核心瓶颈 #

优先拆分耗时根因，避免盲目优化：

• 用Arthas、Spring Boot Actuator埋点拆分接口各阶段耗时，确认耗时是来自数据库查询、结果集映射、还是资源竞争（连接池排队、锁冲突、GC停顿）
• 优先排查数据库连接池状态：并发场景下连接数不足会导致请求排队等待连接，是耗时成倍上涨的常见诱因

二、基础访问逻辑优化（先降低单次请求耗时） #

单次请求25-30s本身就存在明显优化空间，这是并发性能恶化的基础：

• SQL优化：慢SQL是90%以上接口耗时过高的根因，先检查SQL是否存在全表扫描、未命中索引、关联查询冗余、返回字段过多的问题，优先把单次SQL查询耗时降到可接受范围
• 替换queryForRowSet实现：queryForRowSet返回的SqlRowSet是JDBCResultSet的包装类，默认会把全量结果加载到内存再返回，大数据量下性能远低于流式映射；直接使用JdbcTemplate.query(sql, rowMapper)方法，底层会逐行映射结果，避免二次遍历结果集的开销
• 结果映射优化：去掉手动while循环映射逻辑，直接使用Spring自带的BeanPropertyRowMapper或者自定义高性能RowMapper实现，减少手动映射的冗余逻辑和性能损耗
• 连接池调优：SpringBoot默认使用HikariCP连接池，调整核心参数：spring.datasource.hikari.maximum-pool-size建议设置为「CPU核心数*2 + 有效磁盘数」，不要设置过大导致数据库端连接过载；同时调整connection-timeout、idle-timeout参数避免无效连接占用资源

三、并发场景专项优化 #

解决并发下耗时成倍上涨的问题：

• 新增缓存层：如果接口返回数据不是强实时要求，用Caffeine做本地缓存、或者Redis做分布式缓存，相同查询参数的请求直接走缓存返回，大幅降低数据库压力
• 修正Bean作用域：Controller设置为prototype完全没有必要，Spring MVC的Controller默认是singleton，只要不定义可变成员变量就不会有线程安全问题；prototype会每次请求都创建Controller实例，额外增加性能开销，直接改回默认singleton即可
• 接口分页改造：如果单次查询返回数据量过大，强制接口增加分页参数，单次仅返回必要数量的数据，避免单次查询加载数万条数据导致的内存占用高、GC频繁问题
• 限流削峰：如果并发量超过系统承载上限，用Guava RateLimiter等组件做限流，避免大量请求同时打向数据库导致雪崩
• 异步化改造：如果业务允许非实时返回，可以将接口改造为异步查询模式，前端轮询或者回调获取结果，避免同步请求长时间占用连接池资源

四、JVM层面优化 #

并发场景下GC停顿也会导致耗时上涨：

• 调整堆内存配置，尤其是老年代大小，避免大量结果集对象频繁进入老年代触发Full GC
• 大内存场景下替换为G1垃圾回收器，降低GC停顿时间

内容的提问来源于stack exchange，提问作者Prasad Reddy