1. 从JDK8到JDK17升级的核心动力与垃圾回收器变迁如果你还在用JDK8考虑升级到JDK17最直接的理由可能不是新语法而是垃圾回收器GC的全面革新。JDK8时代CMSConcurrent Mark Sweep是很多线上服务的主流选择因为它能提供相对较低的停顿时间。但到了JDK17CMS已被彻底移除G1Garbage-First成为默认GC同时引入了ZGC和Shenandoah这两个以超低停顿时间为目标的革命性回收器。这次升级远不止是换个运行环境那么简单。它意味着你需要重新理解整个Java应用的停顿时间模型、内存管理策略和性能调优思路。很多人卡在升级这一步不是因为代码不兼容——事实上JDK17对大部分JDK8程序兼容性很好——而是因为对新的GC体系感到陌生不知道如何为生产环境选择合适的回收器以及如何配置参数。所以这篇文章不会只讲“如何安装JDK17”那是第一步。我会重点拆解JDK8到JDK17中五大垃圾回收器Serial, Parallel, CMS, G1, ZGC/Shenandoah的核心工作原理、适用场景、配置要点和升级后的实战调优思路。无论你是运维、架构师还是开发只要你的服务对延迟敏感或者内存规模较大这篇文章都能帮你理清升级路上最关键的一环。2. 升级准备环境、兼容性与第一个可运行验证在深入GC之前必须确保基础升级流程是顺畅的。很多人一上来就研究高深的GC调优结果连环境都没搭对。2.1 环境选择与安装要点从网络热词看大家最关心的是安装。对于生产环境我强烈建议使用LTS长期支持版本。JDK8和JDK17都是LTS版本稳定性有保障。不要轻易使用非LTS版本如JDK18, 19, 20作为生产基准。下载来源优先从官方渠道如 adoptium.net 提供Temurin发行版或Oracle官网下载。避免使用来路不明的安装包。对于Linux服务器通常直接下载tar.gz压缩包解压即可比RPM/DEB包更灵活便于多版本共存。安装与多版本共存这是关键。你不需要卸载旧版本。在Linux/Mac上通过JAVA_HOME环境变量和PATH来切换版本是最佳实践。# 假设你将JDK17解压到了 /opt/java/jdk-17.0.11 export JAVA_HOME/opt/java/jdk-17.0.11 export PATH$JAVA_HOME/bin:$PATH在Windows上同样通过系统环境变量JAVA_HOME和修改Path来指定。IDEA等IDE可以单独为每个项目指定JDK不影响全局。验证安装安装后第一个命令不是跑业务应用而是验证基础信息。java -version确认输出的是JDK 17。然后跑一个最简单的Hello World程序确保能编译和运行。javac Hello.java java Hello这个步骤能排除90%的基础环境问题比如路径错误、安装包不完整等。2.2 代码与依赖兼容性快速检查JDK17移除了不少在JDK8中已被标记为“过时”deprecated的API并加强了模块化封装。你的应用能否跑起来取决于代码和依赖库。核心检查点内部API访问如果你的代码或依赖库使用了sun.misc.*或sun.reflect.*等内部API在JDK17默认的强封装下会抛出IllegalAccessError。这是最常见的兼容性问题。废弃的GC组合在启动参数中不能再使用-XX:UseConcMarkSweepGCCMS。如果启动脚本里还有这个参数应用将无法启动。第三方依赖重点检查那些多年未更新的基础库如老版本的Apache Commons、网络客户端、序列化工具等。使用Maven或Gradle的依赖树分析工具查看是否有已知的不兼容依赖。快速测试方法不要直接在生产代码上测试。建立一个隔离的测试环境将你的应用打包JAR或WAR用JDK17启动并加上-XX:ShowCodeDetailsInExceptionMessages参数它能提供更详细的错误信息。观察启动日志和初期运行是否报错。如果遇到内部API访问错误短期解决方案是在启动命令中添加JVM参数来开放这些内部包--add-opens java.base/java.langALL-UNNAMED --add-opens java.base/sun.nio.chALL-UNNAMED # ... 根据错误信息添加对应的 --add-opens 参数但这只是权宜之计长期来看应推动依赖库升级或修改代码。3. 五大垃圾回收器深度拆解从原理到选型环境搞定后我们来直面核心垃圾回收器。JDK17可用的回收器主要有五类它们的设计目标和适用场景截然不同。3.1 Serial 与 Parallel基础与吞吐量的代表Serial GC这是一个单线程回收器。在进行垃圾回收时必须暂停所有应用线程Stop-The-World。它的优势是简单、开销极小没有线程交互的开销。在JDK17中它依然存在但仅适用于客户端应用或微型服务比如内存几十兆或者对吞吐量没要求、资源极度受限的环境如嵌入式。启用参数-XX:UseSerialGC。Parallel GC (吞吐量收集器)JDK8的默认GC。它的目标是最大化应用程序的吞吐量即CPU用于运行用户代码的时间占比。为了达到这个目标它在年轻代和老年代都使用多线程进行并行垃圾回收但同样会发生Stop-The-World停顿且停顿时间可能较长。如果你的应用是后台计算密集型任务如批量处理、科学计算对延迟不敏感那么Parallel GC可能仍然是JDK17下的一个好选择。启用参数-XX:UseParallelGC。选型建议对于绝大多数从JDK8升级上来的Web应用或微服务不再建议使用Parallel GC作为默认选择。因为现代应用更关注请求的响应速度低延迟而非纯粹的吞吐量。3.2 CMS昔日王者的落幕与替代方案CMS (Concurrent Mark Sweep)这是JDK8时代很多中大型互联网服务的“标配”。它的设计目标是降低老年代回收的停顿时间。它的大部分标记和清理工作是与应用线程并发进行的只有在初始标记和重新标记阶段需要短暂停顿。为什么被移除CMS有几个致命缺点1)内存碎片化严重可能导致Full GC时出现不可预测的长停顿2) 对CPU资源非常敏感并发阶段会与应用线程争抢CPU3)无法处理“浮动垃圾”可能在并发清理阶段因应用线程产生新垃圾而导致“Concurrent Mode Failure”进而触发一次Full GC。正因为这些难以根治的问题它在JDK14中被标记为废弃在JDK17中被彻底移除。升级后怎么办如果你原来的应用使用CMS升级到JDK17后G1 GC是首选的直接替代品。G1同样致力于可控的停顿时间但通过将堆内存划分为多个Region、引入预测模型和并行压缩避免了CMS的碎片化问题。你需要将启动参数从-XX:UseConcMarkSweepGC改为-XX:UseG1GC。3.3 G1JDK9后的默认王者与核心调优从JDK9开始G1取代Parallel成为默认垃圾回收器这是有重大意义的。G1的设计目标是在延迟可控的情况下尽可能获得高吞吐量。它不再坚持传统分代物理连续而是将堆划分为多个大小相等的Region。核心工作流程年轻代回收 (Young GC)当Eden区满时触发采用多线程并行复制存活对象到Survivor区或老年代Region。这个过程是Stop-The-World的但G1会尽量高效完成。并发标记周期 (Concurrent Cycle)这不是每次Young GC都触发。当堆占用达到一定阈值默认45%时启动。它包括初始标记、根区域扫描、并发标记、最终标记、清理等阶段。其中初始标记和最终标记需要停顿其他阶段并发。混合回收 (Mixed GC)在并发标记周期之后G1知道哪些Region里垃圾最多。Mixed GC会不仅回收年轻代Region还会选择性地回收一部分垃圾多的老年代Region。这是G1实现可控停顿的关键。Full GCG1设计上尽量避免Full GC。但如果并发收集速度赶不上对象分配速度或者Mixed GC无法回收足够空间就会退化为单线程的Serial Old GC进行Full GC停顿会非常长。调优的核心目标之一就是避免Full GC。关键调优参数-XX:MaxGCPauseMillis200这是目标值不是保证值。G1会尽力达成但不承诺。设置一个合理的期望如100-200ms不要设得太小如20ms否则G1会过度收缩年轻代导致频繁GC反而降低吞吐量。-XX:G1HeapRegionSizeRegion大小范围1MB到32MB。通常不用设G1会根据堆大小自动计算。堆很大4G时可以考虑显式设置如16M来平衡管理开销和回收粒度。-XX:InitiatingHeapOccupancyPercent45触发并发标记周期的堆占用阈值。如果老年代对象增长很快可以适当调低此值如40让G1更早开始标记为Mixed GC预留时间。-XX:G1ReservePercent10保留空间用于晋升失败时的“兜底”。如果频繁发生晋升失败可以适当提高此值。G1适用场景适用于从JDK8升级上来的绝大多数应用特别是内存从6G到几十G要求停顿时间在几百毫秒可控范围内的服务。它是平衡吞吐量和延迟的“万金油”选择。3.4 ZGC与Shenandoah面向未来的超低延迟神器如果你的应用对停顿时间有极致要求目标停顿时间在10ms以下甚至亚毫秒级并且堆内存非常大百G级别那么你需要关注ZGC和Shenandoah。它们在JDK17中已是生产可用状态。共同核心思想它们都采用了染色指针和读屏障技术使得垃圾回收的绝大部分工作包括标记、转移/压缩都能与应用线程并发执行从而将Stop-The-World停顿时间缩短到与堆大小无关的极低水平通常1ms甚至0.1ms。ZGC由Oracle开发JDK15成为生产特性。其停顿时间几乎全部来自于GC周期的开始和结束阶段。启用参数-XX:UseZGC。它还有一个实验性的分代版本ZGenerational在JDK21中引入旨在进一步提升吞吐量。Shenandoah由Red Hat开发JDK12成为生产特性。其工作流程与ZGC类似但实现细节不同。启用参数-XX:UseShenandoahGC。关键配置与代价内存开销为了实现并发转移它们需要额外的内存来存储元数据通常会有10%-20%的堆内存开销。CPU开销读屏障会带来一定的CPU指令开销可能对极限吞吐量有轻微影响通常5%。参数简单它们的调优参数远比G1简单。通常只需要设置堆大小-Xmx和目标停顿时间如ZGC的-XX:MaxGCPauseMillis大部分工作由回收器自适应完成。选型建议新应用或对延迟有严苛要求的应用如果资源内存、CPU充足直接上ZGC或Shenandoah。它们能提供近乎“无感”的GC体验。从G1升级如果你的应用在使用G1时停顿时间gc_pause仍然无法满足SLA要求并且堆内存较大可以考虑切换到ZGC/Shenandoah。注意在JDK17中ZGC和Shenandoah不支持类数据共享和压缩指针这意味着它们的内存占用可能会比G1稍高。同时确保你的监控工具如Prometheus Grafana支持这些新GC的指标暴露。4. 升级实战参数迁移、监控与性能验证理论清楚了现在来落地。升级JDK并切换GC不是改个版本号就完事了必须有一套验证流程。4.1 启动参数迁移与适配这是升级过程中最需要谨慎处理的部分。以下是一个常见的参数迁移对照示例JDK8 (CMS) 典型参数JDK17 (G1) 对应参数/建议说明-Xms4g -Xmx4g-Xms4g -Xmx4g堆大小通常保持不变。G1建议不设置-Xmn年轻代大小让它自适应。-XX:UseConcMarkSweepGC-XX:UseG1GC必须修改。这是核心变更。-XX:UseParNewGC(移除)CMS的年轻代回收器G1自有其年轻代回收。-XX:CMSInitiatingOccupancyFraction75-XX:InitiatingHeapOccupancyPercent45触发并发标记的阈值。G1默认45更激进可根据老年代增长情况调整。-XX:UseCMSInitiatingOccupancyOnly(移除)G1无此参数。-XX:CMSParallelRemarkEnabled(移除)G1无此参数。-XX:ExplicitGCInvokesConcurrent(通常移除)处理System.gc()。G1会将其视为一次Full GC请求可考虑用-XX:DisableExplicitGC禁用显式GC或依赖G1自身逻辑。-XX:ParallelGCThreads8-XX:ParallelGCThreads8并行GC线程数可保留。G1的Young GC和Mixed GC阶段会使用。-XX:ConcGCThreads4-XX:ConcGCThreads4并发GC线程数可保留。G1的并发标记阶段会使用。启动脚本调整示例# JDK8 CMS 风格 (已过时) java -Xms4g -Xmx4g -XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction75 -XX:UseCMSInitiatingOccupancyOnly -jar your-app.jar # JDK17 G1 风格 java -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -jar your-app.jar可以看到G1的参数更简洁。不要简单地把CMS参数堆砌到G1上很多参数不兼容或无效。4.2 监控指标如何判断新GC是否工作良好升级后必须通过监控来验证GC行为。关键指标如下GC日志这是第一手资料。在启动参数中添加详细的GC日志输出。-Xlog:gc*,gcheapdebug,gcergo*trace,gcage*trace:filegc.log:time,uptime,level,tags:filecount10,filesize10m这个参数会输出非常详细的G1日志到文件。重点关注Pause Time每次Young GC、Mixed GC的停顿时间。是否接近你设定的MaxGCPauseMillis目标GC Cycles观察并发标记周期和混合回收的发生频率。To-space Exhausted / Evacuation Failure出现这些说明回收速度跟不上分配速度可能触发Full GC需要调整参数如增加堆大小、降低IHOP、增加G1ReservePercent。JVM内置工具jstat -gcutil pid 1s实时查看各内存区域使用率和GC次数/时间。jcmd pid GC.heap_info查看堆概要信息。可视化监控生产必备将JVM指标通过JMX或Micrometer暴露给监控系统如Prometheus在Grafana中制作仪表盘。核心看板应包括堆内存使用趋势老年代、新生代的占用变化。GC暂停时间分布Young GC和Mixed GC的停顿时间百分位数P50, P90, P99, P999。GC吞吐量应用运行时间占比。GC原因是什么触发了GCAllocation Failure, System.gc等。4.3 性能压测与对比验证在预发布或隔离环境进行压测对比升级前后的关键性能数据基准测试使用像wrk,jmeter等工具模拟生产流量。对比指标吞吐量 (RPS/QPS)是否下降如果使用ZGC/Shenandoah轻微下降5%是可接受的因为换来了极低延迟。延迟 (P99, P999 Latency)这是最重要的指标。升级到G1/ZGC后长尾延迟P99应该有显著改善。如果延迟反而变差需要检查参数配置。系统资源CPU使用率、系统内存占用。ZGC/Shenandoah的CPU开销可能略高。异常情况测试模拟内存泄漏、流量尖峰观察GC的行为和应用的恢复能力。5. 常见问题排查与进阶调优思路即使按照上述步骤操作在生产环境仍可能遇到问题。以下是典型的排查路径。5.1 应用启动失败或立即崩溃现象Error: Could not create the Java Virtual Machine.或Unrecognized VM option。排查检查启动参数首要怀疑是残留的CMS相关参数如UseConcMarkSweepGC。用java -XX:PrintFlagsFinal可以查看所有有效参数。检查--add-opens等模块化参数是否正确。检查环境变量JAVA_HOME和PATH确保指向的是JDK17。5.2 频繁Full GC或长时间停顿现象监控显示频繁发生Full GC或者Young/Mixed GC的停顿时间远超预期如秒级。排查顺序看GC日志找到触发Full GC的原因。常见原因是“Evacuation Failure”晋升失败或“System.gc()”。检查内存分配速率使用jstat -gc pid 1s观察Eden区的增长速度。如果分配速率极高G1可能来不及回收。考虑优化代码减少对象创建。调整G1参数晋升失败尝试增加-XX:G1ReservePercent如从10调到20为晋升预留更多空间。或者适当增加堆大小-Xmx。并发模式失败调低-XX:InitiatingHeapOccupancyPercent让G1更早启动并发标记。停顿时间过长确认-XX:MaxGCPauseMillis设置是否合理通常200ms。如果Region太多堆太大RegionSize太小GC时选择收集的Region集合CSet可能过大导致一次回收时间过长。可以考虑适当增大-XX:G1HeapRegionSize。检查代码是否存在内存泄漏使用jmap -histo:live pid或Profiler工具如Async-Profiler, JProfiler分析堆中对象类型看是否有异常累积的对象。5.3 切换到ZGC/Shenandoah后吞吐量下降明显现象延迟降低了但每秒处理请求数RPS下降超过10%。排查确认CPU开销使用系统监控工具如top,htop观察应用进程的CPU使用率。ZGC/Shenandoah的读屏障会带来额外CPU指令。调整并发线程数ZGC有-XX:ConcGCThreads参数。默认值可能不适合你的机器。可以尝试调整但并非越多越好需要平衡GC和应用线程。评估是否值得对于高吞吐量优先的批处理任务切换回G1或Parallel可能是更优选择。超低延迟GC的代价就是一定的CPU开销。5.4 元空间Metaspace问题现象java.lang.OutOfMemoryError: Metaspace。排查JDK8中的永久代PermGen已被元空间取代。元空间使用本地内存默认上限很大。出现此错误通常是因为应用动态生成大量类如大量使用CGLIB、ASM、动态代理。部署了多个应用且未使用共享类数据。类加载器泄漏这是最常见原因。某个类加载器如Webapp ClassLoader加载的类无法被卸载导致元空间只增不减。解决增加-XX:MaxMetaspaceSize限制并监控其使用情况。更重要的是使用jcmd pid GC.class_stats或jmap -clstats pid分析类加载器找到泄漏根源。5.5 容器环境Docker/K8s下的特殊考量在容器中运行Java应用非常普遍但JVM早期版本无法感知容器资源限制。关键参数在JDK8 update 191和JDK10JVM提供了对容器CPU和内存限制的自动支持。但在JDK17下为了最佳实践建议显式设置-XX:UseContainerSupport # 默认已开启确保使用 -XX:MaxRAMPercentage75.0 # 使用容器内存的75%作为堆上限 -XX:InitialRAMPercentage50.0 # 初始堆大小为容器内存的50%不要再使用-Xmx和-Xms指定绝对数值而是使用百分比让JVM根据容器实际分配的内存来调整。同时确保容器内存限制设置合理并预留足够空间给非堆内存元空间、线程栈、直接内存等。升级JDK17并驾驭新的垃圾回收器是一个从“能用”到“用好”的过程。我的建议是先在测试环境用G1跑通你的应用观察监控理解其行为模式。如果延迟满足要求G1就是最稳妥的选择。如果追求极致低延迟且资源充足再尝试ZGC。记住没有最好的GC只有最适合你应用场景和资源约束的GC。每一次参数调整都要有监控数据作为依据而不是盲目猜测。