版权声明

• 本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明，所有版权属于黑马程序员或相关权利人所有。本博客的目的仅为个人学习和交流之用，并非商业用途。
• 我在整理学习笔记的过程中尽力确保准确性，但无法保证内容的完整性和时效性。本博客的内容可能会随着时间的推移而过时或需要更新。
• 若您是黑马程序员或相关权利人，如有任何侵犯版权的地方，请您及时联系我，我将立即予以删除或进行必要的修改。
• 对于其他读者，请在阅读本博客内容时保持遵守相关法律法规。
• 本博客中的部分观点和意见仅代表我个人，不代表黑马程序员的立场。

垃圾回收器的技术演进

• CMS会产生内存碎片：没有整理功能，会导致最终产生需要碎片，导致内存浪费
  
• 解决方案：

1. 产生FULLGC并且进行整理，此时会产生长时间STW
2. 退化成串行回收，产生长时间的STW

---

• 新一代的垃圾回收器
  
• 不同的垃圾回收器设计的目标是不同的。Parallel GC、G1更注重较高的吞吐量；Shenandoah、ZGC更注重较低的延迟时间

Shenandoah

• Shenandoah 是由Red Hat开发的一款低延迟的垃圾收集器，Shenandoah 并发执行大部分 GC 工作，包括并发的整理，堆大小对STW的时间基本没有影响。
• Shenandoah GC文档
  

Shenandoah GC体验

• 可以使用docker构建Shenandoah GC体验

# Update the image to the most recent one:
$ docker pull shipilev/openjdk
$ docker pull shipilev/openjdk:17
$ docker pull shipilev/openjdk:11# Run the latest version:
$ docker run --rm -it shipilev/openjdk java -XX:+UseShenandoahGC -Xlog:gc -version
[0.007s][info][gc] Using Shenandoah
...# Run the JDK 17 version:
$ docker run --rm -it shipilev/openjdk:17 java -XX:+UseShenandoahGC -Xlog:gc -version
[0.007s][info][gc] Using Shenandoah
...# Run the JDK 11 version:
$ docker run --rm -it shipilev/openjdk:11 java -XX:+UseShenandoahGC -Xlog:gc -version
[0.008s][info][gc] Using Shenandoah
...

Shenandoah GC循环过程

GC(3) Pause Init Mark 0.771ms
GC(3) Concurrent marking 76480M->77212M(102400M) 633.213ms
GC(3) Pause Final Mark 1.821ms
GC(3) Concurrent cleanup 77224M->66592M(102400M) 3.112ms
GC(3) Concurrent evacuation 66592M->75640M(102400M) 405.312ms
GC(3) Pause Init Update Refs 0.084ms
GC(3) Concurrent update references  75700M->76424M(102400M) 354.341ms
GC(3) Pause Final Update Refs 0.409ms
GC(3) Concurrent cleanup 76244M->56620M(102400M) 12.242ms

• 这些阶段大致执行以下操作：

1. Init Mark（初始化标记）启动并发标记。它为堆和应用程序线程准备并发标记，然后扫描根集。这是周期中的第一次暂停，最主要的时间消耗者是根集扫描。因此，其持续时间依赖于根集的大小。
2. Concurrent Marking（并发标记）遍历堆，并追踪可达对象。这个阶段与应用程序并行运行，其持续时间取决于堆中活跃对象的数量和对象图的结构。由于应用程序在此阶段可以自由分配新数据，因此堆占用率在并发标记期间上升。
3. Final Mark（最终标记）通过排空所有待处理的标记/更新队列并重新扫描根集来完成并发标记。它还通过确定要疏散的区域（收集集）、预先疏散一些根，并通常为下一个阶段准备运行时来初始化疏散。这部分工作可以在Concurrent Precleaning（并发预清理）阶段并发完成。这是周期中的第二次暂停，这里最主要的时间消耗者是排空队列和扫描根集。
4. Concurrent Cleanup（并发清理）回收即时垃圾区域——即，并发标记后检测到没有活跃对象存在的区域。
5. Concurrent Evacuation（并发疏散）将对象从收集集复制到其他区域。这是与其他OpenJDK GCs的主要区别。这个阶段再次与应用程序并行运行，因此应用程序可以自由分配。其持续时间取决于本周期选择的收集集的大小。
6. Init Update Refs（初始化更新引用）启动更新引用阶段。它几乎不做任何事情，只确保所有GC和应用程序线程已完成疏散，然后为下一个阶段准备GC。这是第三次暂停，也是所有中最短的。
7. Concurrent Update References（并发更新引用）遍历堆，并更新在并发疏散期间移动的对象的引用。这是与其他OpenJDK GCs的主要区别。其持续时间取决于堆中的对象数量，但不依赖于对象图的结构，因为它是线性扫描堆的。这个阶段与应用程序并行运行。
8. Final Update Refs（最终更新引用）通过重新更新现有根集来完成更新引用阶段。它还回收收集集中的区域，因为现在堆不再有对那些（过时的）对象的引用。这是周期中的最后一次暂停，其持续时间取决于根集的大小。
   9。 Concurrent Cleanup（并发清理）回收现在没有引用的收集集区域。

