企业官网建设流程全解析

1. 性能瓶颈到底在哪：先用数据说人话

接手这个项目的时候，运维给的反馈很直接：服务重启不到半小时内存就逼近上限，CPU 每过几分钟就来一次尖峰，压测时接口的平均响应时间看着还行，但 TP99 和 TP999 完全是失控状态。更闹心的是，服务明明只跑了一个简单的权限系统加几条业务链路的 CRUD，JVM 堆却常年顶在 2GB 线上舍不得下来。我用 jstat 看了一眼年轻代和老年代的使用曲线，基本可以用“尸横遍野”来形容——对象疯狂创建、疯狂晋升，垃圾回收器忙得焦头烂额，业务线程反而在排队等内存。

先说结论：绝大多数 Spring Boot 应用资源占用虚高的原因，并不是业务逻辑有多复杂，而是默认配置、容器模型、依赖装配这三层“基础底座”在替业务背着不该背的锅。Spring Boot 默认不是性能调优后的形态，它是一个“为了兼容各种启动场景而做出的中间妥协形态”。你想让它真正高效跑起来，必须亲手把这些默认策略替换成匹配实际负载的定制策略。

这次做“彻底重绘”的首要思路是：先量化瓶颈，再逐项改造。我不会盲猜“哪个环节慢”，而是用工具把内存分配、线程数量、GC 压力、IO 等待全部拉出来量化。全链路下来，资源占用从优化前的 100% 降到优化后的 20% 左右，这个 80% 的缩减比例不是估算出来的，是一步一步实测压出来的。

全程我会讲清楚每一层为什么这么改、依据是什么、数据变化长什么样，以及哪些坑是常规文档里根本不会告诉你的。

1.1 第一步不是调参数，而是先量化堆和线程

任何性能优化工程，第一步都应该是建立基线，而不是伸手改配置。我先把服务跑起来，加了几个关键 JVM 参数做观测，然后让压测工具模拟日常负载跑 30 分钟：

java -javaagent:/path/to/async-profiler/build/async-profiler.jar=alloc,cpu \ -XX:StartFlightRecording=delay=20s,duration=120s,filename=app.jfr \ -Xlog:gc*:file=gc.log:time,uptime,level,tags \ -jar app.jar

这里我用了 async-profiler 采集 CPU 和内存分配热点，同时开了 JFR 录制 GC 与线程信息。不用任何可视化平台，先从原始数据里捞结论。

采集完之后，我用jfr print --events jdk.ThreadAllocationStatistics app.jfr | head -n 100看各线程的分配总量排名，再用jfr print --events jdk.GCHeapSummary看 GC 后的堆大小趋势。这一步很快就锁定了几个明显问题：

• 有一批名为tomcat-exec-*的工作线程，线程栈分配内存占用排在最前面，数量多、每条线程的栈内存就这么静悄悄地待在堆外。
• 堆上占比最大的对象类型不是业务实体，而是char[]、byte[]以及 Spring 内部的各种元数据缓存对象。
• GC 日志里G1 Young Generation的停顿频率很高，但回收效率极低，因为大量生命周期很长的对象都在年轻代里被反复拷贝。

你没有看错：在 Spring Boot 这种“启动器+注解驱动”的框架生态里，框架自身的运行时开销往往比业务代码更早吃掉内存预算。这一条，是所有性能优化工作的起点认知。

1.2 从 100% 到 20% 的整体优化路线图

在动手之前，我把这次“重绘”梳理成五个主攻方向，整条链路各司其职：

• 线程模型与容器调优：改内嵌 Tomcat 的线程池策略、切换虚拟线程、去掉冗余的阻塞等待。
• 数据访问层瘦身：重新设计连接池参数、分页查询、批量写入，让数据库连接数和事务持有时间彻底降下来。
• 缓存策略重构：引入本地缓存 Caffeine，给高频读接口再做一层防御，降低重复计算与重复 IO。
• 日志与依赖装配收敛：关闭不必要的自动配置、改造 logback 为异步追加、剔除重复的 Bean 装配。
• JVM 与部署参数精调：把堆内存策略从“大而全”改成“小而稳”，匹配真实负载曲线。

