Spring Boot 性能优化实战：从启动加速到运行时调优

1. 引言：性能优化不是玄学，而是工程

很多团队在 Spring Boot 项目上线后才发现：启动要 40 秒、接口 P99 抖动、数据库连接池频繁告警、GC 日志里 Full GC 时不时来一发。于是开始"凭感觉调参"------把 maximumPoolSize 从 10 改成 50，把堆内存从 2G 加到 8G，结果问题依旧。

性能优化的本质是先测量、再定位、后优化、最后验证的闭环工程。本文给出一套系统化的方法论，并附上一份可以直接照着做的优化清单，覆盖启动、连接池、JVM、数据库、接口层、日志六大方向。

2. 性能优化方法论：先有基线，再谈优化

2.1 建立压测基线

没有基线的优化都是自嗨。上线前必须固化一组可复现的压测数据：

指标	说明	采集方式
启动耗时	从 main 到 Started Application	启动日志时间戳
QPS / TPS	单位时间处理请求数	JMeter / wrk / Gatling
P50 / P95 / P99 延迟	分位响应时间	压测工具报告
错误率	非 2xx 响应占比	压测工具报告
CPU / 内存 / GC	运行时资源画像	Prometheus + Grafana
慢 SQL 数量	超过阈值的 SQL 条数	Druid / p6spy

压测环境要尽量贴近生产：同样的 JVM 参数、同样的数据库数据量、同样的机器规格。否则基线毫无参考价值。

2.2 定位瓶颈的四个层次

flowchart TD A["压测发现指标异常"] --> B{"瓶颈在哪一层"} B -->|"CPU 高、GC 频繁"| C["JVM 层：堆大小 / GC 选型"] B -->|"线程阻塞、连接等待"| D["资源层：连接池 / 线程池"] B -->|"SQL 慢、锁等待"| E["数据库层：慢 SQL / 索引"] B -->|"启动慢、内存占用高"| F["应用层：扫描范围 / 自动配置"] C --> G["针对性优化"] D --> G E --> G F --> G G --> H["回归压测验证"]

定位工具推荐：

• CPU 热点 ：async-profiler 火焰图，比 JProfiler 更轻量、对生产更友好。
• 线程阻塞 ：jstack 多次采样，看线程状态分布。
• GC 问题 ：-Xlog:gc* 输出 GC 日志，用 GCViewer 分析。
• SQL 问题 ：开启慢查询日志 + EXPLAIN 执行计划。

3. 启动优化：把 40 秒压到 10 秒

3.1 限定组件扫描范围

@SpringBootApplication 默认扫描启动类所在包及其子包。如果启动类放在 com.example 这种顶层包下，就会把整个工程甚至第三方包都扫一遍。

// 不推荐：扫描范围过大
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

// 推荐：显式限定扫描范围
@SpringBootApplication(scanBasePackages = {
        "com.example.order",
        "com.example.common"
})
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

同时检查 @ComponentScan、@EntityScan、@EnableJpaRepositories 是否也用了过大的包路径。

3.2 延迟初始化

Spring Boot 2.2 起支持全局延迟初始化，把非必需的 Bean 推迟到首次使用时创建，能显著缩短启动时间：

spring:
  main:
    lazy-initialization: true

注意：延迟初始化会把部分启动期错误推迟到运行期暴露，建议只在开发/测试环境或启动时间敏感的场景开启 ，并对关键 Bean 用 @Lazy(false) 显式排除。

3.3 排除无用的自动配置

引入一个 starter 就会带来一串自动配置。用 --debug 启动可以看到 CONDITIONS EVALUATION REPORT，据此排除不需要的配置：

@SpringBootApplication(exclude = {
        DataSourceAutoConfiguration.class,
        SecurityAutoConfiguration.class,
        MailSenderAutoConfiguration.class
})
public class Application {
}

或者用配置文件方式：

spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration
      - org.springframework.boot.autoconfigure.mail.MailSenderAutoConfiguration