ZGC

ZGC简介

• ZGC 是一种可扩展的低延迟垃圾回收器。ZGC 在垃圾回收过程中，STW的时间不会超过一毫秒，适合需要低延迟的应用。支持几百兆到16TB 的堆大小，堆大小对STW的时间基本没有影响。
• ZGC降低了停顿时间，能降低接口的最大耗时，提升用户体验。但吞吐量不佳，所以如果服务关注QPS（每秒的查询次数）G1是比较不错的选择。
  

ZGC的版本更迭

ZGC体验&使用

• OracleJDK和OpenJDK中都支持ZGC，阿里的DragonWell龙井JDK也支持ZGC但属于其自行对OpenJDK 11的
  ZGC进行优化的版本。

• 【建议使用JDK17之后的版本，延迟较低同时无需手动配置并行线程数。】

• 分代 ZGC添加如下参数启用 -XX:+UseZGC -XX:+ZGenerational

• 非分代 ZGC通过命令行选项启用 -XX:+UseZGC

• 使用 adoptopenjdk:17 作为基础镜像，进行体验，创建名称为Dockerfile的普通文本文件

#使用adoptopenjdk作为基础镜像，选择Java 17版本
FROM adoptopenjdk:17-jdk-hotspot#设置工作目录
WORKDIR /app#拷贝应用程序jar包到镜像中
COPY target/your-application.jar /app/your-application.jar#暴露应用程序的端口（如果需要）
EXPOSE 8080#设置启动命令，指定使用ZGC作为垃圾收集器
CMD ["java", "-XX:+UseZGC", "-jar", "your-application.jar"]

2. 构建 Docker 镜像并运行容器， 并配置 ZGC 的 Java 应用程序

docker build -t your-image-name .
docker run -d -p 8080:8080 your-image-name

ZGC的参数设置

• ZGC在设计上做到了自适应，根据运行情况自动调整参数，让用户手动配置的参数最少化。
  • 自动设置年轻代大小，无需设置-Xmn参数。
  • 自动晋升阈值（复制中存活多少次才搬运到老年代），无需设置-XX:TenuringThreshold。
  • JDK17之后支持自动的并行线程数，无需设置-XX:ConcGCThreads。
• 需要设置的参数：
  -Xmx 值 （最大堆内存大小）：ZGC最重要的一个参数，必须设置。ZGC在运行过程中会使用一部分内存用来处理垃圾回收，所以尽量保证堆中有足够的空间。设置多少值取决于对象分配的速度，根据测试情况来决定。
• 可以设置的参数：
  -XX:SoftMaxHeapSize=值：ZGC会尽量保证堆内存小于该值，在内存靠近这个值时会尽早地进行垃圾回收，但是依然有可能会超过该值。例如，-Xmx5g -XX:SoftMaxHeapSize=4g ZGC会尽量保证堆内存小于4GB，最多不会超过5GB。

ZGC的调优

• ZGC 中可以使用Linux的Huge Page大页技术优化性能，提升吞吐量、降低延迟。

• 注意：安装过程需要 root 权限，所以ZGC默认没有开启此功能。

操作步骤：

1. 计算所需页数，Linux x86架构中大页大小为$2MB$，根据所需堆内存的大小估算大页数量。比如堆空间需要$16G$，预留$2G$（JVM需要额外的一些非堆空间），那么页数就是$18G/2MB=9216$。
2. 配置系统的大页池以具有所需的页数（需要root权限）：

$ echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

3. 添加参数$-XX:+UseLargePages$ 启动程序进行测试