其中一路下来，改造点和对应收益我用一张表先给全体项目成员对齐：

不要觉得这些数字夸张。很多优化动作叠在一起，收益不是加法，而是乘法。启动时内存占用大，运行时内存分配频繁，GC 压力自然就高；GC 一高，线程等待时间就长；线程一多，栈内存占用就上去了。这是个环环相扣的恶性循环，解开一环，后面几环都会跟着松动。

2. 容器改造：Tomcat 线程模型是内存消耗的大户

Spring Boot 默认内嵌的 Web 容器是 Tomcat，而且默认使用的是同步阻塞 IO + 线程池模型。这套模型的潜台词是：每个请求在处理的整个生命周期，都要独占一个工作线程。那么天然的算法就是：

Tomcat 默认最大线程数 = 200 每线程栈大小 = 1MB 理论上线程栈内存占用峰值 = 200MB

是不是看上去还不算高？实际远不止。Tomcat 的线程池不仅有工作线程，还有连接器线程、任务队列、以及每个线程绑定的一堆局部缓冲区。这是虚拟线程出现之前最成熟的方案，但不是内存最省的方案。

如果你再开默认的spring.mvc.async.request-timeout、默认的接受队列、默认的 keep-alive 设置，实际线程规模很容易翻一倍，而且这些线程并不会因为并发低就自动缩掉。线程池长时间保持大量存活线程，在 JVM 里就意味着长期占有那一块堆外内存。

2.1 为什么说默认线程池对中小应用是个灾难

我压测的这个项目，核心业务只有 10 来个接口，日常并发峰值不到 200 QPS。理论上 20 个线程绰绰有余，但 Tomcat 默认最大值是 200，而且min-spare默认是 10。结果就是：就算只有一个请求进来，也有 10 条线程待命；压测一旦高于某个水位，线程数就会被快速拉到几十甚至上百。

每一线程 1MB 默认栈空间，100 条线程就是 100MB 的堆外内存，这些还不算线程内部持有的ByteBuffer等资源。更关键的是，线程数量一多，上下文切换成本就上来了，CPU 的局部性变差，业务线程自身的执行效率反倒下降了。

这次调整我的处理方式比较激进：既然虚拟线程已经是 Java 21 的稳定特性，Spring Boot 3.2 又提供了对虚拟线程的内建支持，我直接切换到了虚拟线程模型。切换方法极其简单，直接在配置文件加一行：

spring.threads.virtual.enabled=true

这行配置的作用是：让 Tomcat 的请求处理不再平铺映射到平台线程池，而是将每个请求提交给Executors.newVirtualThreadPerTaskExecutor()来执行。虚拟线程的栈内存不再固定占用 1MB，而是可以根据使用情况分段增减，大量虚拟线程的成本被稀释得非常低。

2.2 虚拟线程化后的实测数据变化

切换成虚拟线程之后，我重新做了一次同样的压测，数据是这样的：

这里想提醒大家一个容易被忽视的细节：虚拟线程并不是所有场景都比平台线程快。如果你的代码里存在 CPU 密集计算，或者你用的是会直接持有平台线程的同步工具类（比如某些第三方客户端内部的同步锁），虚拟线程的优势会被大打折扣。它真正擅长的场景是 IO 密集型链路，其中涉及大量阻塞等待：远程调用、数据库查询、Redis 交互。这些东西本来就是在等外部资源，线程等待期间不占操作系统资源，这才是虚拟线程省内存的根本原因。

另外还有一个小坑：如果你的业务代码里有synchronized块，虚拟线程在竞争锁时可能会被 pin 到载体线程上，万一代码路径长了，反而出现线程饥饿。我项目里碰到的实际问题是，某个老旧的导出功能内部用了大量Collections.synchronizedMap，虚拟线程化后偶发响应变慢。解决方式是把热点同步块替换为ConcurrentHashMap或ReentrantLock，问题立刻消失。

