文章目录 专栏SpringBoot进阶实战系列 本文独家核心收获区别于全网水文一、前言为什么生产环境必须做性能调优二、性能调优核心流程生产标准规范2.1 标准调优四步法2.2 常见性能瓶颈优先级三、JVM生产级性能调优解决OOM、GC频繁、服务卡顿3.1 核心调优目标3.2 主流垃圾回收器选择生产必选G13.3 生产通用JVM参数可直接复制投产3.4 参数逐行详解吃透原理3.5 不同服务器内存适配方案3.6 高频JVM线上问题与解决方案问题1频繁Full GC问题2服务间歇性卡顿问题3OOM内存溢出四、数据库连接池HikariCP生产调优SpringBoot默认4.1 连接池参数错误的线上危害4.2 生产最优HikariCP配置直接投产4.3 核心参数深度解析4.3.1 maximum-pool-size 最大连接数重中之重4.3.2 其他核心参数4.4 连接池高频线上故障排查故障1HikariPool-1 - Connection is not available故障2数据库连接数爆满五、接口慢查询全链路优化90%性能问题根源5.1 第一步开启慢查询日志精准定位问题5.1.1 MySQL开启慢查询5.1.2 SpringBoot开启SQL日志5.2 慢SQL通用优化手段5.2.1 索引优化最核心5.2.2 SQL语句优化5.2.3 业务逻辑优化5.3 慢查询排查完整流程六、通用接口性能高阶优化方案6.1 缓存优化兜底高并发6.2 异步化优化6.3 线程池调优七、线上性能问题快速排查命令运维必备7.1 服务器资源排查7.2 JVM问题排查7.3 数据库排查八、生产调优上线Checklist逐条核对九、大厂面试高频问答满分标准答案9.1 JVM调优面试9.2 连接池调优面试9.3 慢查询优化面试十、全文总结 专栏SpringBoot进阶实战系列文章评级生产落地调优 底层原理拆解 问题定位闭环 高并发适配 面试全覆盖 适用人群后端开发、性能优化、线上故障排查、微服务调优、面试进阶、服务稳定性保障 前置基础SpringBoot项目部署、Linux基础命令、MySQL基础、JVM基础概念️ 文章标签#SpringBoot #性能调优 #JVM调优 #数据库连接池 #慢查询优化 #接口优化 #服务稳定性 本文独家核心收获区别于全网水文调优思维建立掌握「先定位瓶颈、再精准调优、最后压测验证」的生产标准调优流程拒绝盲目改参数JVM生产级调优吃透内存模型、垃圾回收机制给出高并发低延迟专属JVM参数解决OOM、GC频繁、卡顿问题连接池精准配置详解HikariCP核心参数解决连接泄露、连接超时、并发阻塞、资源浪费等线上顽疾慢查询全链路优化从日志排查、SQL分析、索引优化、业务重构、兜底方案全方位解决接口慢、超时、堆积问题通用接口性能优化缓存、异步、分页、限流、批量操作等企业通用优化手段适配所有业务接口线上故障快速排查汇总CPU飙高、内存溢出、接口超时、数据库阻塞全套排查方案面试满分题库覆盖JVM调优、连接池原理、慢查询优化、高并发性能架构高频考点一、前言为什么生产环境必须做性能调优很多本地正常运行的SpringBoot项目一旦上线生产就会出现各种诡异问题接口超时、服务卡顿、CPU持续飙高、内存溢出、数据库连接爆满、高峰期请求雪崩。根本原因本地开发参数默认适配小流量生产高并发、大流量、长连接场景完全不适用。默认参数只能保证项目能跑不能保证项目稳跑、快跑。性能调优不是玄学是数据驱动的精准优化核心优化三板斧JVM调优解决内存溢出、GC卡顿、线程阻塞、资源占用过高问题连接池调优解决数据库连接耗尽、连接超时、频繁创建销毁连接问题业务SQL调优解决慢查询、数据库CPU飙高、接口响应慢、堆积超时问题本文所有参数、方案均经过线上高并发项目验证可直接复制投产同时配套完整原理知其然更知其所以然。二、性能调优核心流程生产标准规范所有性能问题必须遵循以下流程禁止盲目修改参数2.1 标准调优四步法第一步监控观测通过监控、日志、命令定位瓶颈CPU/内存/IO/数据库/接口第二步问题定位精准锁定是JVM问题、连接池问题还是SQL业务问题第三步精准调优针对性修改参数、优化代码、重构SQL第四步压测验证压测对比QPS、响应时间、错误率确认优化生效2.2 常见性能瓶颈优先级90%的线上性能问题都出自以下三点优先级从高到低数据库慢查询最常见、影响最大单条慢SQL拖垮整个服务连接池参数不合理连接数过小阻塞请求过大浪费资源、导致数据库崩库JVM参数不当GC频繁、内存溢出、线程堆积、服务卡顿三、JVM生产级性能调优解决OOM、GC频繁、服务卡顿3.1 核心调优目标JVM调优不是把内存调越大越好生产核心目标低延迟减少Full GC频率避免服务卡顿高吞吐提升垃圾回收效率支撑高并发稳运行彻底杜绝OOM内存溢出、内存泄漏省资源合理利用服务器内存不浪费、不溢出3.2 主流垃圾回收器选择生产必选G1JDK8生产环境强制使用G1收集器放弃默认Parallel、CMSG1优势可预测停顿时间、分代回收、大内存适配、低延迟高吞吐完美适配后端服务适用场景8G及以上服务器内存、高并发、长时间运行的微服务3.3 生产通用JVM参数可直接复制投产适配服务器8G内存、SpringBoot微服务、7×24小时稳定运行# JVM生产最优参数 JDK8 8G服务器java-jar\-Xms4g-Xmx4g\-XX:UseG1GC\-XX:MaxGCPauseMillis200\-XX:MetaspaceSize512m\-XX:MaxMetaspaceSize512m\-XX:HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath/home/logs/oom.dump\-XX:PrintGCDetails\-XX:PrintGCTimeStamps\-Xloggc:/home/logs/gc.log\-jarapp.jar3.4 参数逐行详解吃透原理-Xms4g -Xmx4g初始化堆内存、最大堆内存统一设置避免扩容缩容带来的性能损耗生产必须相等-XX:UseG1GC开启G1垃圾收集器低延迟首选-XX:MaxGCPauseMillis200设置GC最大停顿时间200ms保证接口无明显卡顿Metaspace元空间固定大小避免元空间动态扩容导致的卡顿防止元空间溢出HeapDumpOnOutOfMemoryErrorOOM时自动导出堆快照便于线上问题复盘定位GC日志打印记录GC详情精准分析GC频繁、内存泄漏问题3.5 不同服务器内存适配方案4G服务器-Xms2g -Xmx2g 元空间256m8G服务器-Xms4g -Xmx4g 元空间512m通用标准16G服务器-Xms8g -Xmx8g 元空间512m3.6 高频JVM线上问题与解决方案问题1频繁Full GC根因堆内存过小、内存泄漏、大对象过多、元空间不足解决方案固定堆内存、开启G1、排查静态集合内存泄漏、优化大对象创建问题2服务间歇性卡顿根因GC停顿时间过长、堆内存动态扩容解决方案统一Xms/Xmx、限制G1最大停顿时间问题3OOM内存溢出根因内存泄漏、堆内存不足、无限创建对象、线程堆积解决方案导出dump文件分析、优化代码、合理扩容堆内存四、数据库连接池HikariCP生产调优SpringBoot默认SpringBoot2.x默认使用HikariCP性能远超Druid、Tomcat连接池特点轻量、高效、低延迟但参数配置不当极易出现线上故障。4.1 连接池参数错误的线上危害连接数过小高峰期获取不到连接接口全部超时、报错连接数过大数据库连接数爆满拖垮整个数据库引发全局雪崩超时参数不合理连接空闲失效、频繁重连、IO消耗过高4.2 生产最优HikariCP配置直接投产spring:datasource:# 数据库连接参数url:jdbc:mysql://127.0.0.1:3306/test?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/ShanghaiallowMultiQueriestrueusername:rootpassword:123456driver-class-name:com.mysql.cj.jdbc.Driver# HikariCP生产调优参数hikari:# 最大连接数核心maximum-pool-size:15# 最小空闲连接minimum-idle:5# 连接最大生命周期max-lifetime:1800000# 空闲连接超时时间idle-timeout:600000# 连接超时时间connection-timeout:3000# 开启连接泄露检测leak-detection-threshold:600004.3 核心参数深度解析4.3.1 maximum-pool-size 最大连接数重中之重生产黄金公式最大连接数 CPU核心数 × 2 磁盘数常规4核8G服务器设置10-15为最优禁止超过20误区纠正连接数不是越大越快MySQL单节点承载连接有限过多连接会导致数据库锁竞争、上下文切换频繁整体性能暴跌。4.3.2 其他核心参数minimum-idle最小空闲连接保证低峰期有可用连接避免频繁创建销毁max-lifetime连接最大生命周期30分钟主动回收规避数据库长期空闲连接失效问题connection-timeout连接获取超时3秒快速失败、避免请求长时间阻塞堆积leak-detection-threshold连接泄露检测1分钟未归还连接判定为泄露打印日志便于排查代码问题4.4 连接池高频线上故障排查故障1HikariPool-1 - Connection is not available根因最大连接数不足、接口阻塞导致连接不释放、连接泄露解决方案适当调大最大连接数、开启泄露检测、排查未关闭连接的代码、优化慢SQL故障2数据库连接数爆满根因多个服务连接数设置过大、无连接回收机制解决方案统一各服务连接数上限、配置连接生命周期、监控数据库连接数五、接口慢查询全链路优化90%性能问题根源线上80%的接口超时、服务卡顿、CPU飙高全部来自慢SQL。JVM和连接池调优是兜底SQL优化才是性能提升的核心。5.1 第一步开启慢查询日志精准定位问题5.1.1 MySQL开启慢查询# 查看慢查询状态showvariableslike%slow_query%;# 开启慢查询超过1秒的SQL记录setglobalslow_query_log1;setgloballong_query_time1;5.1.2 SpringBoot开启SQL日志logging:level:com.baomidou.mybatisplus.core.mapper:DEBUGorg.springframework.jdbc:DEBUG5.2 慢SQL通用优化手段5.2.1 索引优化最核心禁止select *只查询需要字段减少IO传输where条件、排序、分组字段必须建立索引遵循最左匹配原则避免索引失效禁止索引失效场景like %xxx、or、null判断、类型转换5.2.2 SQL语句优化大表禁止join关联查询拆分SQL、代码层面关联避免子查询嵌套过深拆分分步查询批量操作使用batch批量插入/更新禁止循环单条操作大分页使用深度分页优化避免limit 100000,105.2.3 业务逻辑优化大列表查询必须分页禁止一次性查询全表数据高频查询、低变更数据加入Redis缓存耗时查询异步化采用消息队列异步处理报表、统计类定时任务离线预计算避免实时统计5.3 慢查询排查完整流程通过慢查询日志、接口监控锁定超时SQLexplain分析SQL执行计划查看是否命中索引、是否全表扫描针对性优化索引、改写SQL语句优化后压测验证响应时间、QPS提升效果六、通用接口性能高阶优化方案6.1 缓存优化兜底高并发本地缓存CaffeineRedis多级缓存减少数据库查询压力缓存预热、过期淘汰、击穿穿透雪崩防护高频静态数据、字典、配置全部缓存化6.2 异步化优化非核心流程异步化日志记录、消息推送、数据统计、文件处理使用Spring异步线程池、RabbitMQ/Kafka解耦主流程核心接口只保留核心业务剥离所有非耗时非必要逻辑6.3 线程池调优自定义业务线程池禁止使用Executors默认线程池核心线程数根据CPU核心数配置避免线程过多上下文切换设置合理队列、拒绝策略防止线程堆积七、线上性能问题快速排查命令运维必备7.1 服务器资源排查# 查看CPU、内存负载top# 查看磁盘IOiostat# 查看网络连接netstat-an|grepESTABLISHED7.2 JVM问题排查# 查看java进程jps-l# 查看线程堆栈排查线程死锁、堆积jstack 进程id# 查看内存使用情况jmap-heap进程id7.3 数据库排查# 查看当前连接数showglobalstatuslikeThreads_connected;# 查看慢查询日志showslow log;八、生产调优上线Checklist逐条核对✅ JVM堆内存固定大小开启G1收集器配置GC日志与OOM快照导出✅ HikariCP连接数合理配置开启连接泄露检测超时参数适配生产✅ 开启MySQL慢查询日志定期巡检慢SQL✅ 核心接口SQL全部命中索引无全表扫描、无索引失效场景✅ 大查询、大列表全部分页处理禁止全表查询✅ 高频查询数据缓存化非核心流程异步化✅ 自定义线程池杜绝线程堆积、死锁问题✅ 上线后压测验证QPS、响应时间、错误率达标九、大厂面试高频问答满分标准答案9.1 JVM调优面试Q生产环境为什么Xms和Xmx要设置相等**A**如果不相等JVM会在内存不足时动态扩容、空闲时缩容频繁的内存调整会触发多次GC造成服务卡顿固定大小可以避免内存动态伸缩提升服务稳定性和性能。QG1收集器的优势是什么为什么生产首选**A**G1支持可预测的GC停顿时间采用分区回收策略兼顾低延迟和高吞吐适合大内存服务能有效避免CMS的内存碎片、停顿时间不可控问题适配微服务7×24小时稳定运行场景。9.2 连接池调优面试Q数据库连接数是不是越大性能越好为什么**A**不是。数据库连接是稀缺资源连接数过大会导致数据库线程竞争激烈、上下文切换频繁、锁等待增多反而大幅降低数据库吞吐量合理的连接数可以最大化利用CPU资源避免资源浪费和数据库雪崩。Q什么是连接泄露如何排查解决**A**连接泄露是代码获取数据库连接后异常场景未关闭连接导致连接无法归还池子最终连接耗尽接口报错通过开启Hikari连接泄露检测日志定位未关闭连接的代码统一finally关闭或使用try-with-resources自动关闭。9.3 慢查询优化面试Q接口响应慢的排查思路是什么**A**1. 查看服务器CPU、内存、IO是否瓶颈2. 查看JVM GC情况排查卡顿问题3. 查看数据库慢查询日志定位耗时SQL4. explain分析执行计划优化索引和SQL5. 优化业务逻辑增加缓存、异步、分页6. 压测验证优化效果。Q如何解决深度分页慢的问题**A**1. 采用主键回溯分页避免limit大偏移量2. 后台分页禁止前端超大页码查询3. 大数据量使用游标分页4. 离线分页预计算缓存分页数据。十、全文总结本文完整落地SpringBoot生产级全方位性能调优方案覆盖JVM、数据库连接池、慢查询、接口优化四大核心模块彻底解决线上服务卡顿、超时、OOM、CPU飙高、连接耗尽等顽疾掌握标准化性能调优流程告别盲目改参数实现数据驱动精准优化落地G1垃圾回收生产参数解决GC卡顿、内存溢出、服务不稳定问题优化HikariCP核心参数杜绝连接耗尽、连接泄露、数据库雪崩风险建立慢查询全链路排查优化体系从根源解决接口性能瓶颈配套通用接口优化、线上排查命令、上线校验清单可直接企业复用覆盖全层级面试考点兼顾工程落地与求职进阶。性能调优是后端高级开发、架构师的核心能力是保障服务高可用、高并发的基石本文全套方案可作为企业统一性能调优规范。 点赞收藏关注专栏持续更新SpringBoot底层原理、生产实战、架构优化、大厂面试硬核干货
SpringBoot系列19：生产环境性能调优：JVM参数、连接池、接口慢查询优化（完整版）
发布时间：2026/7/16 22:02:06
文章目录 专栏SpringBoot进阶实战系列 本文独家核心收获区别于全网水文一、前言为什么生产环境必须做性能调优二、性能调优核心流程生产标准规范2.1 标准调优四步法2.2 常见性能瓶颈优先级三、JVM生产级性能调优解决OOM、GC频繁、服务卡顿3.1 核心调优目标3.2 主流垃圾回收器选择生产必选G13.3 生产通用JVM参数可直接复制投产3.4 参数逐行详解吃透原理3.5 不同服务器内存适配方案3.6 高频JVM线上问题与解决方案问题1频繁Full GC问题2服务间歇性卡顿问题3OOM内存溢出四、数据库连接池HikariCP生产调优SpringBoot默认4.1 连接池参数错误的线上危害4.2 生产最优HikariCP配置直接投产4.3 核心参数深度解析4.3.1 maximum-pool-size 最大连接数重中之重4.3.2 其他核心参数4.4 连接池高频线上故障排查故障1HikariPool-1 - Connection is not available故障2数据库连接数爆满五、接口慢查询全链路优化90%性能问题根源5.1 第一步开启慢查询日志精准定位问题5.1.1 MySQL开启慢查询5.1.2 SpringBoot开启SQL日志5.2 慢SQL通用优化手段5.2.1 索引优化最核心5.2.2 SQL语句优化5.2.3 业务逻辑优化5.3 慢查询排查完整流程六、通用接口性能高阶优化方案6.1 缓存优化兜底高并发6.2 异步化优化6.3 线程池调优七、线上性能问题快速排查命令运维必备7.1 服务器资源排查7.2 JVM问题排查7.3 数据库排查八、生产调优上线Checklist逐条核对九、大厂面试高频问答满分标准答案9.1 JVM调优面试9.2 连接池调优面试9.3 慢查询优化面试十、全文总结 专栏SpringBoot进阶实战系列文章评级生产落地调优 底层原理拆解 问题定位闭环 高并发适配 面试全覆盖 适用人群后端开发、性能优化、线上故障排查、微服务调优、面试进阶、服务稳定性保障 前置基础SpringBoot项目部署、Linux基础命令、MySQL基础、JVM基础概念️ 文章标签#SpringBoot #性能调优 #JVM调优 #数据库连接池 #慢查询优化 #接口优化 #服务稳定性 本文独家核心收获区别于全网水文调优思维建立掌握「先定位瓶颈、再精准调优、最后压测验证」的生产标准调优流程拒绝盲目改参数JVM生产级调优吃透内存模型、垃圾回收机制给出高并发低延迟专属JVM参数解决OOM、GC频繁、卡顿问题连接池精准配置详解HikariCP核心参数解决连接泄露、连接超时、并发阻塞、资源浪费等线上顽疾慢查询全链路优化从日志排查、SQL分析、索引优化、业务重构、兜底方案全方位解决接口慢、超时、堆积问题通用接口性能优化缓存、异步、分页、限流、批量操作等企业通用优化手段适配所有业务接口线上故障快速排查汇总CPU飙高、内存溢出、接口超时、数据库阻塞全套排查方案面试满分题库覆盖JVM调优、连接池原理、慢查询优化、高并发性能架构高频考点一、前言为什么生产环境必须做性能调优很多本地正常运行的SpringBoot项目一旦上线生产就会出现各种诡异问题接口超时、服务卡顿、CPU持续飙高、内存溢出、数据库连接爆满、高峰期请求雪崩。根本原因本地开发参数默认适配小流量生产高并发、大流量、长连接场景完全不适用。默认参数只能保证项目能跑不能保证项目稳跑、快跑。性能调优不是玄学是数据驱动的精准优化核心优化三板斧JVM调优解决内存溢出、GC卡顿、线程阻塞、资源占用过高问题连接池调优解决数据库连接耗尽、连接超时、频繁创建销毁连接问题业务SQL调优解决慢查询、数据库CPU飙高、接口响应慢、堆积超时问题本文所有参数、方案均经过线上高并发项目验证可直接复制投产同时配套完整原理知其然更知其所以然。二、性能调优核心流程生产标准规范所有性能问题必须遵循以下流程禁止盲目修改参数2.1 标准调优四步法第一步监控观测通过监控、日志、命令定位瓶颈CPU/内存/IO/数据库/接口第二步问题定位精准锁定是JVM问题、连接池问题还是SQL业务问题第三步精准调优针对性修改参数、优化代码、重构SQL第四步压测验证压测对比QPS、响应时间、错误率确认优化生效2.2 常见性能瓶颈优先级90%的线上性能问题都出自以下三点优先级从高到低数据库慢查询最常见、影响最大单条慢SQL拖垮整个服务连接池参数不合理连接数过小阻塞请求过大浪费资源、导致数据库崩库JVM参数不当GC频繁、内存溢出、线程堆积、服务卡顿三、JVM生产级性能调优解决OOM、GC频繁、服务卡顿3.1 核心调优目标JVM调优不是把内存调越大越好生产核心目标低延迟减少Full GC频率避免服务卡顿高吞吐提升垃圾回收效率支撑高并发稳运行彻底杜绝OOM内存溢出、内存泄漏省资源合理利用服务器内存不浪费、不溢出3.2 主流垃圾回收器选择生产必选G1JDK8生产环境强制使用G1收集器放弃默认Parallel、CMSG1优势可预测停顿时间、分代回收、大内存适配、低延迟高吞吐完美适配后端服务适用场景8G及以上服务器内存、高并发、长时间运行的微服务3.3 生产通用JVM参数可直接复制投产适配服务器8G内存、SpringBoot微服务、7×24小时稳定运行# JVM生产最优参数 JDK8 8G服务器java-jar\-Xms4g-Xmx4g\-XX:UseG1GC\-XX:MaxGCPauseMillis200\-XX:MetaspaceSize512m\-XX:MaxMetaspaceSize512m\-XX:HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath/home/logs/oom.dump\-XX:PrintGCDetails\-XX:PrintGCTimeStamps\-Xloggc:/home/logs/gc.log\-jarapp.jar3.4 参数逐行详解吃透原理-Xms4g -Xmx4g初始化堆内存、最大堆内存统一设置避免扩容缩容带来的性能损耗生产必须相等-XX:UseG1GC开启G1垃圾收集器低延迟首选-XX:MaxGCPauseMillis200设置GC最大停顿时间200ms保证接口无明显卡顿Metaspace元空间固定大小避免元空间动态扩容导致的卡顿防止元空间溢出HeapDumpOnOutOfMemoryErrorOOM时自动导出堆快照便于线上问题复盘定位GC日志打印记录GC详情精准分析GC频繁、内存泄漏问题3.5 不同服务器内存适配方案4G服务器-Xms2g -Xmx2g 元空间256m8G服务器-Xms4g -Xmx4g 元空间512m通用标准16G服务器-Xms8g -Xmx8g 元空间512m3.6 高频JVM线上问题与解决方案问题1频繁Full GC根因堆内存过小、内存泄漏、大对象过多、元空间不足解决方案固定堆内存、开启G1、排查静态集合内存泄漏、优化大对象创建问题2服务间歇性卡顿根因GC停顿时间过长、堆内存动态扩容解决方案统一Xms/Xmx、限制G1最大停顿时间问题3OOM内存溢出根因内存泄漏、堆内存不足、无限创建对象、线程堆积解决方案导出dump文件分析、优化代码、合理扩容堆内存四、数据库连接池HikariCP生产调优SpringBoot默认SpringBoot2.x默认使用HikariCP性能远超Druid、Tomcat连接池特点轻量、高效、低延迟但参数配置不当极易出现线上故障。4.1 连接池参数错误的线上危害连接数过小高峰期获取不到连接接口全部超时、报错连接数过大数据库连接数爆满拖垮整个数据库引发全局雪崩超时参数不合理连接空闲失效、频繁重连、IO消耗过高4.2 生产最优HikariCP配置直接投产spring:datasource:# 数据库连接参数url:jdbc:mysql://127.0.0.1:3306/test?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/ShanghaiallowMultiQueriestrueusername:rootpassword:123456driver-class-name:com.mysql.cj.jdbc.Driver# HikariCP生产调优参数hikari:# 最大连接数核心maximum-pool-size:15# 最小空闲连接minimum-idle:5# 连接最大生命周期max-lifetime:1800000# 空闲连接超时时间idle-timeout:600000# 连接超时时间connection-timeout:3000# 开启连接泄露检测leak-detection-threshold:600004.3 核心参数深度解析4.3.1 maximum-pool-size 最大连接数重中之重生产黄金公式最大连接数 CPU核心数 × 2 磁盘数常规4核8G服务器设置10-15为最优禁止超过20误区纠正连接数不是越大越快MySQL单节点承载连接有限过多连接会导致数据库锁竞争、上下文切换频繁整体性能暴跌。4.3.2 其他核心参数minimum-idle最小空闲连接保证低峰期有可用连接避免频繁创建销毁max-lifetime连接最大生命周期30分钟主动回收规避数据库长期空闲连接失效问题connection-timeout连接获取超时3秒快速失败、避免请求长时间阻塞堆积leak-detection-threshold连接泄露检测1分钟未归还连接判定为泄露打印日志便于排查代码问题4.4 连接池高频线上故障排查故障1HikariPool-1 - Connection is not available根因最大连接数不足、接口阻塞导致连接不释放、连接泄露解决方案适当调大最大连接数、开启泄露检测、排查未关闭连接的代码、优化慢SQL故障2数据库连接数爆满根因多个服务连接数设置过大、无连接回收机制解决方案统一各服务连接数上限、配置连接生命周期、监控数据库连接数五、接口慢查询全链路优化90%性能问题根源线上80%的接口超时、服务卡顿、CPU飙高全部来自慢SQL。JVM和连接池调优是兜底SQL优化才是性能提升的核心。5.1 第一步开启慢查询日志精准定位问题5.1.1 MySQL开启慢查询# 查看慢查询状态showvariableslike%slow_query%;# 开启慢查询超过1秒的SQL记录setglobalslow_query_log1;setgloballong_query_time1;5.1.2 SpringBoot开启SQL日志logging:level:com.baomidou.mybatisplus.core.mapper:DEBUGorg.springframework.jdbc:DEBUG5.2 慢SQL通用优化手段5.2.1 索引优化最核心禁止select *只查询需要字段减少IO传输where条件、排序、分组字段必须建立索引遵循最左匹配原则避免索引失效禁止索引失效场景like %xxx、or、null判断、类型转换5.2.2 SQL语句优化大表禁止join关联查询拆分SQL、代码层面关联避免子查询嵌套过深拆分分步查询批量操作使用batch批量插入/更新禁止循环单条操作大分页使用深度分页优化避免limit 100000,105.2.3 业务逻辑优化大列表查询必须分页禁止一次性查询全表数据高频查询、低变更数据加入Redis缓存耗时查询异步化采用消息队列异步处理报表、统计类定时任务离线预计算避免实时统计5.3 慢查询排查完整流程通过慢查询日志、接口监控锁定超时SQLexplain分析SQL执行计划查看是否命中索引、是否全表扫描针对性优化索引、改写SQL语句优化后压测验证响应时间、QPS提升效果六、通用接口性能高阶优化方案6.1 缓存优化兜底高并发本地缓存CaffeineRedis多级缓存减少数据库查询压力缓存预热、过期淘汰、击穿穿透雪崩防护高频静态数据、字典、配置全部缓存化6.2 异步化优化非核心流程异步化日志记录、消息推送、数据统计、文件处理使用Spring异步线程池、RabbitMQ/Kafka解耦主流程核心接口只保留核心业务剥离所有非耗时非必要逻辑6.3 线程池调优自定义业务线程池禁止使用Executors默认线程池核心线程数根据CPU核心数配置避免线程过多上下文切换设置合理队列、拒绝策略防止线程堆积七、线上性能问题快速排查命令运维必备7.1 服务器资源排查# 查看CPU、内存负载top# 查看磁盘IOiostat# 查看网络连接netstat-an|grepESTABLISHED7.2 JVM问题排查# 查看java进程jps-l# 查看线程堆栈排查线程死锁、堆积jstack 进程id# 查看内存使用情况jmap-heap进程id7.3 数据库排查# 查看当前连接数showglobalstatuslikeThreads_connected;# 查看慢查询日志showslow log;八、生产调优上线Checklist逐条核对✅ JVM堆内存固定大小开启G1收集器配置GC日志与OOM快照导出✅ HikariCP连接数合理配置开启连接泄露检测超时参数适配生产✅ 开启MySQL慢查询日志定期巡检慢SQL✅ 核心接口SQL全部命中索引无全表扫描、无索引失效场景✅ 大查询、大列表全部分页处理禁止全表查询✅ 高频查询数据缓存化非核心流程异步化✅ 自定义线程池杜绝线程堆积、死锁问题✅ 上线后压测验证QPS、响应时间、错误率达标九、大厂面试高频问答满分标准答案9.1 JVM调优面试Q生产环境为什么Xms和Xmx要设置相等**A**如果不相等JVM会在内存不足时动态扩容、空闲时缩容频繁的内存调整会触发多次GC造成服务卡顿固定大小可以避免内存动态伸缩提升服务稳定性和性能。QG1收集器的优势是什么为什么生产首选**A**G1支持可预测的GC停顿时间采用分区回收策略兼顾低延迟和高吞吐适合大内存服务能有效避免CMS的内存碎片、停顿时间不可控问题适配微服务7×24小时稳定运行场景。9.2 连接池调优面试Q数据库连接数是不是越大性能越好为什么**A**不是。数据库连接是稀缺资源连接数过大会导致数据库线程竞争激烈、上下文切换频繁、锁等待增多反而大幅降低数据库吞吐量合理的连接数可以最大化利用CPU资源避免资源浪费和数据库雪崩。Q什么是连接泄露如何排查解决**A**连接泄露是代码获取数据库连接后异常场景未关闭连接导致连接无法归还池子最终连接耗尽接口报错通过开启Hikari连接泄露检测日志定位未关闭连接的代码统一finally关闭或使用try-with-resources自动关闭。9.3 慢查询优化面试Q接口响应慢的排查思路是什么**A**1. 查看服务器CPU、内存、IO是否瓶颈2. 查看JVM GC情况排查卡顿问题3. 查看数据库慢查询日志定位耗时SQL4. explain分析执行计划优化索引和SQL5. 优化业务逻辑增加缓存、异步、分页6. 压测验证优化效果。Q如何解决深度分页慢的问题**A**1. 采用主键回溯分页避免limit大偏移量2. 后台分页禁止前端超大页码查询3. 大数据量使用游标分页4. 离线分页预计算缓存分页数据。十、全文总结本文完整落地SpringBoot生产级全方位性能调优方案覆盖JVM、数据库连接池、慢查询、接口优化四大核心模块彻底解决线上服务卡顿、超时、OOM、CPU飙高、连接耗尽等顽疾掌握标准化性能调优流程告别盲目改参数实现数据驱动精准优化落地G1垃圾回收生产参数解决GC卡顿、内存溢出、服务不稳定问题优化HikariCP核心参数杜绝连接耗尽、连接泄露、数据库雪崩风险建立慢查询全链路排查优化体系从根源解决接口性能瓶颈配套通用接口优化、线上排查命令、上线校验清单可直接企业复用覆盖全层级面试考点兼顾工程落地与求职进阶。性能调优是后端高级开发、架构师的核心能力是保障服务高可用、高并发的基石本文全套方案可作为企业统一性能调优规范。 点赞收藏关注专栏持续更新SpringBoot底层原理、生产实战、架构优化、大厂面试硬核干货
