解决IntelliJ IDEA中JVM废弃参数警告的完整指南

1. 问题现场：一个熟悉的“老朋友”又来了

如果你用 IntelliJ IDEA 开发 Spring Boot 项目，大概率见过下面这个老朋友。某天，当你满怀期待地点击那个绿色的运行按钮，控制台在项目启动信息之前，赫然打印出一行刺眼的黄色警告：

Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.

或者，你也可能遇到它的其他变体，比如关于CMS垃圾收集器、UseConcMarkSweepGC等参数的警告。这个警告本身不会阻止你的项目启动，Spring Boot 应用依然能跑起来，但它就像代码里一个没处理的TODO注释，或者 IDE 里一个无关紧要的拼写错误提示，总让人觉得心里有个疙瘩，不够“干净”。尤其对于有代码洁癖的开发者，或者是在团队协作、演示项目时，控制台里夹杂着警告信息，显得不够专业。

这个警告的本质是什么？简单说，就是你的项目运行时，JVM（Java虚拟机）接收到了一个或多个已经被标记为“过时”且在未来版本中“即将被移除”的启动参数。IDEA 作为启动器，把这些参数传递给了 JVM，而 JVM 出于兼容性考虑，目前只是警告，但未来某个版本可能就直接报错导致启动失败了。所以，处理它不仅仅是为了界面清爽，更是一种面向未来的预防性维护。

2. 警告的根源：谁在传递这些“过时”参数？

要解决问题，首先得找到问题的源头。这些-XX开头的 JVM 参数是从哪里来的？它们不会凭空出现。根据我的经验，排查路径可以遵循从“直接”到“间接”，从“显式”到“隐式”的顺序。

2.1 第一站：检查项目自身的运行配置

这是最直接、最常见的原因。在 IDEA 中，每个可运行的项目（如Application）都有一个或多个“运行/调试配置”。

1. 定位配置：在 IDEA 右上角，找到运行配置的下拉菜单，选择你的 Spring Boot 主类（通常是*Application）对应的配置，然后点击Edit Configurations...。
2. 检查 VM 选项：在弹出的配置窗口中，找到Modify options（或直接看下方区域），确保Add VM options被勾选。然后，在出现的VM options文本框中，仔细查看里面的内容。
3. 识别问题参数：警告信息里提到的参数，例如-noverify、-Xverify:none，很可能就写在这里。这些参数的作用是关闭字节码验证，以换取极微小的启动速度提升。在 JDK 13 之前，一些旧项目或教程可能会建议添加它们来“优化”启动。但现在，它们已经成了警告的来源。

注意：这里有个常见的坑。有时候这个文本框里看起来是空的，但你可能需要滚动一下，或者检查是否有多余的空格、换行符。最好全选、删除、再重新输入你真正需要的参数。

2.2 第二站：审视构建工具（Maven/Gradle）的配置

如果运行配置里是干净的，那么问题可能埋得更深，在项目的构建脚本里。构建工具在启动应用时，可以传递 JVM 参数。

• 对于 Maven 项目 (pom.xml)： 检查spring-boot-maven-plugin的配置。参数可能通过<jvmArguments>标签传递。

  <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <!-- 检查这里是否有过时的JVM参数 --> <jvmArguments>-Xverify:none -Dsome.property=value</jvmArguments> </configuration> </plugin> </plugins> </build>

  此外，也要检查 Maven 的MAVEN_OPTS环境变量（系统级或用户级），它会影响所有 Maven 命令。

• 对于 Gradle 项目 (build.gradle或build.gradle.kts)： 检查bootRun任务的配置。参数可能通过jvmArgs设置。

  // build.gradle bootRun { jvmArgs = ['-noverify', '-XX:+UseConcMarkSweepGC'] }

  // build.gradle.kts tasks.bootRun { jvmArgs = listOf("-noverify", "-XX:+UseConcMarkSweepGC") }

2.3 第三站：探索 IDE 或环境的全局默认值

如果前两步都排除了，那么可能是 IDEA 本身或你的系统环境为所有 Java 应用设置了全局的 JVM 参数。