3.4 其他启动加速手段

• 用 spring-boot-maven-plugin 的 layers 分层打包，配合 Docker 缓存减少镜像构建与拉取时间。
• 关闭不必要的 spring.devtools、spring-boot-actuator 端点。
• 升级到 Spring Boot 3.x + JDK 17+，类加载与 AOT 支持更好；必要时可尝试 GraalVM Native Image（启动可到百毫秒级，但生态兼容性需评估）。

启动优化的整体思路可以概括为「少扫描、少加载、晚创建」，下图展示了各手段的作用位置：

flowchart TD A["Spring Boot 启动慢"] --> B["减少扫描范围"] A --> C["减少自动配置加载"] A --> D["推迟 Bean 创建"] B --> B1["scanBasePackages 限定包路径"] B --> B2["检查 @EntityScan / @EnableJpaRepositories"] C --> C1["--debug 查看条件评估报告"] C --> C2["exclude 排除无用自动配置"] D --> D1["lazy-initialization 全局延迟"] D --> D2["@Lazy(false) 排除关键 Bean"] B1 --> E["启动耗时下降"] B2 --> E C1 --> E C2 --> E D1 --> E D2 --> E

4. 连接池调优：HikariCP 与业务并发量匹配

4.1 核心参数

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 10
      connection-timeout: 3000
      idle-timeout: 600000
      max-lifetime: 1800000
      leak-detection-threshold: 60000

4.2 maximumPoolSize 怎么算

这是最容易被拍脑袋设置的参数。经验公式：

连接数 ≈ CPU 核数 × 2 + 有效磁盘数

但更准确的做法是用压测找拐点 ：固定其他变量，把 maximumPoolSize 从 5 逐步调到 50，观察 QPS 与 P99。通常会出现一个明显的拐点，超过后 QPS 不再上升、延迟反而恶化------那就是数据库的并发处理上限。

几个常见误区：

• 连接池越大越好？ 错。连接数超过数据库处理能力后，只会增加上下文切换与锁竞争。
• minimum-idle 设成和 maximum-pool-size 一样？ 可以，能避免突发流量时的建连开销，但会长期占用数据库连接。
• 忽略 max-lifetime？ 数据库或中间件（如 ProxySQL、RDS）通常有连接空闲超时，max-lifetime 必须小于它，否则会拿到已被服务端关闭的"死连接"。

连接池大小与 QPS 的关系通常呈现「先升后平、再升则降」的曲线，下图是压测找拐点的示意：

flowchart LR A["maximumPoolSize = 5"] --> B["逐步加压至 10 / 20 / 30"] B --> C{"QPS 是否继续上升"} C -->|"上升"| D["继续增大连接数"] C -->|"持平或下降"| E["拐点即数据库并发上限"] D --> B E --> F["取拐点略偏小的值作为配置"]

4.3 监控连接池状态

通过 Actuator 暴露 Hikari 指标：

management:
  endpoints:
    web:
      exposure:
        include: health,metrics,prometheus
  metrics:
    tags:
      application: ${spring.application.name}

重点关注 hikaricp.connections.active、hikaricp.connections.pending、hikaricp.connections.timeout。pending 长期大于 0 说明连接不够用，timeout 增长说明获取连接超时严重。

5. JVM 调优：堆内存、GC 选型与停顿控制

5.1 堆内存设置

java -Xms4g -Xmx4g \
     -XX:MetaspaceSize=256m \
     -XX:MaxMetaspaceSize=512m \
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/data/dump \
     -jar app.jar

要点：

• -Xms 与 -Xmx 设为相同值，避免堆动态扩缩带来的抖动。
• 堆大小一般不超过物理内存的 50%~70%，给堆外内存（Netty Direct Buffer、Metaspace、线程栈）留出空间。
• 容器环境下务必设置 -XX:MaxRAMPercentage，让 JVM 感知 cgroup 限制：