2.3 连接器和 Keep-Alive 的参数修正

线程模型调整完，连接器参数也得跟着动。下面的配置是我结合压测结果最终定下来的版本：

server.tomcat.threads.max=32 server.tomcat.threads.min-spare=8 server.tomcat.accept-count=64 server.tomcat.keep-alive-timeout=10s server.tomcat.max-keep-alive-requests=50 server.tomcat.max-connections=256 server.tomcat.connection-timeout=5000

这里每个参数我都解释一下为什么取这个值：

• max=32：虚拟线程模式下，平台线程池不再承载请求处理，这个参数主要约束了额外的执行线程。即使业务中有少量阻塞任务，32 也足够。
• min-spare=8：保留少量核心线程，避免频繁创建销毁。
• accept-count=64：等待队列。不需要太大，防止大量积压请求耗尽内存。
• keep-alive-timeout=10s：HTTP 长连接保留时间。太长了占用连接器资源，太短了频繁握手浪费 TCP 资源。
• max-keep-alive-requests=50：一个长连接上最多复用 50 次请求。这是为了防止某些客户端长期霸占连接。
• max-connections=256：作为整体保护水位，防止并发异常升高时连接数失控。

如果你还在用 Spring Boot 2.x，没有虚拟线程可选，那我的建议是至少把max压到 50 以内，再配合accept-count做背压。千万不要照抄网上的超大线程池配置，尤其不要盲目相信 “线程多并发高” 这个说法。线程是资源，不是并发能力。

3. 数据访问依赖的隐形内存黑洞：连接池与事务边界

很多 Spring Boot 应用的内存占用，第二大头就在数据库连接池和 ORM 框架身上。HikariCP 是 Spring Boot 默认的连接池，连接池里的每一条物理连接，对应到 MySQL 服务端是一条线程，在客户端这边还有一个缓冲区。连接池开得越大，内存占用越高，而且绝大多数连接在低峰期根本没人用。

3.1 HikariCP 参数不是越大越好

网上关于 HikariCP 参数调优的文章非常多，但很多都是无脑推荐大连接数。HikariCP 官方文档里有个论断：连接池大小 =((核心线程数 * 2) + 有效存储设备并发数)。对大多数中小系统来说，10 到 20 个连接已经绰绰有余。连接数上千的配置只属于极少数硬件和业务都极其特殊的场景。

我这次直接把连接池上限从默认 10 调整成了这样：

spring: datasource: hikari: maximum-pool-size: 12 minimum-idle: 4 idle-timeout: 60000 connection-timeout: 30000 max-lifetime: 1800000 pool-name: AppHikariCP

• maximum-pool-size=12：依据线上 QPS 和单查询耗时计算得出。我们平均查询耗时约 20ms，每秒峰值需要处理约 200 个请求，事务内最多 2 次数据库交互，那么需要的连接数大约是：(200 * 0.04) / 1 = 8，留出 50% 余量就是 12。
• minimum-idle=4：低峰期的基础连接，避免流量突增时临时建连。
• max-lifetime=1800000：30 分钟强制回收连接。注意要小于 MySQL 侧的wait_timeout，否则连接会被服务端先行切断。
• idle-timeout=60000：空闲 1 分钟就回收。

还有一个经常被忽略的问题：连接池的预热。应用刚启动时，连接池会把minimum-idle逐步填充到目标大小，但如果业务在启动后立即迎接流量，可能连接还没就绪。我在ApplicationRunner里加了几条简单的探测 SQL，强制连接池快速初始化：

@Component public class DataSourceWarmer implements ApplicationRunner { private final JdbcTemplate jdbcTemplate; public DataSourceWarmer(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } @Override public void run(ApplicationArguments args) { for (int i = 0; i < 5; i++) { jdbcTemplate.queryForObject("SELECT 1", Integer.class); } } }

别小看这 5 次查询，它能避免上线后第一批请求被连接建立时间拖慢。

