launch.json中配置vmArgs是调整Spring Boot应用JVM内存的唯一有效方式，例如"-Xms512m -Xmx1g -XX:+UseG1GC"，该参数仅作用于当前调试进程，不涉及语言服务器；需确保-Xms与-Xmx相等以避免运行时扩容开销，并结合/actuator/startup端点分析启动瓶颈。
launch.json 里配 vmArgs 才管 Spring Boot 启动内存
VSCode 调试运行 Spring Boot 项目时，vmArgs 是唯一真正生效的 JVM 参数入口。它只作用于你当前调试启动的 Java 进程，不影响 Language Server 或其他后台服务。
常见错误是把参数写进 settings.json 的 java.jdt.ls.vmargs —— 那只是给 Java 语言服务器用的，和你的 Spring Boot 应用完全无关。
- 打开项目根目录下的
.vscode/launch.json - 找到 type 为
spring-boot或java的配置项 - 在
vmArgs字段中添加参数，例如："-Xms512m -Xmx1g -XX:+UseG1GC" - 若未生成
launch.json，可通过调试面板 → “创建 launch.json” → 选择 “Spring Boot” 自动生成
别乱设 -Xms 和 -Xmx，小项目反而更慢
盲目加大堆内存不仅浪费资源，还可能延长 GC 停顿时间，尤其对启动阶段影响明显。Spring Boot 启动过程大量创建短期对象，过大的堆会让 GC 策略失衡。
实测经验：本地开发单模块 Spring Boot 项目（无大量静态资源、无嵌入式数据库），-Xms256m -Xmx768m 比 -Xms1g -Xmx2g 启动快 1.5–2 秒，内存占用低 30%+。
- 优先固定
-Xms与-Xmx相等，避免运行时扩容开销 - 超过 1GB 堆后，G1 GC 的初始标记阶段耗时明显上升，启动瓶颈从类加载转向 GC
- 如果项目含大量反射扫描（如 Lombok + MapStruct + 多个 starter），可加
-XX:TieredStopAtLevel=1关闭 C2 编译器，减少 JIT 预热时间
Spring Boot 2.4+ 启动分析必须开 startup 端点
光调参数不看数据，等于蒙眼调优。/actuator/startup 是 Spring Boot 自带的结构化启动时序接口，能精准定位卡点在哪一阶段。
不配这个，你永远不知道是 ClassPathScanningCandidateComponentProvider 扫包慢，还是某个 @Bean 初始化拖了后腿。
- 加依赖：
spring-boot-starter-actuator - 在
application.yml中启用：management.endpoints.web.exposure.include: startup - 启动后访问
http://localhost:8080/actuator/startup，查看 events 列表里的 duration 字段 - 重点关注
spring.beans.instantiate和spring.context.refresh两个事件耗时
多个 Spring Boot 服务并行跑，得单独配每个 launch.json
VSCode 不支持“全局 JVM 参数模板”，每个项目或每个启动配置都需独立维护 vmArgs。共用同一份配置容易导致内存争抢或参数冲突。
比如你同时跑 gateway、auth、user 三个服务，各自 launch.json 中的 vmArgs 应差异化设置：
- gateway：侧重网络 IO，可加
-XX:MaxDirectMemorySize=256m - auth：含 JWT 解析和密码加密，建议加
-XX:+UseStringDeduplication - user：DB 操作多，适当提高
-XX:MetaspaceSize至256m防止反复 redefining class
真正容易被忽略的是：这些参数必须和你实际使用的 JDK 版本匹配——JDK 17 的 -XX:+UseZGC 在 JDK 11 上直接报错，而 -XX:TieredStopAtLevel 在 JDK 17+ 已被废弃。调参前先 java -version 确认版本。