java -XX:MaxRAMPercentage=70.0 -XX:InitialRAMPercentage=70.0 -jar app.jar

5.2 G1 vs ZGC 选型

维度	G1	ZGC
适用堆大小	4G ~ 32G	8G ~ 数 TB
停顿目标	可设 MaxGCPauseMillis，通常 50~200ms	亚毫秒级（<1ms）
吞吐量	较高	略低于 G1（有染色指针开销）
JDK 要求	JDK 9+ 默认	JDK 17+ 生产可用，JDK 21 分代 ZGC 更成熟
适用场景	大多数 Web 服务	大堆、低延迟敏感型服务

G1 常用参数：

-XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-XX:G1HeapRegionSize=8m \
-XX:InitiatingHeapOccupancyPercent=45

ZGC 常用参数：

-XX:+UseZGC \
-XX:+ZGenerational \
-Xmx16g

选型建议：堆小于 8G、延迟要求不极端，用 G1；堆大于 16G 或 P99 对 GC 停顿敏感，用 ZGC。切换后必须重新压测，不要只看 GC 日志好看就下结论。

GC 选型可以按下面的决策路径快速判断：

flowchart TD A["确定堆大小与延迟目标"] --> B{"堆是否大于 16G"} B -->|"否"| C{"P99 对 GC 停顿是否敏感"} B -->|"是"| D["优先 ZGC"] C -->|"不敏感"| E["G1 + MaxGCPauseMillis"] C -->|"敏感"| D D --> F["JDK 17+ 开启 ZGC，JDK 21 用分代 ZGC"] E --> G["切换后重新压测验证"] F --> G

5.3 停顿时间优化思路

• 减少对象分配：避免在热点路径上创建大对象、避免循环内字符串拼接。
• 控制大对象：超过 Region 一半的对象会进入 Humongous 区，容易触发 Full GC。
• 排查内存泄漏：用 jmap -histo:live 或 MAT 分析堆转储，找出持续增长的集合。

6. 数据库层优化：慢 SQL、索引与读写分离

6.1 慢 SQL 识别

开启慢查询日志（MySQL）：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 'ON';

应用侧可以用 p6spy 打印带真实参数的 SQL，避免 ? 占位符导致无法定位：

# application.yml
spring:
  datasource:
    driver-class-name: com.p6spy.engine.spy.P6SpyDriver
    url: jdbc:p6spy:mysql://localhost:3306/demo

6.2 索引设计原则

• 最左前缀 ：联合索引 (a, b, c) 能命中 a、a,b、a,b,c，但命中不了 b 或 c 单独查询。
• 区分度优先：把区分度高的列放在联合索引前面。
• 避免索引失效 ：不要在索引列上做函数运算、隐式类型转换、LIKE '%xxx' 前置模糊匹配。
• 覆盖索引：查询列全部包含在索引中，避免回表。

用 EXPLAIN 检查执行计划，重点关注 type（至少到 range）、key（是否命中索引）、rows（扫描行数）、Extra（是否出现 Using filesort、Using temporary）。

6.3 读写分离接入

Spring Boot 中常用 AbstractRoutingDataSource 实现动态数据源路由：

public class RoutingDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return DataSourceContextHolder.get();
    }
}

public class DataSourceContextHolder {
    private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();

    public static void set(String key) { CONTEXT.set(key); }
    public static String get() { return CONTEXT.get(); }
    public static void clear() { CONTEXT.remove(); }
}

配合自定义注解 + AOP，在方法上标注 @ReadOnly 时切到从库，方法结束后清理 ThreadLocal。注意主从延迟问题：写后立即读的场景必须强制走主库。

读写分离的请求路由流程如下：

flowchart TD A["业务方法调用"] --> B{"是否标注 @ReadOnly"} B -->|"是"| C["ThreadLocal 标记 slave"] B -->|"否"| D["ThreadLocal 标记 master"] C --> E["AbstractRoutingDataSource 路由"] D --> E E --> F["执行 SQL"] F --> G["方法结束清理 ThreadLocal"] G --> H{"是否写后立即读"} H -->|"是"| I["强制走主库，规避主从延迟"] H -->|"否"| J["正常返回"]