1. IDEA 默认运行配置模板：在File -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven/Gradle -> Runner（对于构建工具运行），或者File -> Settings -> Build, Execution, Deployment -> Java Compiler等地方，查看是否有全局的 VM 参数设置。更常见的是，在Edit Configurations窗口的顶部，有一个Templates菜单，里面存有各种运行配置类型的模板（如Application、Spring Boot）。检查Spring Boot模板的VM options，它可能被错误地修改并应用到了所有新创建的 Spring Boot 运行配置上。

2. 系统环境变量JAVA_TOOL_OPTIONS或_JAVA_OPTIONS：这是两个特殊的环境变量。JVM 启动时会自动读取它们，并将其中的参数附加到命令行参数之后。你可以在系统的环境变量中搜索它们。这是一个非常隐蔽的源头，特别是如果你之前为了调试或其他目的设置过它们，后来却忘记了。

2.4 第四站：依赖库的“悄悄话”（不太常见但需知晓）

在极少数情况下，某些第三方库或代理（Agent）可能会在运行时动态地向 JVM 添加参数。这种情况比较难排查，通常需要借助-XX:+PrintCommandLineFlags这个 JVM 参数来在启动时打印出所有最终生效的参数，然后与你的配置进行对比，找出“多出来”的那部分。

3. 精准清除：针对不同警告的修复方案

找到源头后，我们就可以动手清理了。不同的警告参数，处理方式略有不同。

3.1 处理-noverify和-Xverify:none

这两个是“字节码验证”开关，是本次警告中最常见的“罪犯”。

• 方案一：直接删除（推荐）。在绝大多数现代应用（包括 Spring Boot）中，关闭字节码验证带来的启动性能提升微乎其微，几乎可以忽略不计，而它却带来了潜在的安全风险（无法验证加载的类文件是否被篡改或损坏）。因此，最安全、最干净的做法是直接在你的运行配置、Maven 或 Gradle 配置中找到并删除-noverify或-Xverify:none参数。
• 方案二：替换（如需兼容旧版）。如果你的项目因为某些特殊原因（例如使用了某些特定的、陈旧的字节码增强工具）必须关闭验证，并且你暂时无法升级 JDK 到 13 以上，可以考虑使用-XX:-BytecodeVerificationLocal和-XX:-BytecodeVerificationRemote这两个更细粒度的参数（如果仍被支持的话）。但长远来看，移除或寻找替代方案才是正道。

3.2 处理过时的垃圾回收器参数

例如-XX:+UseConcMarkSweepGC（CMS GC）。CMS 收集器在 JDK 9 中被标记为废弃（Deprecated），在 JDK 14 中被移除。

• 方案：移除并信任默认GC或显式指定新GC。对于大多数 Spring Boot 应用，最简单的做法就是直接删除这个参数。JVM（特别是 JDK 8+ 的现代版本）会根据你的机器资源自动选择一个合适的垃圾收集器（通常是 G1GC）。对于 JDK 11 及更高版本，G1GC 是默认选择，其综合性能在大多数场景下优于 CMS。
• 如果你确实需要指定，对于 JDK 11+，可以考虑使用-XX:+UseG1GC（G1垃圾收集器）。对于追求低延迟的应用，在 JDK 11+ 上可以评估-XX:+UseZGC或-XX:+UseShenandoahGC（这两者都是低延迟GC，但 Shenandoah 并非所有 JDK 发行版都默认包含）。

3.3 处理其他-XX参数

对于其他任何被标记为deprecated的-XX参数，最通用的处理步骤是：

1. 查询文档：根据你的 JDK 版本，去 Oracle 官方文档或 OpenJDK 的发布说明中，查找该参数的状态和替代方案。
2. 评估必要性：这个参数是必须的吗？它是为了解决某个特定性能问题而添加的吗？现在这个问题是否依然存在？很多时候，这些参数是从网上某个古老的“性能调优”帖子复制过来的，可能早已不适用于当前版本的 JDK 和你的应用。
3. 删除或替换：如果不必要，直接删除。如果必要，寻找文档推荐的、未被废弃的新参数进行替换。

4. 验证与预防：确保问题不再复发

清理完毕后，不能只是简单地重启了事，需要一套验证流程来确认问题真正解决，并建立预防机制。

