SpringBoot项目越写越慢，性能调优有哪些坑？🔍，极度舒适。

说白了 SpringBoot 项目“越写越慢”不是主要原因是框架本身有问题，而是我们在开发过程中忽略了一些细节。比如线程池配置、缓存使用、数据库查询方式、GC 策略等等。这些问题慢慢积累，到头来导致系统整体性能下降，歇了吧...。

数据库连接池的陷阱

记得有一次线上故障， 系统 CPU 负载飙到 90%+，而数据库连接池几乎被打满。那时候我们用的是默认的 HikariCP 配置， 我狂喜。 没有设置 maxPoolSize后来啊大量请求堆积在连接池中，导致整个服务卡顿。

spring: datasource: hikari: maxPoolSize: 10 # 默认值，非常容易被打满

正确做法：依据 QPS 设置连接池大小

别告诉我你还用默认配置！要根据你的 QPS来合理设置 maxPoolSize 和 minimumIdle。公式大概是这样的：maxPoolSize = QPS * 平均查询时间 / 连接池命中率 。 我整个人都不好了。 当然这个只是一个估算值,需要结合实际情况进行调整和监控。

JVM 的那些事儿

JVM 是 SpringBoot 应用运行的基础。不合理的 JVM 参数会导致各种性能问题。

之前我们团队有个项目，上线初期 RT是 30ms 左右，QPS 能到 1000。但因为业务功能越来越多，RT 一路飙到 120ms， 不夸张地说... 甚至有几次直接超时。当时大家以为是数据库出了问题，后来啊排查下来发现其实很多问题都藏在了代码里。

-Xms4g-Xmx4g-XX:+UseG1GC-XX:MaxGCPauseMillis=200-Xlog:gc*:file=./logs/:time

设置 Xms = Xmx 能避免堆动态扩容带来的 STW。

再说一个还有一些需要关注的点：

• 选择合适的垃圾回收器： G1GC 在大多数场景下表现良好。
• 调整堆大小： 根据实际内存使用情况调整 -Xms 和 -Xmx 。
• 监控 GC 日志： 定期分析 GC 日志可以帮助你发现潜在的内存泄漏和 GC 问题。

缓存策略的误区

梳理梳理。 缓存是提升性能的关键手段之一,但是如果使用不当,反而会适得其反。

Redis 的那些烦恼

检查 BigKey： Redis 中如果存在过大的 Key 会影响性能,需要定期检查并进行拆分。

redis-cli MEMORY USAGE user:info:123

开启 Redis slowlog : 可以记录施行时间超过阈值的命令,方便定位慢查询问题。

redis-cli SLOWLOG GET 100

缓存预热示例： 在服务启动后将热点数据加载到缓存中,避免首次访问时产生延迟。

代码层面的优化

N+1 查询问题

SELECT u., o.FROM user uLEFT JOIN orders o ON = _idWHERE = 1;

不如... 有一次我们发现一个查询接口 RT 超过 100ms,但 SQL 施行却只有 5ms。后来发现是 MyBatis 没有正确使用缓存,导致每次请求都重新查数据库。

频繁使用 BeanUtils

奥利给！ 错误做法：频繁使用 BeanUtils BeanUtils 反射效率较低,应该尽量避免在核心逻辑中使用。 UserVO vo = ; 正确做法：MapStruct 或手动赋值 MapStruct 可以生成高性能的代码来完成对象转换. UserVO vo = new UserVO;;

超大方法

public void processOrder { //几百行代码...} 之前有一个订单服务， 里面逻辑特别复杂，各种 if - else ，还有嵌套循环。每次处理一个订单都要走几十步操作后来啊导致接口 RT 直接翻倍。正确做法：职责拆分 +策略模式 将大方法拆分成多个小方法或者使用策略模式将不同的逻辑分离出来 。 大胆一点... 比方说: @ Service publicclassWechatPayStrategyimplements PayStrategy{publicvoidpay { ...}}

一些其他的建议

• 第一步:spring boot启动类上添加@ServletComponentScan注解 ,该注解会自动扫描到我们自定义的filter。springboot项目 中进行XSS过滤简单介绍XSS :跨站脚本攻击,为不和层叠样式表的缩写混淆 ,故将跨站脚本攻击缩写为XSS 。恶意攻击者往Web页面里插入恶意html代码 ,当用户浏览该页之时 ,嵌入其中Web里面的html代码会被执…

至于吗？ 我还有一个印象深刻的故事.之前我们有个项目实现商品订单服务 ，使用了大量的DTO转换 。虽然看起来没什么问题 ，但实际测试的时候 ，发现这个转换过程占了整个请求的25%左右的时间 。后来使用了MapStruct之后速度提升了整整十倍以上！

总而言之 .性能调优是一个持续的过程 .你需要不断地学习新的技术和工具 、不断地分析和改进你的代码和配置 。希望这些经验能对你有所帮助 !，中肯。

走捷径。 再说说分享一段初始化bean的代码:@ PostConstruct publicvoidwarmUp{List hotUsers= ; .set,u,);}. 注意这里的热点用户预热操作一定要做好！