7. 接口层优化：异步、压缩与连接复用

7.1 异步处理

对于耗时且非强一致的逻辑（发短信、写日志、生成报表），用 @Async 或消息队列异步化：

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean("bizExecutor")
    public Executor bizExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(8);
        executor.setMaxPoolSize(16);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("biz-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

@Service
public class NotifyService {

    @Async("bizExecutor")
    public void sendAsync(Long userId, String msg) {
        // 发送通知
    }
}

注意：@Async 方法必须是 public、由 Spring 代理调用（同类内部调用不生效），且线程池必须自定义，不要用默认的 SimpleAsyncTaskExecutor（每次新建线程）。

Spring MVC 还支持返回 Callable / DeferredResult / WebFlux 实现请求级异步，释放 Tomcat 工作线程。

同步与异步处理的线程占用对比：

sequenceDiagram participant C as "客户端" participant T as "Tomcat 工作线程" participant P as "业务线程池" participant D as "下游服务" C->>T: "发起请求" T->>P: "提交异步任务" T-->>C: "立即返回（或等待结果）" P->>D: "执行耗时逻辑" D-->>P: "返回结果" P-->>C: "回调 / 结果推送"

7.2 响应压缩

server:
  compression:
    enabled: true
    min-response-size: 2KB
    mime-types: application/json,application/xml,text/html,text/plain

对 JSON 接口效果明显，通常能压缩 60%~80% 的传输体积。注意：图片、视频等已压缩格式不要加入 mime-types。

7.3 HTTP 连接复用

• 服务端 ：Tomcat 默认开启 keep-alive，检查 server.tomcat.max-keep-alive-requests 与 connection-timeout 是否合理。
• 客户端 ：使用 RestTemplate / WebClient 时，底层 HTTP 客户端必须配置连接池，否则每次请求都新建 TCP 连接：

@Bean
public RestTemplate restTemplate() {
    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
    cm.setMaxTotal(200);
    cm.setDefaultMaxPerRoute(50);

    RequestConfig config = RequestConfig.custom()
            .setConnectTimeout(2000)
            .setSocketTimeout(5000)
            .setConnectionRequestTimeout(1000)
            .build();

    CloseableHttpClient client = HttpClients.custom()
            .setConnectionManager(cm)
            .setDefaultRequestConfig(config)
            .build();

    return new RestTemplate(new HttpComponentsClientHttpRequestFactory(client));
}

8. 日志优化：异步、级别与字符串拼接

8.1 异步追加器

同步日志会阻塞业务线程，尤其在高并发下磁盘 IO 成为瓶颈。Logback 配置异步 Appender：

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logs/app.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>logs/app.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>15</maxHistory>
            <totalSizeCap>5GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="ASYNC_FILE" class="ch.qos.logback.classic.AsyncAppender">
        <queueSize>1024</queueSize>
        <discardingThreshold>0</discardingThreshold>
        <neverBlock>true</neverBlock>
        <appender-ref ref="FILE"/>
    </appender>

    <root level="INFO">
        <appender-ref ref="ASYNC_FILE"/>
    </root>
</configuration>

discardingThreshold=0 表示队列满时也不丢弃 INFO 及以下日志；neverBlock=true 表示队列满时直接丢弃而不是阻塞业务线程------这两个参数需要根据业务对日志完整性的要求权衡。

8.2 级别控制

• 生产环境根级别设为 INFO，框架包（如 org.springframework、com.zaxxer.hikari）可设为 WARN。
• 用 logging.level.xxx=DEBUG 按包精细控制，避免全局 DEBUG。
• 支持动态调整：接入 Actuator 的 loggers 端点，无需重启即可改级别。

8.3 避免字符串拼接

// 错误：无论日志级别是否开启，字符串都会拼接
log.debug("user=" + userId + ", order=" + orderId);

// 正确：使用占位符，级别不满足时不会执行 toString
log.debug("user={}, order={}", userId, orderId);

// 需要复杂计算时用条件判断
if (log.isDebugEnabled()) {
    log.debug("detail={}", buildExpensiveDetail());
}

9. 优化效果验证：压测对比与监控追踪

9.1 压测工具对比

工具	特点	适用场景
JMeter	图形化、插件丰富、支持复杂场景编排	功能级压测、回归测试
wrk	轻量、高并发、Lua 脚本扩展	单接口极限 QPS 测试
Gatling	Scala DSL、报告精美、支持持续压测	CI 集成、性能回归
k6	JS 脚本、云原生友好	DevOps 流水线

压测时注意：压测机不能成为瓶颈，客户端与服务端分离部署；逐步加压（如每 30 秒增加 10 并发），观察拐点而非直接打满。

9.2 关键监控指标

flowchart LR A["应用指标"] --> D["统一监控看板"] B["JVM 指标"] --> D C["数据库指标"] --> D A --> A1["QPS / P99 / 错误率"] B --> B1["堆使用率 / GC 次数 / GC 停顿"] C --> C1["慢 SQL / 连接数 / 锁等待"]

推荐技术栈：Micrometer + Prometheus + Grafana 。Spring Boot Actuator 已内置 Micrometer，只需暴露 prometheus 端点即可采集。

需要重点盯的指标：

• http_server_requests_seconds：接口延迟分布，看 P99 而非平均值。
• jvm_gc_pause_seconds：GC 停顿时间与次数。
• jvm_memory_used_bytes：各内存区使用量。
• hikaricp_connections_pending：等待连接的线程数。
• system_cpu_usage：系统 CPU 使用率。

9.3 优化前后对比表

每次优化后都要回归压测，并记录对比数据：

优化项	优化前	优化后	提升
启动耗时	42s	11s	-74%
接口 P99	380ms	120ms	-68%
慢 SQL 数量（1s 阈值）	156 条/小时	3 条/小时	-98%
Full GC 次数（1 小时）	12 次	0 次	-100%

10. 优化清单速查

• 已建立可复现的压测基线（QPS、P50/P95/P99、错误率、资源画像）
• 已用 async-profiler / jstack / GC 日志定位到具体瓶颈层
• @SpringBootApplication 已限定 scanBasePackages
• 已排除无用的自动配置（通过 --debug 报告确认）
• 启动时间敏感场景已评估 lazy-initialization
• HikariCP maximumPoolSize 已通过压测找拐点确定
• max-lifetime 小于数据库/中间件的连接空闲超时
• -Xms 与 -Xmx 一致，容器环境使用 MaxRAMPercentage
• GC 选型与堆大小匹配，切换后已重新压测
• 慢查询日志已开启，慢 SQL 已逐条 EXPLAIN 分析
• 联合索引遵循最左前缀，无索引失效场景
• 读写分离已处理主从延迟（写后读强制走主库）
• 耗时非核心逻辑已异步化，线程池已自定义
• 已开启响应压缩，mime-types 不含已压缩格式
• HTTP 客户端已配置连接池与超时
• 日志使用异步 Appender，生产级别为 INFO
• 日志使用占位符而非字符串拼接
• 已接入 Micrometer + Prometheus + Grafana 监控
• 每次优化后都有前后对比数据

11. 总结

Spring Boot 性能优化没有银弹，核心是建立基线 → 定位瓶颈 → 单点优化 → 回归验证的循环。启动优化靠"减法"（少扫描、少加载），运行时优化靠"匹配"（连接池匹配并发、GC 匹配堆大小、索引匹配查询模式），而所有优化都必须用数据说话。

建议从本文清单中挑出 3~5 项对当前系统影响最大的先做，每做完一项就压测一次、记录一次，逐步积累属于自己系统的性能画像。