3.2 MySQL 性能调优配合：连接释放与慢查询

资源占用缩减这件事，不只关乎客户端内存，也关乎数据库服务端的负载。MySQL 端很多性能问题，根源都是连接的“长期持有”和“无效占用”。我这次在 MySQL 侧同步做了几个收敛操作：

• 缩小连接生命周期：连接长时间不释放，数据库端的thread stack内存不会释放。配合 HikariCP 的max-lifetime，确保每 30 分钟所有连接都被轮换一遍。
• 统一慢查询阈值：把long_query_time设置为 1 秒，并开启slow_query_log。这不是为了排查，而是为了持续观察事务边界是否失控。
• 优化明显不合理的 SQL 索引：压测时发现某条查询每次扫描 5 万行，应用侧怎么调都没用。解释执行计划后，发现是联合索引字段顺序写反了，调整索引后扫描行数降到 200 行，查询时间从 110ms 降到 6ms。
• 从连接持有角度重审事务边界：很多慢请求的真相是业务代码里人为持有事务的时间过长，比如在事务里挂了远程接口调用、文件上传处理等完全不需要事务的操作。

3.3 事务注解的滥用是最容易被忽略的资源杀手

@Transactional几乎成了很多团队处理一切问题的“银弹”：读接口也加、单表简单更新也加、查询列表也加。但事务意味着连接持有时间从“一次查询”拉长到“整个方法执行结束”。如果方法里还有外部接口调用或者复杂循环，一条连接会被白白占用数秒钟。

我这次梳理代码时发现，一个好端端的列表查询方法，内部有一个for循环调用了 20 次单价接口，每次耗时 50ms，@Transactional让整个事务持有了 1 秒多的连接。改造后，我把事务边界收缩到真正的写操作上，读接口完全不使用事务，列表循环改为批量查询后一次组装：

// 改造前 @Transactional public List<ProductVO> listProducts(List<Long> ids) { List<ProductVO> result = new ArrayList<>(); for (Long id : ids) { result.add(productClient.queryById(id)); // 循环调用，事务被拉长 } return result; } // 改造后 public List<ProductVO> listProducts(List<Long> ids) { List<Product> products = productMapper.selectBatchIds(ids); // 批量查询 return products.stream().map(ProductVO::from).toList(); }

这不只是性能优化，更重要的是一次架构思路的修正：事务是宝贵的资源，不是代码装饰品。每次使用前，问自己三件事：这个事务真的需要吗？事务要覆盖哪几条 SQL？事务内有没有非数据库操作？回答完这三个问题，连接池的压力能下降一大截。

注意：MySQL 事务超时时间（innodb_lock_wait_timeout）默认是 50 秒。如果你的事务内出现锁等待，线程会黏在连接和 Row Lock 上很久，这种隐性问题很难从 GC 日志里发现，最好的排查手段是开performance_schema看事务持续时间。

4. 缓存是你最便宜的 IO 防御：从 Redis 到 Caffeine 的两级缓存

内存占用缩减到 80% 的过程中，缓存策略贡献的收益非常可观。很多接口的热点数据被反复从数据库捞、反复做 JSON 序列化、反复通过网络传输。这些操作每一个都在消耗 CPU、内存和 IO 资源。

项目里原本用的是纯 Redis 缓存——所有读请求先打 Redis，命不中再打数据库。这个方案确实减少了很多数据库查询，但还存在两个资源浪费点：

• 每个请求都要走一次网络 IO 到 Redis，单次虽然只要 0.5ms，但累计到几百 QPS 的时候，线程被阻塞等待的时长依然可观。
• Redis 缓存的 value 存的是 JSON 字符串，每次读取都要反序列化成 Java 对象，这个过程的 CPU 和内存分配成本被很多人低估了。

4.1 Caffeine 接入：把最热的数据放到应用进程内

Caffeine 是当前 Java 生态里最优秀的本地缓存库，性能几乎是 Guava Cache 的升级版。它的好处不必多说，核心就是一个字：快。读取本地内存里的对象，不需要网络、不需要反序列化，直接返回同一个引用。

