qq群网站制作,哈尔滨最新通知,windows优化大师好吗,会展中心网站平台建设方案文章目录 版权声明垃圾回收器的技术演进ShenandoahShenandoah GC体验Shenandoah GC循环过程 ZGCZGC简介ZGC的版本更迭ZGC体验使用ZGC的参数设置ZGC的调优 版权声明
本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明#xff0c;所有版权属于黑马… 文章目录 版权声明垃圾回收器的技术演进ShenandoahShenandoah GC体验Shenandoah GC循环过程 ZGCZGC简介ZGC的版本更迭ZGC体验使用ZGC的参数设置ZGC的调优 版权声明
本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明所有版权属于黑马程序员或相关权利人所有。本博客的目的仅为个人学习和交流之用并非商业用途。我在整理学习笔记的过程中尽力确保准确性但无法保证内容的完整性和时效性。本博客的内容可能会随着时间的推移而过时或需要更新。若您是黑马程序员或相关权利人如有任何侵犯版权的地方请您及时联系我我将立即予以删除或进行必要的修改。对于其他读者请在阅读本博客内容时保持遵守相关法律法规。本博客中的部分观点和意见仅代表我个人不代表黑马程序员的立场。
垃圾回收器的技术演进 CMS会产生内存碎片没有整理功能会导致最终产生需要碎片导致内存浪费 解决方案
产生FULLGC并且进行整理此时会产生长时间STW退化成串行回收产生长时间的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这些阶段大致执行以下操作
Init Mark初始化标记启动并发标记。它为堆和应用程序线程准备并发标记然后扫描根集。这是周期中的第一次暂停最主要的时间消耗者是根集扫描。因此其持续时间依赖于根集的大小。Concurrent Marking并发标记遍历堆并追踪可达对象。这个阶段与应用程序并行运行其持续时间取决于堆中活跃对象的数量和对象图的结构。由于应用程序在此阶段可以自由分配新数据因此堆占用率在并发标记期间上升。Final Mark最终标记通过排空所有待处理的标记/更新队列并重新扫描根集来完成并发标记。它还通过确定要疏散的区域收集集、预先疏散一些根并通常为下一个阶段准备运行时来初始化疏散。这部分工作可以在Concurrent Precleaning并发预清理阶段并发完成。这是周期中的第二次暂停这里最主要的时间消耗者是排空队列和扫描根集。Concurrent Cleanup并发清理回收即时垃圾区域——即并发标记后检测到没有活跃对象存在的区域。Concurrent Evacuation并发疏散将对象从收集集复制到其他区域。这是与其他OpenJDK GCs的主要区别。这个阶段再次与应用程序并行运行因此应用程序可以自由分配。其持续时间取决于本周期选择的收集集的大小。Init Update Refs初始化更新引用启动更新引用阶段。它几乎不做任何事情只确保所有GC和应用程序线程已完成疏散然后为下一个阶段准备GC。这是第三次暂停也是所有中最短的。Concurrent Update References并发更新引用遍历堆并更新在并发疏散期间移动的对象的引用。这是与其他OpenJDK GCs的主要区别。其持续时间取决于堆中的对象数量但不依赖于对象图的结构因为它是线性扫描堆的。这个阶段与应用程序并行运行。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]构建 Docker 镜像并运行容器 并配置 ZGC 的 Java 应用程序
docker build -t your-image-name .
docker run -d -p 8080:8080 your-image-nameZGC的参数设置
ZGC在设计上做到了自适应根据运行情况自动调整参数让用户手动配置的参数最少化。 自动设置年轻代大小无需设置-Xmn参数。自动晋升阈值复制中存活多少次才搬运到老年代无需设置-XX:TenuringThreshold。JDK17之后支持自动的并行线程数无需设置-XX:ConcGCThreads。 需要设置的参数 -Xmx 值 最大堆内存大小ZGC最重要的一个参数必须设置。ZGC在运行过程中会使用一部分内存用来处理垃圾回收所以尽量保证堆中有足够的空间。设置多少值取决于对象分配的速度根据测试情况来决定。可以设置的参数 -XX:SoftMaxHeapSize值ZGC会尽量保证堆内存小于该值在内存靠近这个值时会尽早地进行垃圾回收但是依然有可能会超过该值。例如-Xmx5g -XX:SoftMaxHeapSize4g ZGC会尽量保证堆内存小于4GB最多不会超过5GB。
ZGC的调优
ZGC 中可以使用Linux的Huge Page大页技术优化性能提升吞吐量、降低延迟。 注意安装过程需要 root 权限所以ZGC默认没有开启此功能。 操作步骤
计算所需页数Linux x86架构中大页大小为 2 M B 2MB 2MB根据所需堆内存的大小估算大页数量。比如堆空间需要 16 G 16G 16G预留 2 G 2G 2GJVM需要额外的一些非堆空间那么页数就是 18 G / 2 M B 9216 18G / 2MB 9216 18G/2MB9216。配置系统的大页池以具有所需的页数需要root权限
$ echo 9216 /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages添加参数 − X X : U s e L a r g e P a g e s -XX:UseLargePages −XX:UseLargePages 启动程序进行测试
