大数跨境
0
0

让 SpringBoot 飞起来!15条性能优化秘籍,轻松应对百万并发

让 SpringBoot 飞起来!15条性能优化秘籍,轻松应对百万并发 终码一生
2025-08-21
0
点击“终码一生”,关注,置顶公众号
每日技术干货,第一时间送达!

为何提前暴露指标与分析的重要性

在正式进行性能优化之前,必须先“看得到”系统运行状况:缓存命中率、数据库连接池使用情况、响应时长分布、CPU/内存消耗、垃圾回收停顿等。只有掌握真实数据,才能有针对性地优化;盲目调整往往事倍功半,甚至适得其反。
01
指标暴露与监控接入
Prometheus 集成
  1. Maven 依赖
  2. application.properties/application.yml 配置
  3. 启动与访问
  4. 自定义业务指标示例
  5. Grafana 可视化与 AlertManager
在 Grafana 中配置 Prometheus 数据源,创建 Dashboard 展示:
  • JVM 内存、GC 停顿、线程数
  • HTTP 请求速率、延迟分布(可借助 Histogram/Summary
  • 缓存命中率:hit/(hit+miss)
  • 数据库连接池使用率:活跃连接数 vs 最大连接数
AlertManager 配置告警规则,例如:
  • 95% 延迟超过阈值
  • GC 停顿时长过长
  • 连接池耗尽告警
此部分可参考 Prometheus 与 Grafana 官方文档,自行搭建实验环境。
图片
02
性能剖析工具:火焰图与 async-profiler
async-profiler 下载与使用
1、从 GitHub 下载 async-profiler release 包,解压至服务器目录,如 /opt/async-profiler
2、启动 SpringBoot 应用时,添加 javaagent 参数:
java -agentpath:/opt/async-profiler/build/libasyncProfiler.so=start,svg,file=profile.svg -jar your-app.jar
3、运行一段业务场景(压测或真实流量),然后停止进程或通过 async-profiler 提供的 CLI 停止采样:
# 若不想重启,可 attach 模式:
./profiler.sh -d 30 -f profile.svg <pid>
4、查看生成的 profile.svg,用浏览器打开:
图片
  • 横轴表示消耗的采样比例,宽度越大表示更耗时的方法。
  • 纵向为调用栈层级。
  • 从最宽处逐层向下分析,找到热点方法,结合源代码定位优化点。
结合 Flame 图优化示例
  1. 若热点在某个慢方法,可查看方法内部逻辑:是否存在不必要的循环、I/O 阻塞,或可并行优化。
  2. 若热点在序列化/反序列化,可考虑更高效的库或减小返回对象结构。
  3. 若大量时间在 GC,可结合 GC 日志分析堆配置是否合理。
03
HTTP 及 Web 层优化
图片
CDN 与静态资源加速
将常用静态资源(JS、CSS、图片)托管于 CDN,减轻后端压力;用户访问时由地理就近节点提供。
对第三方库可使用公共 CDN;自有资源可上传到 CDN 或静态文件服务器。
Cache-Control/Expires 在 Nginx 中配置示例
location ~* \.(ico|gif|jpg|jpeg|png|css|js)$ {
    add_header Cache-Control "max-age=31536000, immutable";
}
根据资源更新策略设置版本号或文件指纹,保证缓存命中又可及时更新。
减少域名数量
将静态资源和 API 接口合理合并域名;避免过多不同子域导致 DNS 查询延迟。
可启用 HTTP/2 时,多路复用可减少域名依赖,但 HTTP/2 支持需服务器和客户端皆启用。
Gzip 及资源压缩配置
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_types text/plain application/javascript text/css application/json;
确保对动态 JSON 接口开启 gzip,减小响应体体积。
对大型静态文件可在构建时先行压缩(如 Brotli),结合 Nginx 支持。
Keep-Alive 配置
客户端与 Nginx:
http {
    keepalive_timeout  60s 60s;
    keepalive_requests 10000;
}
Nginx 与 SpringBoot 后端长连接:
location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}
SpringBoot/Tomcat 默认支持 Keep-Alive可通过自定义 Connector 调整超时。
04
SpringBoot 容器调优
自定义嵌入式 Tomcat
如果项目并发量比较高,想要修改最大线程数、最大连接数等配置信息,可以通过自定义Web 容器的方式,代码如下所示。
@SpringBootApplication(proxyBeanMethods = false)
publicclassAppimplementsWebServerFactoryCustomizer<ConfigurableServletWebServerFactory{
    publicstaticvoidmain(String[] args){
        SpringApplication.run(App.classargs);
    }
    @Override
    publicvoidcustomize(ConfigurableServletWebServerFactory factory){
        if (factory instanceof TomcatServletWebServerFactory) {
            TomcatServletWebServerFactory f = (TomcatServletWebServerFactory) factory;
            f.setProtocol("org.apache.coyote.http11.Http11Nio2Protocol");
            f.addConnectorCustomizers(c -> {
                Http11NioProtocol protocol = (Http11NioProtocol) c.getProtocolHandler();
                protocol.setMaxConnections(200);
                protocol.setMaxThreads(200);
                protocol.setConnectionTimeout(30000);
                // protocol.setSelectorTimeout(3000); // NIO2 可选项
            });
        }
    }
}
设置协议为 NIO2 可在高并发 I/O 场景下提升性能;需基准测试验证。
setMaxThreads  setMaxConnections值根据服务器硬件资源与业务并发整,可在压测环境多次尝试并观察响应延迟、CPU 利用率、线程使用情况。
图片
替换 Undertow
在 pom.xml 中排除 Tomcat 并引入 Undertow:
<dependency>
  <groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
    <exclusion>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-tomcat</artifactId>
    </exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
