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 里一个无关紧要的拼写错误提示总让人觉得心里有个疙瘩不够“干净”。尤其对于有代码洁癖的开发者或者是在团队协作、演示项目时控制台里夹杂着警告信息显得不够专业。这个警告的本质是什么简单说就是你的项目运行时JVMJava虚拟机接收到了一个或多个已经被标记为“过时”且在未来版本中“即将被移除”的启动参数。IDEA 作为启动器把这些参数传递给了 JVM而 JVM 出于兼容性考虑目前只是警告但未来某个版本可能就直接报错导致启动失败了。所以处理它不仅仅是为了界面清爽更是一种面向未来的预防性维护。2. 警告的根源谁在传递这些“过时”参数要解决问题首先得找到问题的源头。这些-XX开头的 JVM 参数是从哪里来的它们不会凭空出现。根据我的经验排查路径可以遵循从“直接”到“间接”从“显式”到“隐式”的顺序。2.1 第一站检查项目自身的运行配置这是最直接、最常见的原因。在 IDEA 中每个可运行的项目如Application都有一个或多个“运行/调试配置”。定位配置在 IDEA 右上角找到运行配置的下拉菜单选择你的 Spring Boot 主类通常是*Application对应的配置然后点击Edit Configurations...。检查 VM 选项在弹出的配置窗口中找到Modify options或直接看下方区域确保Add VM options被勾选。然后在出现的VM options文本框中仔细查看里面的内容。识别问题参数警告信息里提到的参数例如-noverify、-Xverify:none很可能就写在这里。这些参数的作用是关闭字节码验证以换取极微小的启动速度提升。在 JDK 13 之前一些旧项目或教程可能会建议添加它们来“优化”启动。但现在它们已经成了警告的来源。注意这里有个常见的坑。有时候这个文本框里看起来是空的但你可能需要滚动一下或者检查是否有多余的空格、换行符。最好全选、删除、再重新输入你真正需要的参数。2.2 第二站审视构建工具Maven/Gradle的配置如果运行配置里是干净的那么问题可能埋得更深在项目的构建脚本里。构建工具在启动应用时可以传递 JVM 参数。对于 Maven 项目 (pom.xml) 检查spring-boot-maven-plugin的配置。参数可能通过jvmArguments标签传递。build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration !-- 检查这里是否有过时的JVM参数 -- jvmArguments-Xverify:none -Dsome.propertyvalue/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 参数。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 运行配置上。系统环境变量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:UseConcMarkSweepGCCMS GC。CMS 收集器在 JDK 9 中被标记为废弃Deprecated在 JDK 14 中被移除。方案移除并信任默认GC或显式指定新GC。对于大多数 Spring Boot 应用最简单的做法就是直接删除这个参数。JVM特别是 JDK 8 的现代版本会根据你的机器资源自动选择一个合适的垃圾收集器通常是 G1GC。对于 JDK 11 及更高版本G1GC 是默认选择其综合性能在大多数场景下优于 CMS。如果你确实需要指定对于 JDK 11可以考虑使用-XX:UseG1GCG1垃圾收集器。对于追求低延迟的应用在 JDK 11 上可以评估-XX:UseZGC或-XX:UseShenandoahGC这两者都是低延迟GC但 Shenandoah 并非所有 JDK 发行版都默认包含。3.3 处理其他-XX参数对于其他任何被标记为deprecated的-XX参数最通用的处理步骤是查询文档根据你的 JDK 版本去 Oracle 官方文档或 OpenJDK 的发布说明中查找该参数的状态和替代方案。评估必要性这个参数是必须的吗它是为了解决某个特定性能问题而添加的吗现在这个问题是否依然存在很多时候这些参数是从网上某个古老的“性能调优”帖子复制过来的可能早已不适用于当前版本的 JDK 和你的应用。删除或替换如果不必要直接删除。如果必要寻找文档推荐的、未被废弃的新参数进行替换。4. 验证与预防确保问题不再复发清理完毕后不能只是简单地重启了事需要一套验证流程来确认问题真正解决并建立预防机制。4.1 验证步骤完全重启IDEA这是一个非常重要的步骤。IDEA 有时会缓存运行配置或环境变量。关闭 IDEA 再重新打开能确保所有更改生效。运行并观察控制台再次运行你的 Spring Boot 应用仔细观察控制台输出的最开始几行。理想情况下你应该只看到 JVM 版本信息、Spring Boot 的 Banner而不再有那个黄色的警告行。使用诊断命令可选为了彻底放心你可以临时在运行配置的VM options中添加-XX:PrintCommandLineFlags。再次运行控制台会打印出所有实际生效的 JVM 参数。你可以在这里面确认有问题的参数已经消失。4.2 预防措施定期更新 JDK使用一个受支持的、较新的 JDK LTS 版本如 JDK 17, 21。新版本不仅修复了安全漏洞提升了性能也逐步清理了这些历史包袱。将团队或项目的 JDK 版本基线保持在一个较新的 LTS 版本能从根源上避免使用已被移除的参数。代码化运行配置针对团队对于 Maven 或 Gradle 项目尽量将 JVM 运行参数定义在构建脚本pom.xml或build.gradle中而不是依赖每个开发者 IDEA 里的本地运行配置。这样能保证团队环境的一致性。IDEA 在运行bootRun或通过插件启动时会读取这些配置。审查“祖传”配置接手老项目时把pom.xml/build.gradle、IDE 运行配置模板、系统环境变量里的 JVM 参数都仔细审查一遍清理掉那些来历不明或明显过时的配置。理解参数含义在添加任何 JVM 调优参数之前花点时间查阅对应 JDK 版本的官方文档了解其作用、适用范围和生命周期状态。避免盲目复制粘贴。5. 举一反三从警告看 JDK 版本升级的兼容性挑战这个看似简单的警告其实暴露了 Java 开发者日常工作中一个更深层次的问题JDK 版本升级的兼容性管理。-noverify在 JDK 13 被废弃未来会移除。这只是一个缩影。API 的移除比如 JDK 11 移除了 Java EE 和 CORBA 模块如果你用了相关的类升级后直接就是ClassNotFoundException或NoClassDefFoundError。内部 API 的封装从 JDK 9 的模块化开始大量sun.misc.*下的内部 API 无法直接访问了依赖它们的库如一些老的序列化工具、网络库会运行失败。默认行为的改变例如 TLS 版本默认值的提升、默认字符集的改变等可能让你的应用在网络通信或文件处理上产生微妙差异。应对策略使用jdeprscan工具这是 JDK 自带的一个神器。在项目编译打包后对生成的 JAR 包运行jdeprscan --release 版本号 your-application.jar。它可以扫描出你的代码包括依赖的库中使用了哪些在指定release版本中已被标记为废弃的 API。这能给你一个升级前的风险预览。依赖管理使用maven-enforcer-plugin等工具禁止项目引入那些依赖了废弃/移除 API 的第三方库版本。在pom.xml中明确声明并管理依赖的版本。持续集成CI中的兼容性检查将jdeprscan或类似的检查步骤集成到你的 CI/CD 流水线中每当有代码或依赖更新时自动扫描并报告潜在的兼容性问题。关注 Release Notes在计划升级 JDK 版本前务必仔细阅读目标版本的官方发布说明Release Notes特别是“不兼容变更”Incompatible Changes和“废弃项”Deprecated APIs部分。处理掉 IDEA 里那个烦人的 JVM 警告不仅仅是让控制台变得整洁。它更像是一次对项目运行环境的小型“体检”引导你去审视那些可能被遗忘的配置角落理解工具链的运作细节并建立起对技术债务和未来兼容性的警惕性。下次再看到任何警告不妨都把它当作一个优化和学习的契机而不是一个可以忽略的噪音。