怎么做网站设计程序,wordpress链接去除下划线,自适应型网站建设哪家便宜,创意平面设计作品图片ZGC#xff08;The Z Garbage Collector#xff09;是JDK 11中推出的一款低延迟垃圾回收器#xff0c;它的设计目标包括#xff1a;
停顿时间不超过10ms#xff1b;停顿时间不会随着堆的大小#xff0c;或者活跃对象的大小而增加#xff1b;支持8MB~4TB级别的堆#x…ZGCThe Z Garbage Collector是JDK 11中推出的一款低延迟垃圾回收器它的设计目标包括
停顿时间不超过10ms停顿时间不会随着堆的大小或者活跃对象的大小而增加支持8MB~4TB级别的堆未来支持16TB ZGC的目标是希望在尽可能对吞吐量影响不太大的前提下 实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。
在ZGC算法中并没有分代的概念所以就不存在Young GC、Old GC所有的GC行为都是Full GC Region布局
先从ZGC的内存布局说起。
和G1一样ZGC也采用基于Region的堆内存布局但与G1不同的是ZGC的Region具有动态性——动态创建和销毁以及动态的区域容量大小。
在x64硬件平台下ZGC的Region可以有小、中、大、三类容量
小型RegionSmall Region容量固定为2MB用于放置小于256KB的小对象。中型RegionMedium Region容量固定为32MB用于放置大于等于256KB但小于4MB的对象。大型RegionLarge Region容量不固定可以动态变化但必须为2MB的整数倍用于放置4MB或以上的大对象。每个大型Region中只会存放一个大对象这也预示着虽然名字叫作「大型Region」但它的实际容量完全有可能小于中型Region最小容量可低至4MB。大型Region在ZGC的实现中是不会被重分配的因为复制一个大对象的代价非常高昂。 读屏障
之前的GC都是采用写屏障Write Barrier而ZGC采用的是读屏障。
读屏障Load Barriers类似于 Spring AOP 的前置通知。
在ZGC中当读取处于重分配集的对象时会被读屏障拦截通过转发表记录将访问转发到新复制的对象上并同时修正更新该引用的值使其直接指向新对象ZGC将这种行为叫做指针的「自愈能力」。
这样就算GC把对象移动了读屏障也会发现并修正指针于是应用代码就永远都会持有更新后的有效指针而且不需要STW类似JDK里的CAS自旋读取的值发现已经失效了需要重新读取。
好处是第一次访问旧对象访问会变慢但也只会有一次变慢当「自愈」完成后后续访问就不会变慢了。
正是因为Load Barriers的存在所以会导致配置ZGC的应用的吞吐量会变低。不过这点开销是值得的。 染色指针
ZGC收集器有一个标志性的设计是它采用的「染色指针」技术。
ZGC 出现之前 GC 信息保存在对象头的 Mark Word 中如对象的哈希码、分代年龄、锁记录等就是这样存储的。
追踪式收集算法的标记阶段就可能存在只跟指针打交道而不必涉及指针所引用的对象本身的场景。
例如对象标记的过程中需要给对象打上三色标记这些标记本质上就只和对象的引用有关而与对象本身无关。
而ZGC的染色指针将这些信息直接标记在引用对象的指针上。
染色指针是一种直接将少量额外的信息存储在指针上的技术Linux下64位指针的高18位不能用来寻址ZGC的染色指针技术盯上了这剩下的46位指针宽度将其高4位提取出来存储四个标志信息。
当然由于这些标志位进一步压缩了原本就只有46位的地址空间也直接导致ZGC能够管理的内存不可以超过4TB2的42次幂 JVM 可以从指针上直接看到对象的三色标记状态Marked0、Marked1、是否进入了重分配集Remapped、是否需要通过 finalize 方法来访问到Finalizable。
18位预留给以后使用
1位Finalizable标识此位与并发引用处理有关它表示这个对象只能通过finalizer才能访问
1位Remapped标识设置此位的值后对象未指向relocation set中relocation set表示需要GC的Region集合
1位Marked1标识
1位Marked0标识和上面的Marked1都是标记对象用于辅助GC
42位对象的地址所以它可以支持2^424T内存
染色指针的优势
染色指针主要有三大优势
染色指针可以使得一旦某个Region的存活对象被移走之后这个Region立即就能够被释放和重用掉而不必等待整个堆中所有指向该Region的引用都被修正后才能清理。理论上只要还有一个空闲RegionZGC就能完成收集。染色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量ZGC只使用了读屏障。因为信息直接维护在指针中。染色指针可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据以便日后进一步提高性能。 如果开发了前18位指针既可以腾出已用的4个标志位将ZGC可支持的最大堆内存从4TB拓展到64TB也可以利用其余位置再存储更多的标志譬如存储一些追踪信息来让垃圾收集器在移动对象时能将低频次使用的对象移动到不常访问的内存区域。 运作过程
ZGC的运作过程大致可划分为以下四个大的阶段。全部四个阶段都是可以并发执行的仅是两个阶段中间会存在短暂的停顿小阶段这些小阶段譬如初始化GC Root直接关联对象的Mark StartZGC的运作过程具体如图所示。 并发标记Concurrent Mark并发标记是遍历对象图做可达性分析的阶段。与G1、Shenandoah不同的是ZGC的标记是在指针上而不是在对象上进行的标记阶段会更新染色指针中的Marked 0、Marked 1标志位。 并发预备重分配Concurrent Prepare for Relocate这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region将这些Region组成重分配集Relocation Set。 重分配集与G1收集器的回收集Collection Set还是有区别的ZGC划分Region的目的并非为了像G1那样做收益优先的增量回收。 相反ZGC每次回收都会扫描所有的Region用范围更大的扫描成本换取省去G1中记忆集的维护成本。 因此ZGC的重分配集只是决定了里面的存活对象会被重新复制到其他的Region中里面的Region会被释放而并不能说回收行为就只是针对这个集合里面的Region进行因为标记过程是针对全堆的。 此外在JDK 12的ZGC中开始支持的类卸载以及弱引用的处理也是在这个阶段中完成的。 并发重分配Concurrent Relocate重分配是ZGC执行过程中的核心阶段这个过程要把重分配集中的存活对象复制到新的Region上并为重分配集中的每个Region维护一个转发表Forward Table记录从旧对象到新对象的转向关系。 得益于染色指针的支持ZGC收集器能仅从引用上就明确得知一个对象是否处于重分配集之中如果用户线程此时并发访问了位于重分配集中的对象这次访问将会被预置的内存屏障所截获然后立即根据Region上的转发表记录将访问转发到新复制的对象上并同时修正更新该引用的值使其直接指向新对象。 ZGC将这种行为称为指针的「自愈”Self-Healing」能力。这样做的好处是只有第一次访问旧对象会陷入转发也就是只慢一次对比Shenandoah的Brooks转发指针那是每次对象访问都必须付出的固定开销简单地说就是每次都慢。 因此ZGC对用户程序的运行时负载要比Shenandoah来得更低一些。 还有另外一个直接的好处是由于染色指针的存在一旦重分配集中某个Region的存活对象都复制完毕后这个Region就可以立即释放用于新对象的分配但是转发表还得留着不能释放掉哪怕堆中还有很多指向这个对象的未更新指针也没有关系这些旧指针一旦被使用它们都是可以自愈的。 并发重映射Concurrent Remap重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用。 这一点从目标角度看是与Shenandoah并发引用更新阶段一样的但是ZGC的并发重映射并不是一个必须要「迫切」去完成的任务因为前面说过即使是旧引用它也是可以自愈的最多只是第一次使用时多一次转发和修正操作。 重映射清理这些旧引用的主要目的是为了不变慢还有清理结束后可以释放转发表这样的附带收益所以说这并不是很「迫切」。因此ZGC很巧妙地把并发重映射阶段要做的工作合并到了下一次垃圾收集循环中的并发标记阶段里去完成反正它们都是要遍历所有对象的这样合并就节省了一次遍历对象图的开销。一旦所有指针都被修正之后原来记录新旧对象关系的转发表就可以释放掉了。
ZGC几乎整个收集过程都全程可并发短暂停顿也只与GC Roots大小相关而与堆内存大小无关因而同样实现了任何堆上停顿都小于十毫秒的目标。 总结
相比G1、Shenandoah等先进的垃圾收集器ZGC在实现细节上做了一些不同的权衡选择。
譬如G1需要通过写屏障来维护记忆集才能处理跨代指针得以实现Region的增量回收。记忆集要占用大量的内存空间写屏障也对正常程序运行造成额外负担这些都是权衡选择的代价。
ZGC就完全没有使用记忆集它甚至连分代都没有连像CMS中那样只记录新生代和老年代间引用的卡表也不需要因而完全没有用到写屏障所以给用户线程带来的运行负担也要小得多。
可是有优就有劣ZGC的这种选择也限制了它能承受的对象分配速率不会太高。
因为ZGC四个阶段都支持并发如果分配速率高将创造大量的新对象这就产生了大量的浮动垃圾。如果这种高速分配持续维持的话回收到的内存空间持续小于期间并发产生的浮动垃圾所占的空间堆中剩余可腾挪的空间就越来越小了。
目前唯一的办法就是尽可能地增加堆容量大小获得更多喘息的时间。但是若要从根本上提升ZGC能够应对的对象分配速率还是需要引入分代收集让新生对象都在一个专门的区域中创建。所以分代算法有利有弊。
最后对本篇文章做一个提炼总结
ZGCZ Garbage Collector是一个面向并行、无停顿时间的垃圾回收器它作为JDK11的一部分首次引入并且在JDK15开始被正式视为生产就绪级别
出现意义面对现代硬件环境中大内存、多核心的趋势以及微服务等新型应用的需求如低延迟和高吞吐量传统的垃圾收集器如Parallel GC和CMS等可能无法满足要求尤其在处理多达数TB内存的情况下。在这样的背景下ZGC应运而生其设计目标是处理大型堆内存同时将停顿时间限制在10ms以内并且不牺牲整体吞吐量。主要特点其采用读屏障(Read Barrier)和染色指针(Colored Pointer)技术实现了可扩展性可以从几百MB到4TB的Java堆大小进行高效处理。此外ZGC能够实现几乎所有的工作都在并行和并发阶段完成包括对象可达性的标记、对象重定位和引用更新等操作。这使得它能够大幅度地降低垃圾收集带来的停顿时间。适用场景ZGC非常适合需要大内存低延时以及可预测的响应时间的系统例如金融交易、游戏、广告科技等领域的应用。局限性尽管ZGC有许多优点但也有一些局限性。例如由于其复杂的实现对JVM的代码入侵较深可能会与一些JVM特性或者优化手段不兼容。另外尽管ZGC的暂停时间很短但并发处理可能占用较多的CPU资源所以在CPU敏感的环境下其表现可能不如其他垃圾收集器。
总的来说ZGC是一种创新的垃圾收集器它解决了大内存和低延迟之间的矛盾为构建现代大规模、高性能的Java应用提供了更多可能。 通过美团分享的文章zgc也有适用和非使用的场景
在Zeus服务不同集群中ZGC在低延迟TP999 200ms场景中收益较大
TP999下降12~142ms下降幅度18%~74%。TP99下降5~28ms下降幅度10%~47%。
超低延迟TP999 20ms和高延迟TP999 200ms服务收益不大原因是这些服务的响应时间瓶颈不是GC而是外部依赖的性能对吞吐量优先的场景ZGC可能并不适合。例如Zeus某离线集群原先使用CMS升级ZGC后系统吞吐量明显降低。究其原因有二第一ZGC是单代垃圾回收器而CMS是分代垃圾回收器。单代垃圾回收器每次处理的对象更多更耗费CPU资源第二ZGC使用读屏障读屏障操作需耗费额外的计算资源。
所以可以参考自己的业务是否适合升级 参考
新一代垃圾回收器ZGC的探索与实践 - 美团技术团队 https://www.cnblogs.com/booksea/p/17665685.html
Java ZGC垃圾收集器(算法及回收原理详解) – mikechen