4.1 验证步骤

1. 完全重启IDEA：这是一个非常重要的步骤。IDEA 有时会缓存运行配置或环境变量。关闭 IDEA 再重新打开，能确保所有更改生效。
2. 运行并观察控制台：再次运行你的 Spring Boot 应用，仔细观察控制台输出的最开始几行。理想情况下，你应该只看到 JVM 版本信息、Spring Boot 的 Banner，而不再有那个黄色的警告行。
3. 使用诊断命令（可选）：为了彻底放心，你可以临时在运行配置的VM options中添加-XX:+PrintCommandLineFlags。再次运行，控制台会打印出所有实际生效的 JVM 参数。你可以在这里面确认有问题的参数已经消失。

4.2 预防措施

1. 定期更新 JDK：使用一个受支持的、较新的 JDK LTS 版本（如 JDK 17, 21）。新版本不仅修复了安全漏洞，提升了性能，也逐步清理了这些历史包袱。将团队或项目的 JDK 版本基线保持在一个较新的 LTS 版本，能从根源上避免使用已被移除的参数。
2. 代码化运行配置（针对团队）：对于 Maven 或 Gradle 项目，尽量将 JVM 运行参数定义在构建脚本（pom.xml或build.gradle）中，而不是依赖每个开发者 IDEA 里的本地运行配置。这样能保证团队环境的一致性。IDEA 在运行bootRun或通过插件启动时，会读取这些配置。
3. 审查“祖传”配置：接手老项目时，把pom.xml/build.gradle、IDE 运行配置模板、系统环境变量里的 JVM 参数都仔细审查一遍，清理掉那些来历不明或明显过时的配置。
4. 理解参数含义：在添加任何 JVM 调优参数之前，花点时间查阅对应 JDK 版本的官方文档，了解其作用、适用范围和生命周期状态。避免盲目复制粘贴。

5. 举一反三：从警告看 JDK 版本升级的兼容性挑战

这个看似简单的警告，其实暴露了 Java 开发者日常工作中一个更深层次的问题：JDK 版本升级的兼容性管理。-noverify在 JDK 13 被废弃，未来会移除。这只是一个缩影。

• API 的移除：比如 JDK 11 移除了 Java EE 和 CORBA 模块，如果你用了相关的类，升级后直接就是ClassNotFoundException或NoClassDefFoundError。
• 内部 API 的封装：从 JDK 9 的模块化开始，大量sun.misc.*下的内部 API 无法直接访问了，依赖它们的库（如一些老的序列化工具、网络库）会运行失败。
• 默认行为的改变：例如 TLS 版本默认值的提升、默认字符集的改变等，可能让你的应用在网络通信或文件处理上产生微妙差异。

应对策略：

1. 使用jdeprscan工具：这是 JDK 自带的一个神器。在项目编译打包后，对生成的 JAR 包运行jdeprscan --release <版本号> your-application.jar。它可以扫描出你的代码（包括依赖的库）中使用了哪些在指定release版本中已被标记为废弃的 API。这能给你一个升级前的风险预览。
2. 依赖管理：使用maven-enforcer-plugin等工具，禁止项目引入那些依赖了废弃/移除 API 的第三方库版本。在pom.xml中明确声明并管理依赖的版本。
3. 持续集成（CI）中的兼容性检查：将jdeprscan或类似的检查步骤集成到你的 CI/CD 流水线中，每当有代码或依赖更新时，自动扫描并报告潜在的兼容性问题。
4. 关注 Release Notes：在计划升级 JDK 版本前，务必仔细阅读目标版本的官方发布说明（Release Notes），特别是“不兼容变更”（Incompatible Changes）和“废弃项”（Deprecated APIs）部分。

处理掉 IDEA 里那个烦人的 JVM 警告，不仅仅是让控制台变得整洁。它更像是一次对项目运行环境的小型“体检”，引导你去审视那些可能被遗忘的配置角落，理解工具链的运作细节，并建立起对技术债务和未来兼容性的警惕性。下次再看到任何警告，不妨都把它当作一个优化和学习的契机，而不是一个可以忽略的噪音。