东莞商城网站开发,wordpress Cute,请解释网站开发的主要流程.,网站建设下一步打算前言
随着JDK17的占有率不断升高和SpringBoot3最低支持JDk17#xff0c;JDK17很大概率会成为大家后续升级的一个选择#xff0c;而JDK17上最重要的垃圾回收器G1和ZGC#xff0c;也就显得格外重要。大家提前了解或者学习一下肯定是有用的。
本篇文章也默认大家了解一…前言
随着JDK17的占有率不断升高和SpringBoot3最低支持JDk17JDK17很大概率会成为大家后续升级的一个选择而JDK17上最重要的垃圾回收器G1和ZGC也就显得格外重要。大家提前了解或者学习一下肯定是有用的。
本篇文章也默认大家了解一些垃圾回收器的知识也不再赘述JDK8上大家比较熟悉的垃圾回收器原理和流程。
G1垃圾回收器
垃圾优先G1垃圾收集器针对多处理器机器可扩展到大量内存。它试图以高概率满足垃圾收集暂停时间目标同时实现高吞吐量几乎不需要配置。G1旨在使用当前目标应用程序和环境提供最佳的延迟和吞吐量平衡其特点包括
堆大小可达数十GB或更大其中超过50的Java堆被实时数据占用。对象分配和提升的速率可能会随时间变化而显着变化。堆中存在大量碎片。可预测的暂停时间目标不超过几百毫秒避免长时间的垃圾收集暂停。
这在应用程序运行时使用一个或多个垃圾收集线程时最为明显。因此与吞吐量收集器相比虽然G1收集器的垃圾收集暂停时间通常要短得多但应用程序的吞吐量也稍微较低。
上面就是官网对于G1的介绍不难看出G1有几个特点。适合大内存、几乎不需要配置、可以预测STW时间、吞吐量要略低。
内存布局
G1的内存布局和之前的有一些不太一样但是还是保留了垃圾分代的特点。内存布局如下图 G1将内存分为不同的region,每个region大小相同。其中主要包含了四种不同的区域。年轻代Eden图中未标字母的红色区域、幸存者区域Suivivor图中标有S的区域、老区域Old图中未标字母的蓝色区域、大对象区域Humongous图中标H的大块区域。
回收流程
G1回收流程主要是两个阶段交替。young-only阶段和Space-reclamation阶段也叫混合GC。具体的交替图如下 young-only阶段是只处理年轻代的一个阶段包含了以下流程。
Concurrent Start这种类型的收集在执行普通的年轻代收集的同时还开始了标记过程。并发标记确定了老年代区域中当前可达活动的所有对象以便在接下来的空间回收阶段保留这些对象。标记过程在两个特殊的停顿中完成Remark和Cleanup。并发启动暂停还可能确定是否要继续Remark阶段在这种情况下会发生一个短暂的并发标记撤销阶段然后继续进行年轻代阶段。同时在这种情况下不会发生Remark和Cleanup。要注意本阶段类似CMS垃圾回收器的并发标记不会产生STW。Remark这个阶段会STW执行引用处理和类卸载回收完全空的区域并清理内部数据结构。在Remark和Cleanup之间G1会计算信息以便稍后能够并发地回收选定的老年代区域中的空闲空间这将在Cleanup阶段中完成。Cleanup这个阶段也会STW同时该阶段也决定是否实际进行Space-reclamation阶段。如果后续需要进行Space-reclamation阶段young-only阶段将以一次准备Space-reclamation阶段回收为结束。
Space-reclamation阶段会伴随多次young-only阶段除了年轻代区域外还会疏散一组老年代区域中的活动对象。这些收集也称为混合收集。当G1确定疏散更多的老年代区域不会产生足够的空闲空间时Space-reclamation阶段结束。
备注
young-only阶段可能不会进行垃圾回收如果计算垃圾回收的耗时远小于设定的值会积攒多次最后一块垃圾回收。young-only阶段只会回收年轻代区域和大对象区域Space-reclamation阶段不仅包含了这两个还有老年代区域。G1的区域回收是使用复制算法将region内的数据整理后复制到新的region中当前region直接清除。如果G1尝试垃圾收集后内存还是很紧张以至于无法找到多余的空间进行复制迁移时会触发Full GC这种GC是单线程的会很慢。
上面的流程可能一部分知识有误因为能力有限翻译过来也存在一些不通的情况。欢迎大家指正。
参数和最佳实践
G1的一些重要参数如下
Option and Default ValueDescription-XX:MaxGCPauseMillis200最大暂停时间的目标。-XX:GCPauseTimeIntervalergo最大STW间隔的目标。默认情况下G1不设定任何目标允许G1在极端情况下连续执行垃圾收集。-XX:ParallelGCThreadsergo垃圾收集暂停期间的最大并行工作线程数。这个数值是根据虚拟机所在计算机上可用的线程数量来确定的如果可用于进程的CPU线程数小于或等于8则使用该数量。否则将大于8的线程数的五分之八加到最终的线程数中。在每次暂停开始时最大使用的线程数还受到其他参数限制G1不会使用超过-XX:HeapSizePerGCThread的线程数-XX:ConcGCThreadsergo用于并发工作的最大线程数。默认情况下该值为-XX:ParallelGCThreads除以4。-XX:G1UseAdaptiveIHOP-XX:InitiatingHeapOccupancyPercent45控制初始堆占用的。默认值表明自适应已开启并且在最初的几个收集周期中G1将使用老年代45%的作为标记开始阈值。-XX:G1HeapRegionSizeergo 堆区域的大小。默认值基于最大堆大小并计算出大约2048个区域然后相除得到这个值。用户指定的大小必须是2的幂次方有效值范围为1到512 MB。-XX:G1NewSizePercent5-XX:G1MaxNewSizePercent60年轻代的总大小在这两个值之间变化以当前使用的 Java 堆的百分比表示。-XX:G1HeapWastePercent5垃圾回收候选中允许的未回收空间。如果垃圾回收候选列表中的可用空间低于该值G1将停止Space-reclamation阶段。-XX:G1MixedGCCountTarget8Space-reclamation阶段在一系列收集中的预计持续时间。-XX:G1MixedGCLiveThresholdPercent85在Space-reclamation阶段中如果老年代区域的存活对象占用率高于这个百分比那么这些区域将不会被回收。
ergo代表这个值需要根据实际情况做判断。
官方对于G1的最佳实践没有说太多对于一般应用的建议也是使用默认值即可不怎么需要调整因为一些参数会在G1运行中自我调整。使用过程中只需要按照大家的要求设置期望暂停时间和最大堆大小即可。然而大家需要知道的是G1在默认配置中的目标既不是最大吞吐量也不是最低延迟而是在高吞吐量下提供相对较小、均匀的暂停。并且G1回收堆空间的机制和暂停时间控制会在应用程序线程和空间回收效率方面产生一些开销这也就是大家常说的应用内存不大的话没必要考虑G1。
如果需要应用高吞吐量则可以通过使用或提供更大的堆来放宽暂停时间目标。如果延迟是主要要求则修改暂停时间目标。不要设置-Xmn -XX:NewRatio等参数因为这些参数会导致期望暂停时间失效。所以从JDK8迁移到JDK17时要丢弃所有的参数配置并且仅设置暂停时间目标和总体堆-Xmx大小-Xms。如果不满足要求再按照上面的表格进行一些微调。
当然JVM参数不能简单的通过一两篇博客就能设置好具体的参数配置还是要结合GC的日志和对于应用的期望。本人这一块实践也比较少也欢迎大家交流和指正。如果对这一部分感兴趣可以看看oracle的调优建议。G1垃圾调优
ZGC垃圾回收器
先问两个小问题
ZGC中的Z代表什么意思ZGC怎么读“zed gee see”还是“zee gee see”
我们使用的最新的JDK为17版本ZGC还是一个初步实现的版本并没有做分代虽然是简单实现但是也足够优秀。目前网络上也都是基于这个版本写的文章但是我看到2023年JVM语言峰会上JDK21上的ZGC已经是较为完善的版本了所以本次也就直接学习JDK21版本的ZGC不再讲述低版本的ZGC。
新版本的ZGC更加的强大并且主打的就是更强更智能基本不需要参数的调整。下面是我整理的一些特点。
支持最大16TB的堆。低延迟一毫秒到几毫秒。简单的配置几乎不需要配置。
同时新版本相较于ZGC的老版本也有很大的提升具体可以看下图 可以说吞吐量是之前的4倍并且内存减少了75%。所以分代ZGC是未来的趋势。
内存布局
内存布局和之前的ZGC不太一样不再按照大小区分region和G1类似直接分为两种类型年轻代和老年代。 回收流程
新版ZGC的运行流程如下图 第一阶段就是并发标记同时这一阶段也会对上一个周期的移动的对象的引用进行重新映射。并发标记结束后会有一个STW然后就是准备并发搬迁。这个准备阶段也会做一些类卸载的操作。最后就是并发迁移。
同时年轻代和老年代的回收也是并发的ZGC这个版本可以说一个并发垃圾回收器。 备注 参数配置和实践
使用分代的ZGC需要使用下面的参数-XX:UseZGC -XX:ZGenerational只使用ZGC可以配置为-XX:UseZGC
ZGC的参数很少几乎不需要配置。
不需要设置年轻代的大小这个计算太复杂并且要很有经验才能估算出一个大概值ZGC自己做了。也不需要设置内存的回收阈值就算堆内存满了也可以使用原地压缩进行原地复制所以不会想G1出现回收失败的情况导致Full GC。也不需要设置年轻代多长时间转换到老年代。不同的阶段可能这个值是变化的ZGC也帮我们做了。什么时候开始老年代的收集这个成本模型计算很复杂ZGC也不需要我们做了。回收时使用多少线程ZGC回收时能动态设置线程数也不需要我们设置参数了。
那我们需要设置什么只有一个参数-Xmx就是堆的大小听起来挺不错的。
技术难点
技术难点因为本人能力有限而且JDK21版本23年才出来所以一部分的技术难点分析需要看源码才能了解透彻。这里就是简单说一下。
颜色指针 读屏障
垃圾回收器未来展望
随着JDK21引入了虚拟线程的概念这部分的垃圾回收就变的不太好处理了。因为没法找到一个时间节点去回收所有虚拟线程的垃圾。所以有了一个新的概念线程本地GC。 结尾
本次解释了目前比较新的垃圾回收器也简单分析了一下技术上的细节同时对于一些未来的技术做了一个小小的展望。当然很多都是参考一些会议上的记录本人能力有限可能中间一些翻译和理解有错误也欢迎大家指正。会议的资料地址JVMLS2023
就这样吧结束。
