⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7343440691680870451 「winjeg」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

背景 TLDR

垃圾回收器的暂停问题对实时响应要求较高的服务来说，一直是个痛点， CMS和G1等主流垃圾回收器的数十毫秒乃至上百毫秒的暂停时间相当致命。此外，调优门槛也相对较高，需要对垃圾回收器的内部机制有一定的了解，才能够进行有效的调优。随着ZGC的出现，使得这一痛点彻底解决， ZGC 最初在 JDK 11 中作为实验性功能引入，并在 JDK 15 中宣布为生产就绪，由于JDK17才是比较正式提供给大众实用的LTS支持版本，而且一部分公司已经在使用，所以本文力推JDK17。

ZGC 作为一款低延迟垃圾收集器，旨在满足以下目标：

8MB到16TB的堆大小支持
10ms最大GC暂时
最糟糕的情况下吞吐量会降低15%（实测，如果参数配置的问题可能更糟，官方这个稍微吹牛了点，说实话就是用CPU换GC时间，也没有那么高大上）

升级JDK17的不可拒绝的理由

低延迟的业务需求，毫秒级耗时的GC

据美团的开发说：

在Zeus服务不同集群中，ZGC在低延迟（TP999 < 200ms）场景中收益较大：

TP999：下降12~142ms，下降幅度18%~74%。

TP99：下降5~28ms，下降幅度10%~47%。

可以忽略的升级JDK17的理由

新版的SpringBoot 官方最低支持 JDK17，想使用新Spring版本，就得升级
JIT 编译器的增强
JDK 17 中的新功能，例如 Sealed 类、Pattern Matching、Records 等
升级到 JDK 17 可以获得更好的安全性，包括修复的漏洞和强化的安全机制

适用场景

网关服务
Web API

暂不推荐场景：定时任务、批量任务、高CPU密集型应用

升级前后对比

话不多说，先看效果

环境：

CPU： 4c
Mem: 6GB

G1参数：

-Xmx3500m -Xms3500m -XX:+UseG1GC -XX:MaxGCPauseMillis=100
-XX:G1ReservePercent=10 -XX:ConcGCThreads=2 -XX:ParallelGCThreads=5
-XX:G1HeapRegionSize=16m -XX:MaxTenuringThreshold=14
-XX:SurvivorRatio=8

ZGC参数：

--add-opens=java.base/java.lang=ALL-UNNAMED -Xms3500m -Xmx3500m -XX:ReservedCodeCacheSize=256m -XX:InitialCodeCacheSize=256m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:ConcGCThreads=1 -XX:ParallelGCThreads=3 -XX:ZCollectionInterval=60 -XX:ZAllocationSpikeTolerance=4 -XX:+UnlockDiagnosticVMOptions -XX:-ZProactive  -Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/opt/gc-%t.log:time,tid,tags:filecount=5,filesize=50m

上述两个参数，均已经在生产环境实验过，生产环境的机器是单机拥有1500业务tps的机器

GC耗时对比

从上图可见， GC耗时是有着质的区别的，这个区别是你用CMS、Parallel GC、 G1 等呕心沥血也调校不出来的

这么短的GC，可以保证，应用因为JVM层面的卡顿都保持在1ms 以内，这也是为啥说这点才是不能拒绝的理由

CPU使用对比

从CPU使用上看， JDK17 相同的代码，比JDK8要高出10 ~ 20%

升级方法

1. JDK选择或安装

使用JDK17前必须要安装JDK17，对于不同的Linux发行版或者操作系统安装方法各不相同，下面给出了一些样例，仅供参考。

# ubuntu 安装jdk17
sudo apt install openjdk-17-jdk

# docker 基础镜像
docker pull openjdk:17-slim
docker pull openjdk:17-jdk-oraclelinux7
Dockerfile

复制代码FROM openjdk:17-slim

2. JVM 参数调整

有了JDK17后，你已经具备了让你的Java程序运行在JDK17上的基本条件了，下一步便是配置Jvm 参数如下（有需要的话，可以自行把换行整理下）：

--add-opens=java.base/java.lang=ALL-UNNAMED \
-Xms1500m -Xmx1500m \
-XX:ReservedCodeCacheSize=256m \
-XX:InitialCodeCacheSize=256m \ 
-XX:+UnlockExperimentalVMOptions \
-XX:+UseZGC \
-XX:ConcGCThreads=1 -XX:ParallelGCThreads=2 \
-XX:ZCollectionInterval=30 -XX:ZAllocationSpikeTolerance=5 \
-XX:+UnlockDiagnosticVMOptions -XX:-ZProactive \
-Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/opt/gc-%t.log:time,tid,tags:filecount=5,filesize=50m \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/opt/errorDump.hprof

芋道源码 —— 纯源码解析博客

升级 JDK17 一个不可拒绝的理由！