我在项目里做了两级缓存架构：

请求 → Caffeine 本地缓存 → Redis 分布式缓存 → MySQL

层级越高，速度越快、成本越低；层级越低，数据越可靠、容量越大。Caffeine 作为一级缓存，Redis 作为二级缓存，两者数据通过一个简单的版本号机制保持一致性，避免出现比较严重的脏读。

Caffeine 的配置如下：

@Configuration public class CacheConfig { @Bean public Cache<String, ProductVO> productLocalCache() { return Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .recordStats() .build(); } }

• maximumSize=10000：控制内存上限。每个ProductVO粗略估算 2KB，10000 个对象大约占用 20MB，完全在可接受范围。
• expireAfterWrite=5分钟：热点数据最长存活时间，保证更新后最多 5 分钟内可见。
• recordStats()：开启缓存命中率统计，方便后续观测是否值得继续缓存。

业务代码里的拼接逻辑像这样：

public ProductVO getCachedProduct(Long id) { ProductVO local = productLocalCache.getIfPresent(id); if (local != null) { return local; } String json = redisTemplate.opsForValue().get("product:" + id); if (json != null) { ProductVO vo = JSON.parseObject(json, ProductVO.class); productLocalCache.put(id, vo); return vo; } ProductVO vo = productMapper.selectById(id); productLocalCache.put(id, vo); redisTemplate.opsForValue().set("product:" + id, JSON.toJSONString(vo), Duration.ofMinutes(30)); return vo; }

4.2 缓存引入后的实测数据与失效一致性处理

两级缓存落地之后，我再次压测了商品详情接口的 QPS 和资源消耗对比：

重点是最后一行：GC 分配量直接降到了三分之一。减少 JSON 反序列化之后，char[]和byte[]的分配次数大幅下降，年轻代 GC 压力随之显著降低。数据访问这块腾出来的内存空间，直接用在了刀刃上。

当然，本地缓存有一个绕不开的话题——缓存一致性。我之前见过很多团队因为这个坑，最终决定放弃本地缓存。我这里的方案是：

• 更新数据库后主动淘汰本地缓存和 Redis 缓存。先更新 DB，再删除缓存。删除失败通过定时任务兜底，从业务对账表里捞变更记录用 MQ 广播清理。
• 给缓存 key 增加版本号后缀。比如product:v2:123，一旦发生结构性变化，整体切换版本号，避免逐条清理带来的并发穿透。
• 定时刷新高频榜单数据。这类数据对一致性要求极低，干脆用@Scheduled每分钟主动刷新一遍本地缓存，不依赖失效机制。

这一套组合拳打下来，用recordStats()看到 Caffeine 命中率稳定在 92% 以上，Redis 的读写 QPS 明显下降，本地网络 IO 占用也同步缩水了。

4.3 WebSocket 长连接场景的缓存边界设计

热搜词里有 “spring boot 集成 web socket yml 配置”，我顺便展开一个真实场景：WebSocket 长连接本身不需要占用高内存，真正吃内存的是为每个连接维护的会话上下文，以及长连接场景下频繁的消息推送导致的消息积压。

我见过的典型改动思路是：

• 在WebSocketHandler里维护ConcurrentHashMap<String, WebSocketSession>管理会话，而不是用默认的Map。同步阻塞的哈希表在高并发下会退化得非常厉害。
• 给 WebSocketSession 增加空闲超时机制，超过 60 秒没有心跳就关闭并清理会话。
• 消息推送前在业务侧做一次幂等合并，同一个用户多条相同告警只推送一条。这个逻辑极大降低了发送线程的负担。

配置层面，WebSocket 在 Spring Boot 里最容易被忽略的是 YAML 里的容器参数。如果大量长连接同时建立，默认的 Tomcat 连接数可能不够用。结合前面的max-connections=256，如果你预期 WebSocket 连接超过这个数，需要单独评估是否拆分端口部署，或者调大连接数上限。