Undertow 线程模型和资源占用一般较轻;需要在业务场景中压测对比。
注意部分 Tomcat 特有配置不适用,需调整监控指标对应项。
JVM 参数回顾
结合性能优化 - 高级进阶:JVM 常见优化参数,可启动时传入:
-XX:+UseG1GC -Xms2048m -Xmx2048m -XX:+AlwaysPreTouch -XX:MaxMetaspaceSize=256m -XX:ReservedCodeCacheSize=240m -XX:MaxDirectMemorySize=512m
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps -XX:ErrorFile=/path/to/hs_err_pid%p.log
-Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=5,filesize=100m
根据硬件和应用特点调整堆大小;若GC停顿问题突出,可结合 async-profiler 和 GC 日志深入分析。
05
应用性能监控与分布式追踪
SkyWalking 集成
图片
  1. 下载与部署
  2. 启动应用时添加 Agent
  3. 查看调用链与指标
  • 访问 SkyWalking UI,可看到每次请求的调用链图、各段耗时、数据库/HTTP 调用详情、JVM 指标、GC 指标。
  • 结合 Prometheus 等指标,综合判断:若某接口响应慢,可查看是哪一段(查询、序列化、远程调用等)成为瓶颈。
  1. 报警与自动化
可结合 SkyWalking 的告警和 Prometheus AlertManager 设置阈值告警。
定期分析热点接口和突发异常请求流,制定优化计划。
06
各层优化思路
Controller 层
  • DTO 精简与分页: 避免一次性返回过大结果集;对列表数据使用分页或流式方式(如 Spring MVC StreamingResponseBody)。
  • JSON 序列化优化: 选择高性能序列化库(Jackson 已较快,可开启 Afterburner 模块),避免将不必要字段序列化。
  • 输入校验与限流: 对异常或恶意请求提前拦截,减少无效处理。
  • 幂等性与缓存: 对可缓存接口,如 GET 查询,结合 HTTP 缓存头或后端缓存减少重复计算。
Service 层
无状态设计:Service Bean 默认单例无状态,避免在 Bean 中维护请求级状态。
合理拆分与职责分离: 将复杂逻辑拆成小模块,便于监控与优化。
异步与并行: 对于可并行处理的子任务,可使用 CompletableFuture、异步消息队列等;但要注意线程池配置与上下文传递。
缓存策略:
  • 本地缓存(Caffeine): 低延迟、减轻远程调用压力;监控命中率,避免缓存污染。
  • 分布式缓存(Redis): 适用于共享场景;注意 TTL 策略、防止缓存穿透(布隆过滤、请求预热)、防止雪崩(加随机过期)、防止击穿(互斥锁或预加载)。
避免重复计算与请求合并: 对重复请求可合并或去重,减少下游压力。
分布式事务讨论:
  • 两阶段提交、TCC、本地消息表等方案都会增加延迟与资源占用;仅在必要场景使用。
优先考虑补偿事务与柔性事务,实现最终一致性;通过幂等设计与补偿逻辑将风险和性能开销控制在可接受范围内。
如上图,分布式事务要在改造成本、性能、时效等方面进行综合考虑。有一个介于分布式事务和非事务之间的名词,叫作柔性事务。柔性事务的理念是将业务逻辑和互斥操作,从资源层上移至业务层面。
传统事务 vs 柔性事务
关于传统事务和柔性事务,我们来简单比较一下。
ACID
关系数据库,最大的特点就是事务处理,即满足 ACID。
  • 原子性(Atomicity): 事务中的操作要么都做,要么都不做。
  • 一致性(Consistency): 系统必须始终处在强一致状态下。
  • 隔离性(Isolation): 一个事务的执行不能被其他事务所干扰。
  • 持久性(Durability): 一个已提交的事务对数据库中数据的改变是永久性的。
