前言
不知道你在SpringBoot项目中,有没有遇到过下面这样的代码:
java
@GetMapping("/orders")
public List<Order> listOrders() {
return orderDao.findAll();
}
一次性查询了所有的订单,全表扫描50万数据,导致接口查询性能很差,严重的时候可能会导致OOM问题。
问题定位:
- 未分页查询
- 无缓存机制
- 未启用批量处理
这次事故让我明白:性能优化必须贯穿开发全流程。
今天这篇文章,跟大家一起聊聊SpringBoot优化的12招,希望对你会有所帮助。


第1招:连接池参数调优
问题场景 :
默认配置导致连接池资源浪费,高并发时出现连接等待
错误配置:
plain
spring:
datasource:
hikari:
maximum-pool-size: 1000
connection-timeout: 30000
数据库连接池的最大连接数,盲目设置过大,连接超时时间设置过长。
优化方案:
plain
spring:
datasource:
hikari:
maximum-pool-size: ${CPU核心数*2} # 动态调整
minimum-idle: 5
connection-timeout: 3000 # 3秒超时
max-lifetime: 1800000 # 30分钟
idle-timeout: 600000 # 10分钟空闲释放
数据库连接池的最大连接数,改成根据CPU核心数动态调整。
将连接超时时间由30000,改成3000。
第2招:JVM内存优化
问题场景 :
频繁Full GC导致服务卡顿
我们需要优化JVM参数。
启动参数优化:
java
java -jar -Xms4g -Xmx4g
-XX:NewRatio=1
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=35
-XX:+AlwaysPreTouch
最大堆内存和初始堆内存都设置成了4G。
-XX:NewRatio=1,设置新生代和老年代各占一半。
垃圾收集器配置的是G1。
垃圾回收的最大停顿时间为200毫秒。
第3招:关闭无用组件
问题场景 :
自动装配加载不需要的Bean
优化方案:
plain
@SpringBootApplication(exclude = {
DataSourceAutoConfiguration.class,
SecurityAutoConfiguration.class
})
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
如果有些功能暂时用不到,可以先排除一下。
在SpringBoot项目启动的时候,排除了DataSourceAutoConfiguration和SecurityAutoConfiguration配置类的自动装载。
第4招:响应压缩配置
问题场景 :
接口返回JSON数据体积过大
优化方案:
yml
server:
compression:
enabled: true
mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/json
min-response-size: 1024
配置开启响应的压缩。
第5招:请求参数校验
问题场景 :
恶意请求导致资源耗尽
防御代码:
java
@GetMapping("/products")
public PageResult<Product> list(
@RequestParam @Max(value=100, message="页大小不能超过100") int pageSize,
@RequestParam @Min(1) int pageNum) {
//...
}
在接口中做好参数校验,可以拦截很多恶意请求。
第6招:异步处理机制
问题场景 :
同步处理导致线程阻塞
优化方案:
java
@Async("taskExecutor")
public CompletableFuture<List<Order>> asyncProcess() {
return CompletableFuture.completedFuture(heavyProcess());
}
@Bean("taskExecutor")
public Executor taskExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(5);
executor.setMaxPoolSize(10);
executor.setQueueCapacity(500);
return executor;
}
在有些业务逻辑中,使用异步处理性能可能会更好。
第7招:使用缓存
使用缓存可以提升效率。
缓存架构:

代码实现:
java
@Cacheable(cacheNames = "products", key = "#id",
cacheManager = "caffeineCacheManager")
public Product getDetail(Long id) {
return productDao.getById(id);
}
这里使用了内存缓存。
第8招:批量操作优化
问题场景 :
逐条插入导致性能低下
优化方案:
java
@Transactional
public void batchInsert(List<Product> products) {
jdbcTemplate.batchUpdate(
"INSERT INTO product(name,price) VALUES(?,?)",
products,
500, // 每批数量
(ps, product) -> {
ps.setString(1, product.getName());
ps.setBigDecimal(2, product.getPrice());
});
}
每500条数据插入一次数据库。
第9招:索引深度优化
问题场景 :
慢查询日志频繁出现全表扫描,SQL执行时间波动大
错误案例:
sql
-- 商品表结构
CREATE TABLE products (
id BIGINT PRIMARY KEY,
name VARCHAR(200),
category VARCHAR(50),
price DECIMAL(10,2),
create_time DATETIME
);
-- 低效查询
SELECT * FROM products
WHERE category = '手机'
AND price > 5000
ORDER BY create_time DESC;
问题分析:

优化方案一:联合索引设计
索引创建:
下面创建了一个分类ID,单价和时间的联合索引:
sql
ALTER TABLE products
ADD INDEX idx_category_price_create
(category, price, create_time);
优化方案二:覆盖索引优化
查询改造:
只查询索引包含字段:
sql
SELECT id, category, price, create_time
FROM products
WHERE category = '手机'
AND price > 5000
ORDER BY create_time DESC;
这里使用了覆盖索引。
优化方案三:索引失效预防
常见失效场景:

案例修复:
错误写法:
sql
SELECT * FROM products
WHERE DATE(create_time) = '2023-01-01';
正确写法:
SELECT * FROM products
WHERE create_time BETWEEN '2023-01-01 00:00:00'
AND '2023-01-01 23:59:59';
查询时间范围,这里使用了BETWEEN AND关键字,代替了等于号。
优化方案四:索引监控分析
诊断命令:
查看索引使用情况:
sql
SELECT
index_name,
rows_read,
rows_selected
FROM
sys.schema_index_statistics
WHERE
table_name = 'products';
分析索引效率:
EXPLAIN FORMAT=JSON
SELECT ...;
索引优化黄金三原则
- 最左前缀原则:联合索引的第一个字段必须出现在查询条件中
- 短索引原则:整型字段优先,字符串字段使用前缀索引
- 适度索引原则:单个表索引数量不超过5个,总索引长度不超过表数据量30%
DBA工具箱
- 索引分析脚本
- 执行计划可视化工具
- 索引碎片检测工具
第10招:自定义线程池
问题场景 :
默认线程池导致资源竞争
优化方案:
java
@Bean("customPool")
public Executor customThreadPool() {
return new ThreadPoolExecutor(
10, // 核心线程
50, // 最大线程
60, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(1000),
new CustomThreadFactory(),
new ThreadPoolExecutor.CallerRunsPolicy());
}
在高并发业务场景中,使用Executors类创建默认的线程池,可能会导致OOM问题。
因此,我们需要自定义线程池。
第11招:熔断限流策略
问题场景 :
突发流量导致服务雪崩
解决方案:
java
// 使用Sentinel实现接口限流
@SentinelResource(value = "orderQuery",
blockHandler = "handleBlock",
fallback = "handleFallback")
@GetMapping("/orders/{id}")
public Order getOrder(@PathVariable Long id) {
return orderService.getById(id);
}
// 限流处理
public Order handleBlock(Long id, BlockException ex) {
throw new RuntimeException("服务繁忙,请稍后重试");
}
// 降级处理
public Order handleFallback(Long id, Throwable t) {
return Order.getDefaultOrder();
}
为了解决重复流量导致服务雪崩的问题,我们需要增加接口熔断、限流和降级处理。
第12招:全链路监控体系
问题场景 :
线上问题定位困难,缺乏数据支撑
我们需要增加项目全链路的监控。
监控方案:
yml
# SpringBoot配置
management:
endpoints:
web:
exposure:
include: "*"
metrics:
export:
prometheus:
enabled: true
这里使用了prometheus监控。
监控架构:

核心监控指标:

总结
SpringBoot性能优化检查清单
- 连接池参数按业务调整
- JVM参数经过压测验证
- 所有查询走缓存机制
- 批量操作替代逐条处理
- 线程池按场景定制
- 全链路监控覆盖

三条黄金法则:
- 预防性优化:编码时考虑性能影响
- 数据驱动:用监控指标指导优化方向
- 持续迭代:性能优化是持续过程
性能工具包
- Arthas在线诊断
- JProfiler性能分析
- Prometheus监控体系
(看着监控大屏上平稳的QPS曲线,我知道今晚可以睡个好觉了...)
最后说一句(求关注,别白嫖我)
如果这篇文章对您有所帮助,或者有所启发的话,帮忙关注一下我的同名公众号:苏三说技术,我的所有文章都会在公众号上首发,您的支持是我坚持写作最大的动力。
求一键三连:点赞、转发、在看。
关注公众号:【苏三说技术】,在公众号中回复:进大厂,可以免费获取我最近整理的10万字的面试宝典,好多小伙伴靠这个宝典拿到了多家大厂的offer。
本文收录于:www.susan.net.cn