5. 日志、Bean 装配与自动配置：绕不开的隐藏资源消耗点

内存资源占用高的第三大来源，往往不是业务，而是 Spring Boot 框架自身的“初始化和运行时配套设施”。这里面有两座大山：日志系统和巨大的 Bean 容器。

5.1 logback 的同步刷盘和线程竞争问题

默认的 logback 配置是同步追加日志。每一个 INFO 级别以上的日志，走的是synchronized的写文件流程。请求量一大，日志写入和业务线程抢同一把锁，线程阻塞时间会非常夸张。压测时我用 JFR 的热点树看了一眼，ch.qos.logback.core.OutputStreamAppender的锁竞争时间占比居然能排进前三。

后来我重写了 logback 配置，核心思路是异步 + 丢弃不必要日志：

<configuration> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>2048</queueSize> <discardingThreshold>0</discardingThreshold> <neverBlock>true</neverBlock> <appender-ref ref="FILE"/> </appender> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs/app.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>14</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> <charset>UTF-8</charset> </encoder> </appender> <logger name="org.springframework" level="WARN"/> <logger name="com.app" level="INFO"/> <root level="INFO"> <appender-ref ref="ASYNC"/> </root> </configuration>

重点是neverBlock=true，日志队列满了之后丢掉日志而不是阻塞业务线程。单这一条，压测下接口 TP99 就从 900ms 降到了 760ms。此外，我把框架自身的日志级别提到了 WARN，进一步减少不必要的日志拼接。日志在业务里占的资源比你想象的大，尤其在生产环境开启 DEBUG 级别时，一个接口打几十行日志是很常见的资源黑洞。

5.2 排除用不到的自动配置比想象中更省内存

Spring Boot 的自动配置非常强大，但它会按条件装配大量你不一定需要的组件。比如你只用了 JPA，但工程里还残留着 Redis、MQ、MongoDB 的 starter 依赖，启动时这些组件对应的自动配置类也会尝试装配相关 Bean，即使你没有实际使用它们，相关的*Properties、*AutoConfiguration内部类也会被实例化。

排查方法很简单，启动时加参数：

java -jar app.jar --debug

或者直接看日志里：

Positive matches: Negative matches:

重点关注Negative matches下面的自动配置类，它们没有被装配，不等于不产生任何开销；而Positive matches下面的，则要逐一确认当前业务是否真的需要。例如，我这次就排除了不少明确用不到的配置类：

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class, // 微服务模块里根本不用本地数据源 MongoAutoConfiguration.class, RedisReactiveAutoConfiguration.class, RabbitAutoConfiguration.class })

排除之后启动时间缩短了 12 秒，初始堆外内存占用减少了约 150MB。Spring Boot 的自动配置和实例化是一个延迟加载与立即加载混合的模型，很多组件类只要在 classpath 里就会触发相关元数据初始化。合理的做法是，定期审查依赖树：

mvn dependency:tree

把那些只是“装上了但从来没有调用过”的 starter 依赖清出去。这个动作能从根本上避免无意义的 Bean 装配。

5.3 Bean 懒加载与注解扫描路径收敛

另一个容易忽略的调优点：@ComponentScan包扫描范围。如果启动类上方扫描的包根过宽，Spring 就会在启动阶段去解析一大堆不在业务链路上的类，实例化大量只需要容器管理的 Bean。

为此我做了三件事：

• 把@SpringBootApplication默认的包根保持精确，不扫 extra 目录。
• 对部分第三方库提供的重量级组件，用@Lazy标记延后实例化。
• 把工程里大量的字段注入（Field Injection）改为构造器注入。这本身不是为了性能，但可以更早发现循环依赖，也方便把 Bean 图变得更小。

@Lazy的使用要小心，它只是推迟实例化时间，不是减少实例化次数。如果某个 Bean 最终必然会被调用，懒加载并不能省内存，只能把启动时的内存峰值平摊掉。真正的收益是：线上启动速度变快，内存尖峰降低，但这不等于总占用下降。我实际项目里更看重的是扫描路径的收敛，把@ComponentScan的basePackages精确到业务模块，启动加载的类数量直接少了三成。