BASE
BASE 方法通过牺牲一致性和孤立性来提高可用性和系统性能。
BASE 为 Basically AvailableSoft-stateEventually consistent 三者的缩写,其中 BASE 分别代表:
  • 基本可用(Basically Available): 系统能够基本运行、一直提供服务。
  • 软状态(Soft-state): 系统不要求一直保持强一致状态。
  • 最终一致性(Eventual consistency): 系统需要在某一时刻后达到一致性要求。
互联网业务,推荐使用补偿事务,完成最终一致性。比如,通过一系列的定时任务,完成对数据的修复。
DAO 层
ORM 使用注意:
懒加载原则: 避免无意触发大量关联查询,合理使用 FetchType.LAZY,并在Service层通过显式查询或 DTO 投影避免 N+1。
批量操作: 对于大量写场景,使用批量插入/更新。
SQL 优化与索引: 分析慢查询日志、使用 EXPLAIN 确认索引命中,避免全表扫描。
分库分表注意: 理解中间件实现原理,避免误以为简单 SQL 实现即高效;关注路由开销与合并成本。
数据库连接池:
HikariCP 默认已非常高效,但仍需监控活跃连接数、等待时长;根据业务并发调整最大连接数,避免连接池耗尽或空闲过多浪费资源。
在 Prometheus 中可通过 HikariPool 指标收集连接使用情况,适时调整。
07
缓存优化
Caffeine:
适合本地缓存,低延迟;需监控缓存大小*、命中率、加载延迟;避免过大导致内存占用过高。
Redis:
连接池配置: 监控和调整 Lettuce/Redisson 连接数;注意阻塞或过度并发导致连接耗尽。
数据序列化: 选择高效序列化方式(如 JSON、Kryo、FST 等),兼顾可读性与性能。
缓存策略: 参见上文防护策略;结合业务场景设计合理 TTL。
二级缓存: 对数据库读密集应用,可考虑本地+分布式二级缓存架构;注意缓存一致性。
08
资源与线程管理
线程池配置:
对于异步任务、自定义 Executor,设置合适的 core/max pool sizequeue size;监控线程活跃度、队列长度,防止任务堆积。
对于定时任务,避免过多定时线程争抢资源。
非阻塞与异步:
若业务适合,可使用 WebFlux 或 Reactor,但需慎重考虑团队熟悉度与实际场景;异步场景要注意线程切换开销和上下文传递。
对外 HTTP 调用可使用异步 HTTP 客户端(如 WebClient),避免阻塞线程。
09
端到端测试与压测
压测工具:
wrk、JMeter、Locust 等
测前准备:
确保监控、日志、profiling 准备完毕;在测试环境部署与生产相近的架构。
测试脚本设计:
模拟真实业务流量,包括登录、查询、写入等混合场景。
结果分析:
结合 Prometheus/Grafana 监控数据和火焰图,找出瓶颈;反复调优并回归测试,评估改动效果。
负载模型:
考虑渐增负载测试、稳定性测试、持久压力测试,观察资源消耗与响应曲线。
10
小结
指标采集—剖析—优化—验证是闭环流程: 始终保持对系统可观测性。
渐进式改动: 在非生产环境验证,避免一次性大改带来风险;生产环境小步部署与监控回滚准备。
CI/CD 集成: 可在持续集成/部署流程中集成简单的健康检查和性能基准测试。
定期回顾: 定时检查关键接口的性能指标,防止代码或依赖升级带来性能回退。
团队协作: 文档化优化经验,分享给团队成员,形成共识和规范。
https://blog.csdn.net/yangshangwei
END
PS:防止找不到本篇文章,可以收藏点赞,方便翻阅查找哦。



往期推荐



SpringBoot3+国产FolkMQ!5行代码搞定消息中间件

Cursor Pro Ai编程工具 永久激活 无限续杯白嫖最高模型

开启Cloudflare邮箱接管 详细流程

IntelliJ IDEA 2025.2 最新激活教程,一键激活2099

如何优雅的实现在线人数统计功能?

Http 接口对接太繁琐?试试 UniHttp 框架吧!简简单单~


【声明】内容源于网络
0
0
终码一生
开发者聚集地。分享Java相关开发技术(JVM,多线程,高并发,性能调优等),开源项目,常见开发问题和前沿科技资讯!
内容 1876
粉丝 0
终码一生 开发者聚集地。分享Java相关开发技术(JVM,多线程,高并发,性能调优等),开源项目,常见开发问题和前沿科技资讯!
总阅读1.5k
粉丝0
内容1.9k