在实际 Java 项目升级过程中从 JDK 8 迁移到 JDK 17 不仅仅是修改一个版本号那么简单。最核心、也最容易引发生产环境性能波动的部分就是垃圾回收器的变更。JDK 8 时代开发者对 Parallel Scavenge Parallel OldPSPO和 CMS 耳熟能详而到了 JDK 17G1 已成为默认选择同时 ZGC 和 Shenandoah 也提供了全新的低延迟体验。如果只是简单升级 JDK 版本而不调整 GC 策略或者不理解新老回收器的工作原理与配置差异很可能会遇到应用停顿时间变长、吞吐量下降甚至内存泄漏误判等问题。本文面向正在或计划从 JDK 8 升级至 JDK 17 的中高级 Java 开发者、架构师和运维人员。我们将深入拆解 JDK 8 到 JDK 17 中五个关键的垃圾回收器Serial、ParallelPSPO、CMS、G1 以及 ZGC。不仅会解释它们各自的工作原理和适用场景更会聚焦于升级过程中的实际配置迁移、参数调整、监控验证和问题排查。目标是让你在完成 JDK 升级后能根据自身应用特点选择并调优出最合适的垃圾回收策略确保应用平稳运行。1. 理解垃圾回收器的演进与升级核心挑战在动手修改JAVA_HOME之前必须先理解这次升级在垃圾回收层面意味着什么。这不是一次简单的替换而是一次架构理念的切换。1.1 从“组合选择”到“默认统一”的转变在 JDK 8 及更早版本中JVM 没有指定一个绝对的默认垃圾回收器。对于服务器端应用常见的组合是吞吐量优先-XX:UseParallelGC年轻代 Parallel Scavenge -XX:UseParallelOldGC老年代 Parallel Old合称 Parallel GC。低停顿优先-XX:UseParNewGC年轻代 ParNew -XX:UseConcMarkSweepGC老年代 CMS合称 CMS GC。开发者需要根据应用特性如 Web 服务、批处理主动选择。而从 JDK 9 开始G1 垃圾回收器被设置为默认的垃圾回收器。这意味着如果你在 JDK 17 下不加任何 GC 参数启动应用使用的就是 G1。这个变化是升级后 GC 行为可能迥异的根本原因。1.2 核心挑战配置参数的不兼容与失效许多在 JDK 8 时代习以为常的 GC 参数在 JDK 17 中可能已经失效、废弃或行为改变。直接沿用旧的启动脚本会导致 JVM 忽略无效参数或产生非预期行为。例如CMS 相关的参数在 JDK 14 中被彻底移除。如果你的启动脚本包含-XX:UseConcMarkSweepGC在 JDK 17 下启动时会收到警告并被忽略JVM 将回退到默认的 G1。这可能导致你原本为 CMS 优化的堆大小、线程数等参数在 G1 下表现不佳。1.3 五大回收器定位速览为了后续的对比和选型我们先快速了解这五大回收器的核心定位回收器名称JDK 8 状态JDK 17 状态核心目标适用场景Serial GC可用可用非默认单线程低开销客户端应用、微服务测试、资源受限环境Parallel GC服务器端默认之一可用非默认高吞吐量后台计算、批处理、对吞吐量敏感的应用CMS GC常用低延迟已移除低停顿时间JDK 8 及之前版本的 Web 服务已过时G1 GC可用需显式启用默认回收器平衡吞吐量与停顿大多数服务器端应用堆内存中等至大型如 4GZGC不存在可用生产就绪超低停顿亚毫秒级超大堆内存如数百GB、对延迟极其敏感的应用如金融交易注意Shenandoah GC 也是 JDK 17 中可用的低延迟回收器但其并非 Oracle JDK 的默认组成部分在 OpenJDK 中提供且设计理念与 ZGC 类似。本文聚焦于最主流的五个Shenandoah 可类比参考。2. 环境准备与升级前置检查升级不是直接替换安装包。一个系统的升级流程可以避免很多后续的“灵异事件”。2.1 JDK 安装与多版本管理在生产环境升级前建议在开发或测试环境先安装 JDK 17。你可以从 Adoptium 原 AdoptOpenJDK或 Oracle 官网下载。在 Linux 服务器上可以使用alternatives或手动设置JAVA_HOME来管理多版本# 解压 JDK 17 到 /usr/lib/jvm/ tar -xzf openjdk-17.0.2_linux-x64_bin.tar.gz -C /usr/lib/jvm/ # 设置环境变量临时 export JAVA_HOME/usr/lib/jvm/jdk-17.0.2 export PATH$JAVA_HOME/bin:$PATH # 验证版本 java -version在 IDE 中如 IntelliJ IDEA需要为项目或模块单独指定 JDK 17 的路径并确保编译器的字节码版本设置为 17。2.2 升级前 GC 配置快照与基线性能在关闭 JDK 8 应用前务必记录下当前的 GC 配置和关键性能指标。获取当前 GC 配置通过应用启动命令或jcmd获取。# 找到 Java 进程 PID jps -l # 查看该进程的 VM 标志包含 GC 参数 jcmd PID VM.flags重点关注以-XX:Use开头的 GC 相关参数。建立性能基线收集升级前的关键 GC 日志和性能数据。启用 GC 日志在 JDK 8 启动参数中加入-Xloggc:/path/to/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps。使用jstat观察实时 GC 情况jstat -gcutil PID 1000 10每秒一次共10次。记录应用的关键指标平均响应时间RT、吞吐量QPS、Full GC 频率与耗时。这些数据是升级后对比验证的黄金标准。2.3 依赖与兼容性检查使用 JDK 17 运行你的应用可能遇到三类兼容性问题模块化JPMS问题如果依赖的第三方库尝试深度反射访问 JDK 内部 API如sun.misc.Unsafe的某些用法在 JDK 17 的强封装下会抛出IllegalAccessError。解决方案通常是升级该库到新版本或使用--add-opens命令行参数临时开放模块生产环境慎用。移除的 API如java.security.acl包、java.util.zip.Deflater的某些构造函数等。编译或运行时可能报ClassNotFoundException或NoSuchMethodError。需要查找替代 API。字节码版本确保所有依赖的 Jar 包尤其是通过 Agent 加载的如 APM 探针是为 JDK 8 或更高版本编译的避免UnsupportedClassVersionError。一个实用的检查命令是使用 JDK 17 的jdeps工具分析 Jar 包对内部 API 的依赖jdeps --jdk-internals your-application.jar输出会列出所有使用了内部 API 的类帮助你提前识别风险。3. 五大垃圾回收器深度拆解与配置迁移这是本文的核心。我们将逐一分析每个回收器并给出从 JDK 8 旧配置到 JDK 17 新配置的迁移思路。3.1 Serial GC简单场景的守门员是什么单线程工作的回收器在进行垃圾回收时必须暂停所有应用线程Stop-The-World。为什么还存在因为它实现简单没有线程交互的开销总消耗内存、CPU最小。在堆内存很小如几十MB的客户端应用或单核服务器上它可能比并行回收器更快。JDK 8 配置-XX:UseSerialGCJDK 17 配置保持不变仍为-XX:UseSerialGC迁移建议如果你的 JDK 8 应用运行在资源极其受限的环境如嵌入式设备、低配云函数且使用了 Serial GC升级到 JDK 17 后可以继续使用它。但对于任何稍有规模的服务端应用都不再推荐。3.2 Parallel GC (Throughput Collector)吞吐量的捍卫者是什么JDK 8 时代服务器端的默认选择之一。其年轻代Parallel Scavenge和老年代Parallel Old都使用多线程并行回收专注于最大化应用程序的吞吐量即 CPU 用于运行业务代码的时间占比。为什么在 JDK 17 中不是默认因为 G1 在吞吐量上已经接近 Parallel GC同时在停顿时间控制上远胜于它。但对于纯粹的计算密集型、可以容忍较长且可预测停顿的批处理作业Parallel GC 仍是首选。JDK 8 典型配置-XX:UseParallelGC -XX:UseParallelOldGC -XX:ParallelGCThreads8 # GC线程数通常等于CPU核心数 -XX:MaxGCPauseMillis200 # **期望的**最大停顿时间注意是目标非保证 -XX:GCTimeRatio99 # 吞吐量目标GC时间与总时间比率1/(199)1%JDK 17 配置迁移 配置语法完全兼容可以直接沿用。但需要注意-XX:UseParallelOldGC在 JDK 17 中已无需单独指定设置-XX:UseParallelGC会自动启用。-XX:MaxGCPauseMillis和-XX:GCTimeRatio是相互冲突的目标JVM 会尽力平衡。在 JDK 17 中这些参数的行为可能被微调建议升级后观察实际停顿。关键参数调整-XX:ParallelGCThreads仍可设置为 CPU 核心数。在容器化环境如 Docker中需注意 JVM 可能无法正确识别 CPU 限制建议通过-XX:ActiveProcessorCount明确指定。-XX:UseAdaptiveSizePolicy默认开启Parallel GC 能根据运行时情况自动调整 Eden、Survivor 区大小以达到停顿或吞吐量目标。如果你在 JDK 8 中已手动调优了-XX:SurvivorRatio、-XX:NewRatio升级后建议先关闭此策略-XX:-UseAdaptiveSizePolicy观察效果。3.3 CMS GC一个时代的落幕是什么并发标记清除回收器。其核心优势是“并发”大部分标记和清除工作可以与应用线程同时进行从而显著减少停顿时间。但它存在内存碎片化和“并发模式失败”导致 Full GC 的风险。为什么被移除CMS 的代码复杂且难以维护无法有效与现代硬件特性如大内存结合。其碎片化问题需要依赖 Full GC 来整理而 Full GC 是单线程的可能导致长时间停顿。G1 和 ZGC 提供了更优的低延迟解决方案。JDK 8 典型配置-XX:UseParNewGC -XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction75 # 老年代使用率达到75%时启动CMS -XX:UseCMSInitiatingOccupancyOnly -XX:CMSParallelRemarkEnabled # 并行重新标记减少停顿 -XX:CMSClassUnloadingEnabled # 启用类卸载JDK 17 迁移策略CMS 在 JDK 14 中被移除JDK 17 中已完全不可用。如果启动参数中包含 CMS 相关参数JVM 会忽略并打印警告然后回退到默认的 G1。因此你必须主动选择一个新的回收器。迁移路径首选 G1对于大多数从 CMS 迁移的应用G1 是最自然的替代者。它同样追求低停顿且能避免内存碎片。考虑 ZGC/Shenandoah如果应用堆内存非常大32GB且对停顿时间有极苛刻要求10ms可以直接评估 ZGC。3.4 G1 GC新时代的默认王者是什么垃圾回收器。它将堆内存划分为多个大小相等的区域Region不再是物理上的连续新生代和老年代。G1 通过跟踪每个区域的垃圾价值回收所需时间与回收空间优先回收价值高的区域从而在可控的停顿时间内获得尽可能高的吞吐量。为什么成为默认它在吞吐量和停顿时间之间取得了更好的平衡且能有效管理从几百MB到几十GB的堆内存适应性最强。从 CMS 迁移到 G1 的配置对照 以下是一个常见的 CMS 配置及其对应的 G1 配置思路。CMS 配置参数JDK 8含义G1 对应配置思路JDK 17说明-Xms4g -Xmx4g堆大小-Xms4g -Xmx4g堆大小设置原则不变。G1 对堆的利用率更高可考虑设置相同或略小。-XX:CMSInitiatingOccupancyFraction75触发 GC 的老年代阈值-XX:InitiatingHeapOccupancyPercent45重要区别G1 关注的是整个堆的使用率而非仅老年代。初始值建议 45。-XX:UseCMSInitiatingOccupancyOnly仅使用阈值触发无直接对应G1 有自适应机制会根据历史数据预测。如需固定阈值需配合其他参数。-XX:ParallelGCThreads8GC 并行线程数-XX:ParallelGCThreads8含义相同可沿用。-XX:ConcGCThreads2CMS 并发线程数-XX:ConcGCThreads2G1 并发标记阶段线程数可沿用或稍增。无直接对应最大停顿时间目标-XX:MaxGCPauseMillis200G1 的核心调优参数。设置一个合理的目标如 200msG1 会努力达成。G1 关键参数详解-XX:MaxGCPauseMillis200期望的最大停顿时间目标。这是软目标JVM 会尽力但不保证。设置过低如 50ms会导致 GC 过于频繁反而降低吞吐量。-XX:InitiatingHeapOccupancyPercent45触发并发标记周期的堆占用率阈值。如果应用分配很快可以适当调低如 40以提早启动标记。-XX:G1ReservePercent10堆的保留空间用于防止晋升失败Evacuation Failure。如果频繁发生晋升失败可以适当增加如 15。-XX:G1HeapRegionSize区域大小范围 1MB 到 32MB。通常无需手动设置JVM 会根据堆大小自动计算。G1 的 GC 日志分析 在 JDK 17 中推荐使用统一日志框架JUL来输出 GC 日志信息更全面。# JDK 17 推荐GC日志参数 -Xlog:gc*,gcheapdebug,gcergo*trace,gcage*trace:file/path/to/gc.log:time,uptime,level,tags:filecount5,filesize100M日志中需关注的关键阶段Young Generation GC常规的新生代回收。Concurrent Cycle包含并发标记、重新标记、清理等阶段。这是 G1 实现低停顿的关键。Full GC如果看到 “Full GC (Allocation Failure)”说明 G1 发生了疏散失败或并发周期跟不上分配速率是需要调优的信号。3.5 ZGC面向未来的超低延迟回收器是什么Z 垃圾回收器。其设计目标是实现亚毫秒级1ms的最大停顿时间且停顿时间不会随堆大小增长而增加。它通过染色指针和读屏障等黑科技将大部分垃圾回收工作移至并发阶段完成。适用场景堆内存极大TB 级别或对响应时间有极端要求如金融核心交易、实时游戏的应用。对于中小型堆或吞吐量优先的应用ZGC 可能不是最佳选择因为它会牺牲一部分吞吐量。JDK 17 中启用 ZGC-XX:UseZGC # 对于堆内存非常大的情况可以设置大页面以提高性能 -XX:UseLargePages -XX:ZPath/path/to/hugepages关键参数-Xmx -XmsZGC 对堆大小的设置非常敏感建议-Xms和-Xmx设置为相同的值以避免堆伸缩带来的延迟。-XX:ConcGCThreads并发 GC 线程数。默认值为(CPU核心数 1) / 4。可以适当调整以平衡 GC 和应用线程对 CPU 的占用。-XX:SoftMaxHeapSize软最大堆大小。ZGC 会努力将堆使用率维持在此值以下仅在必要时才扩展到-Xmx。这有助于控制内存占用。从 G1/Parallel 迁移到 ZGC 的注意事项吞吐量预期ZGC 的吞吐量通常低于 Parallel GC也可能略低于调优良好的 G1。需要评估业务是否能接受。内存开销ZGC 需要额外的内存用于元数据和染色指针实际可用堆内存会略小于-Xmx的设置。监控工具确保你的监控系统如 Prometheus Grafana支持 ZGC 的指标如jvm_gc_pause_seconds_max。使用jstat -gc命令查看 ZGC 指标。4. 升级实战配置迁移、运行验证与监控理论之后我们通过一个模拟案例将上述知识串联起来。4.1 案例一个 Spring Boot Web 应用的 GC 配置迁移假设我们有一个在 JDK 8 上运行的 Spring Boot 应用原 GC 配置如下CMSjava -Xms2g -Xmx2g \ -XX:UseParNewGC \ -XX:UseConcMarkSweepGC \ -XX:CMSInitiatingOccupancyFraction70 \ -XX:UseCMSInitiatingOccupancyOnly \ -XX:CMSParallelRemarkEnabled \ -XX:CMSClassUnloadingEnabled \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/app/logs/gc.log \ -jar myapp.jar迁移到 JDK 17 的 G1 配置步骤移除废弃参数去掉所有 CMS 相关参数UseParNewGC,UseConcMarkSweepGC,CMSInitiatingOccupancyFraction等。启用 G1添加-XX:UseG1GC在 JDK 17 中即使不加默认也是 G1但显式声明更清晰。转换核心参数堆大小-Xms2g -Xmx2g保持不变。将老年代触发阈值CMSInitiatingOccupancyFraction70转换为堆触发阈值。由于 G1 的并发标记开销比 CMS 大初始值可以设得保守一些例如-XX:InitiatingHeapOccupancyPercent40。增加最大停顿时间目标-XX:MaxGCPauseMillis150。更新 GC 日志参数采用 JDK 9 的统一日志格式。添加容器化支持如果适用明确指定 CPU 核心数。迁移后的新启动脚本java -Xms2g -Xmx2g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis150 \ -XX:InitiatingHeapOccupancyPercent40 \ -XX:ParallelGCThreads4 \ -XX:ConcGCThreads2 \ -XX:UseContainerSupport \ -XX:ActiveProcessorCount4 \ -Xlog:gc*,gcheapdebug,gcergo*trace,gcage*trace:file/app/logs/gc.log:time,uptime,level,tags:filecount5,filesize100M \ -jar myapp.jar4.2 验证与监控启动应用后需要通过多种手段验证 GC 行为是否符合预期。验证回收器是否生效jcmd PID VM.flags | grep UseG1GC # 应输出UseG1GC使用jstat实时观察jstat -gcutil PID 1000关注列S0,S1,ESurvivor 0/1 区和 Eden 区的使用百分比。O老年代使用百分比。M元空间使用百分比。YGC,YGCTYoung GC 次数和总耗时。FGC,FGCTFull GC 次数和总耗时。对于 G1应极少看到 FGC。分析 GC 日志 查看配置的 GC 日志文件。重点关注是否有 “Full GC” 记录。“Pause Young” 和 “Pause Mixed” 的实际停顿时间是否接近MaxGCPauseMillis目标。并发标记周期Concurrent Cycle的频率和耗时。应用性能对比 与升级前记录的基线数据对比平均响应时间RT是否稳定或改善吞吐量QPS/TPS是否有下降系统监控如 CPU 使用率、Load是否正常4.3 容器化环境Docker/K8s的特殊配置在容器中运行 JDK 17需要特别注意 JVM 对资源限制的感知。CPU 核心数JVM 默认会读取宿主机的 CPU 数而非容器限制。必须使用-XX:UseContainerSupportJDK 8u191 和 JDK 10 默认开启并配合-XX:ActiveProcessorCountnumber来明确指定可用 CPU 数。内存限制同样使用-XX:UseContainerSupport让 JVM 从cgroup读取内存限制。-Xmx应设置为小于容器内存限制的值为操作系统和其他进程留出空间例如容器限制 2G-Xmx可设为 1.5g。GC 线程数ParallelGCThreads和ConcGCThreads会根据ActiveProcessorCount自动计算通常无需手动设置除非有特殊调优需求。一个容器内的启动示例# Dockerfile 或 K8s yaml 中的命令 java -XX:UseContainerSupport \ -XX:MaxRAMPercentage75.0 \ # 使用容器内存的75%作为堆最大限制 -XX:InitialRAMPercentage50.0 \ # 初始堆大小为容器内存的50% -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -jar /app.jar5. 常见问题排查与调优指南升级后遇到问题怎么办以下是按症状分类的排查清单。5.1 问题一启动失败或警告未知参数现象应用启动失败或日志中出现Unrecognized VM option警告。原因使用了 JDK 17 中已移除或废弃的参数主要是 CMS 相关。解决从启动脚本中移除所有-XX:UseConcMarkSweepGC、-XX:UseParNewGC、-XX:CMS*等参数。如果仍需低延迟改为启用 G1 (-XX:UseG1GC) 或 ZGC (-XX:UseZGC)。使用java -XX:PrintFlagsFinal -version | grep flag来验证参数在当前 JDK 版本中是否可用。5.2 问题二频繁 Full GC 或长时间停顿现象通过jstat或 GC 日志观察到频繁的 Full GC且单次停顿时间很长1秒。可能原因及排查回收器可能原因排查手段调优建议G1晋升失败年轻代回收时Survivor 区或老年代没有足够空间容纳存活对象。查看 GC 日志中是否有 “Evacuation Failure” 或 “To-space exhausted”。观察jstat -gcutil中老年代 (O) 使用率是否持续很高。1.增加堆大小(-Xmx)。2.提早启动并发标记降低-XX:InitiatingHeapOccupancyPercent如从45降到35。3.增加预留空间提高-XX:G1ReservePercent如从10到20。4.加快标记速度增加-XX:ConcGCThreads。G1并发模式失败并发标记周期跟不上对象分配的速度导致不得不进行 Full GC。GC 日志中在并发周期阶段出现 “Full GC (Allocation Failure)”。1.降低触发阈值同晋升失败。2.增加并发线程同晋升失败。3.优化应用减少内存分配速率检查是否有内存泄漏。Parallel老年代填满对象晋升过快或存在内存泄漏。jstat显示老年代 (O) 使用率在每次 Young GC 后只增不减最终触发 Full GC。1.增加堆大小。2.调整新生代比例增加-XX:NewRatio减小新生代或调整-XX:SurvivorRatio。3.排查内存泄漏使用jmap -histo:live PID或jcmd PID GC.class_histogram分析存活对象。ZGC分配停顿非 Full GC。ZGC 的停顿主要是分配停顿。查看 GC 日志中的 “Pause” 类型。1.避免堆自动伸缩设置-Xms等于-Xmx。2.调整-XX:SoftMaxHeapSize设置一个更积极的软限制。3.优化分配速率。5.3 问题三吞吐量显著下降现象CPU 使用率变化不大但应用处理的请求数QPS/TPS明显降低。可能原因GC 线程占用过多 CPU尤其是并发标记阶段。使用top -Hp PID查看 GC 线程的 CPU 消耗。GC 频率过高过于激进的停顿时间目标如MaxGCPauseMillis50导致 GC 频繁发生。回收器选择不当从 Parallel GC 切换到 G1/ZGC 会固有地损失一部分吞吐量。调优建议对于 G1适当放宽-XX:MaxGCPauseMillis如从 100 调到 200给 JVM 更多空间来优化吞吐量。对于所有回收器如果吞吐量是唯一核心指标可以换回 Parallel GC (-XX:UseParallelGC) 进行对比测试。监控 GC 时间占比通过 GC 日志计算(Total GC time) / (Total elapsed time)。如果超过 10%-20%说明 GC 开销过大需要从上述原因入手。5.4 问题四元空间Metaspace相关问题现象java.lang.OutOfMemoryError: Metaspace或jstat显示M元空间使用率持续增长。原因JDK 8 中的永久代PermGen已被元空间Metaspace取代。元空间使用本地内存默认上限很大但如果不加限制可能导致内存被耗尽。解决设置元空间大小限制-XX:MaxMetaspaceSize256m。设置元空间初始大小-XX:MetaspaceSize64m。当使用量达到此值时会触发 Full GC 进行类卸载和元空间扩容。监控类加载器的泄漏使用jcmd PID GC.class_stats需要-XX:UnlockDiagnosticVMOptions分析加载的类数量。6. 最佳实践与最终决策清单在完成升级和初步调优后遵循以下实践可以保持系统稳定。6.1 GC 选型决策清单面对 JDK 17你可以根据以下清单选择回收器堆内存很小512MB或单核环境考虑Serial GC(-XX:UseSerialGC)。吞吐量是唯一核心指标可容忍秒级停顿选择Parallel GC(-XX:UseParallelGC)。堆内存中等2GB ~ 32GB追求停顿时间与吞吐量的平衡使用默认的 G1 GC。这是大多数 Web 应用、微服务的推荐选择。堆内存非常大32GB 甚至 TB 级要求停顿时间极短且可预测10ms评估ZGC(-XX:UseZGC) 或Shenandoah(-XX:UseShenandoahGC)。从 JDK 8 CMS 迁移首选 G1。只有在 G1 无法满足延迟要求且堆内存很大时才考虑 ZGC。6.2 生产环境配置检查清单在将新的 JDK 17 应用配置部署到生产环境前请核对[ ]GC 参数已移除所有废弃的 CMS 参数明确指定了目标回收器或接受默认 G1。[ ]堆大小-Xms和-Xmx已根据容器或物理机内存合理设置并为操作系统和其他进程留出空间。[ ]停顿目标如果使用了 G1-XX:MaxGCPauseMillis设置了一个合理的值如 100-200ms。[ ]元空间限制设置了-XX:MaxMetaspaceSize以防止内存无限增长。[ ]GC 日志已配置统一日志-Xlog:gc*...并输出到文件设置了滚动策略。[ ]容器化支持如果在容器中运行已启用-XX:UseContainerSupport并合理设置了-XX:MaxRAMPercentage或-XX:ActiveProcessorCount。[ ]监控对接确保监控系统能采集 JVM 指标如通过 JMX 或 Micrometer特别是 GC 次数、耗时、内存池使用情况。6.3 性能调优迭代流程GC 调优不是一蹴而就的应遵循“观察-假设-验证”的循环观察在预发或压测环境使用jstat、GC 日志和应用监控收集至少一个业务周期如一天的数据。假设根据问题如频繁 Full GC、长停顿和理论知识提出调优假设如“降低InitiatingHeapOccupancyPercent可能减少晋升失败”。验证每次只调整一个参数然后再次观察相同负载下的表现。记录每次变更和结果。固化将带来积极效果的参数变更固化到配置中并持续监控生产环境。从 JDK 8 升级到 JDK 17 是一次重要的技术演进垃圾回收器的变更则是其中最关键也最需要谨慎对待的一环。理解 Serial、Parallel、CMS、G1、ZGC 这五代回收器的设计哲学与适用场景是做出正确选型的基础。升级的核心操作在于配置参数的迁移与更新特别是从 CMS 到 G1 的思维转换。成功的升级不仅意味着程序能跑起来更意味着在新的 JDK 和 GC 下应用能获得更优的性能和更稳定的运行时表现。务必通过严谨的监控、对比测试和循序渐进的调优来完成这次升级让新版本的性能潜力真正为你的业务服务。