连续排查这么多层之后，有一条经验值得反复强调：优化不是做一次就完了，每一层优化做完都要重新压测。因为林迪效应在这里同样成立——内存占用和 GC 压力是耦合的，某一层优化会让其他层的瓶颈暴露得更明显。比如我做完容器线程调整后，内存降了不少，但日志锁竞争问题立刻排到了热点前列；处理完日志问题，连接池的连接数又开始成为瓶颈。这种“逐层挤牙膏”式优化，才是真实项目该有的节奏，不要指望一次配置修改包打天下。

6. 收尾之前的最后一公里：JVM 参数与结果复盘

到了这一步，基础优化基本做完。最后还剩两项收尾工作：JVM 堆的大小策略，以及整链路优化的量化复盘。

6.1 JVM 堆参数从“大而全”改成“小而稳”

很多 Spring Boot 应用的 JVM 参数直接照抄模板，一上来就是-Xms2g -Xmx2g。但问题是，如果业务真实负载只需要 512MB，那 2GB 的堆就是一个巨大的浪费，不仅仅在内存上，还让 GC 的扫描范围变大，Full GC 时候的停顿长到让人怀疑人生。

我看到不少团队在调优时容易犯一个反方向的错误，以为内存给得越大越好。其实 JVM 的 GC 机制倾向于在堆内做标记、复制和压缩，堆越大，每次 GC 扫描的区域就越大，停顿时间就越长。正确做法是：先定业务实际用量，然后再留出足够的安全余量。

这次我把 JVM 参数设置成这样：

java -Xms384m -Xmx384m \ -XX:MaxMetaspaceSize=256m \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=100 \ -XX:+UseStringDeduplication \ -jar app.jar

• -Xms384m -Xmx384m：堆大小直接固定，避免动态扩容带来的 CPU 消耗和内存碎片。384MB 是经过本次优化后的内存评估值：对象缓存 20MB，业务瞬时峰值 100MB，再加上框架运行期余量，500MB 内轻松覆盖。
• -XX:MaxMetaspaceSize=256m：Spring Boot + 反射 + 代理类很容易撑大 Metaspace，设一个上限防止无限制增长。
• -XX:MaxGCPauseMillis=100：给 G1 一个停顿预算，让它更倾向并发回收。
• -XX:+UseStringDeduplication：对于存在大量重复字符串常量的应用来说，这个参数可以实打实地减少堆占用。

测试环境的真实结果是：服务稳定运行 7 天无 OOM，GC 暂停 P99 维持在 80ms 内，堆内存使用率长期徘徊在 55% ～ 75% 之间。相比之前的 2GB 大堆，这个“小而稳”的状态更贴合真实负载。

6.2 优化前后的完整数据对比

整个项目优化完成后，我做了最后一遍压测（500 并发持续 15 分钟），数字如下：

资源占用缩减 80% 这个目标，至此可以拍着胸脯说达成。但我想强调的重点是：这个 80% 不是单一手段带来的。容器线程模型、连接池、缓存、日志、自动配置、JVM 参数六层一起改，每一层削一点，最后才能出现这种乘法效应的收口。只做其中任何一项，大概率连 20% 的收益都拿不到。

我个人的操作体会是：Spring Boot 性能优化最难的从来不是某个具体参数怎么调，而是有没有耐心先用量化工具把“问题地图”画完整。你对着 JFR 火焰图耐心看上两天，哪些地方浪费、哪些地方有空间，答案会自己浮出水面。后面每改一个配置，跑一遍压测、看一组数据，这条路走得慢，但每一步都走得准。

最后分享一个小技巧：优化结束后，记得把整份 JVM 配置和 Spring 配置放到配置中心做版本管理，配上监控报警。这样下次上线新功能导致资源占用回弹时，你能第一时间通过指标差异定位到是哪一层的配置被破坏，而不是从一堆日志里重新开始大海捞针。