旅游网站建设主要工作,自己网站的登录api怎么做,免费软件恢复微信聊天记录,权威网站优化价格上一篇#xff1a;07-垃圾收集算法详解 如果说收集算法是内存回收的方法论#xff0c;那么垃圾收集器就是内存回收的具体实现。 虽然我们对各个收集器进行比较#xff0c;但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现#xff0c;更加没…上一篇07-垃圾收集算法详解 如果说收集算法是内存回收的方法论那么垃圾收集器就是内存回收的具体实现。 虽然我们对各个收集器进行比较但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现更加没有万能的垃圾收集器我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。试想一下如果有一种四海之内、任何场景下都适用的完美收集器存在那么我们的Java虚拟机就不会实现那么多不同的垃圾收集器了。
1.Serial收集器
-XX:UseSerialGC -XX:UseSerialOldGC
Serial串行收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程 “Stop The World” 直到它收集结束。
新生代采用复制算法老年代采用标记-整理算法。
虚拟机的设计者们当然知道Stop The World带来的不良用户体验所以在后续的垃圾收集器设计中停顿时间在不断缩短仍然还有停顿寻找最优秀的垃圾收集器的过程仍然在继续。
但是Serial收集器有没有优于其他垃圾收集器的地方呢当然有它简单而高效与其他收集器的单线程相比。Serial收集器由于没有线程交互的开销自然可以获得很高的单线程收集效率。
Serial Old收集器是Serial收集器的老年代版本它同样是一个单线程收集器。它主要有两大用途一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用另一种用途是作为CMS收集器的后备方案。
2.Parallel Scavenge收集器
-XX:UseParallelGC(年轻代) -XX:UseParallelOldGC(老年代)
Parallel收集器其实就是Serial收集器的多线程版本除了使用多线程进行垃圾收集外其余行为控制参数、收集算法、回收策略等等和Serial收集器类似。默认的收集线程数跟cpu核数相同当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量高效率的利用CPU。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间提高用户体验。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量如果对于收集器运作不太了解的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法老年代采用标记-整理算法。
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。
3.ParNew收集器
-XX:UseParNewGC
ParNew收集器其实跟Parallel收集器很类似区别主要在于它可以和CMS收集器配合使用。 新生代采用复制算法老年代采用标记-整理算法。 它是许多运行在Server模式下的虚拟机的首要选择除了Serial收集器外只有它能与CMS收集器真正意义上的并发收集器后面会介绍到配合工作。
4.CMS收集器
-XX:UseConcMarkSweepGC(old)
CMSConcurrent Mark Sweep收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用它是HotSpot虚拟机第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程基本上同时工作。
从名字中的Mark Sweep这两个词可以看出CMS收集器是一种 “标记-清除”算法实现的它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤
初始标记 暂停所有的其他线程(STW)并记录下gc roots直接能引用的对象速度很快。并发标记 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程 这个过程耗时较长但是不需要停顿用户线程 可以与垃圾收集线程一起并发运行。因为用户程序继续运行可能会有导致已经标记过的对象状态发生改变。重新标记 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间一般会比初始标记阶段的时间稍长远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。并发清理 开启用户线程同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。并发重置重置本次GC过程中的标记数据。 从它的名字就可以看出它是一款优秀的垃圾收集器主要优点并发收集、低停顿。但是它有下面几个明显的缺点
对CPU资源敏感会和服务抢资源无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾这种浮动垃圾只能等到下一次gc再清理了)它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生当然通过参数-XX:UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理执行过程中的不确定性会存在上一次垃圾回收还没执行完然后垃圾回收又被触发的情况特别- 是在并发标记和并发清理阶段会出现一边回收系统一边运行也许没回收完就再次触发full gc也就是concurrent mode failure此时会进入stop the world用serial old垃圾收集器来回收
CMS的相关核心参数
-XX:UseConcMarkSweepGC启用cms-XX:ConcGCThreads并发的GC线程数-XX:UseCMSCompactAtFullCollectionFullGC之后做压缩整理减少碎片-XX:CMSFullGCsBeforeCompaction多少次FullGC之后压缩一次默认是0代表每次FullGC后都会压缩一次-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC默认是92这是百分比-XX:UseCMSInitiatingOccupancyOnly只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)如果不指定JVM仅在第一次使用设定值后续则会自动调整-XX:CMSScavengeBeforeRemark在CMS GC前启动一次minor gc降低CMS GC标记阶段(也会对年轻代一起做标记如果在minor gc就干掉了很多对垃圾对象标记阶段就会减少一些标记时间)时的开销一般CMS的GC耗时 80%都在标记阶段-XX:CMSParallellnitialMarkEnabled表示在初始标记的时候多线程执行缩短STW-XX:CMSParallelRemarkEnabled在重新标记的时候多线程执行缩短STW;
5.G1收集器
-XX:UseG1GC
G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征. G1将Java堆划分为多个大小相等的独立区域RegionJVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)实际可以超过该值但是不推荐。
一般Region大小等于堆大小除以2048比如堆大小为4096M则Region大小为2M当然也可以用参数-XX:G1HeapRegionSize手动指定Region大小但是推荐默认的计算方式。
G1保留了年轻代和老年代的概念但不再是物理隔阂了它们都是可以不连续Region的集合。
默认年轻代对堆内存的占比是5%如果堆大小为4096M那么年轻代占据200MB左右的内存对应大概是100个Region可以通过“-XX:G1NewSizePercent”设置新生代初始占比在系统运行中JVM会不停的给年轻代增加更多的Region但是最多新生代的占比不会超过60%可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样默认8:1:1假设年轻代现在有1000个regioneden区对应800个s0对应100个s1对应100个。
一个Region可能之前是年轻代如果Region进行了垃圾回收之后可能又会变成老年代也就是说Region的区域功能可能会动态变化。
G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样唯一不同的是对大对象的处理G1有专门分配大对象的Region叫Humongous区而不是让大对象直接进入老年代的Region中。在G1中大对象的判定规则就是一个大对象超过了一个Region大小的50%比如按照上面算的每个Region是2M只要一个大对象超过了1M就会被放入Humongous中而且一个大对象如果太大可能会横跨多个Region来存放。
Humongous区专门存放短期巨型对象不用直接进老年代可以节约老年代的空间避免因为老年代空间不够的GC开销。
Full GC的时候除了收集年轻代和老年代之外也会将Humongous区一并回收。
G1收集器一次GC(主要值Mixed GC)的运作过程大致分为以下几个步骤
初始标记initial markSTW暂停所有的其他线程并记录下gc roots直接能引用的对象速度很快 并发标记Concurrent Marking同CMS的并发标记最终标记RemarkSTW同CMS的重新标记筛选回收CleanupSTW筛选回收阶段首先对各个Region的回收价值和成本进行排序根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划比如说老年代此时有1000个Region都满了但是因为根据预期停顿时间本次垃圾回收可能只能停顿200毫秒那么通过之前回收成本计算得知可能回收其中800个Region刚好需要200ms那么就只会回收800个Region(Collection Set要回收的集合)尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行但是因为只回收一部分Region时间是用户可控制的而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代回收算法主要用的是复制算法将一个region中的存活对象复制到另一个region中这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次G1采用复制算法回收几乎不会有太多内存碎片。(注意CMS回收阶段是跟用户线程一起并发执行的G1因为内部实现太复杂暂时没实现并发回收不过到了ZGCShenandoah就实现了并发收集Shenandoah可以看成是G1的升级版本) G1收集器在后台维护了一个优先列表每次根据允许的收集时间优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)比如一个Region花200ms能回收10M垃圾另外一个Region花50ms能回收20M垃圾在回收时间有限情况下G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式保证了G1收集器在有限时间内可以尽可能高的收集效率。
被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点
并行与并发G1能充分利用CPU、多核环境下的硬件优势使用多个CPUCPU或者CPU核心来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作G1收集器仍然可以通过并发的方式让java程序继续执行。分代收集虽然G1可以不需要其他收集器配合就能独立管理整个GC堆但是还是保留了分代的概念。空间整合与CMS的“标记–清理”算法不同G1从整体来看是基于“标记整理”算法实现的收集器从局部上来看是基于“复制”算法实现的。可预测的停顿这是G1相对于CMS的另一个大优势降低停顿时间是G1 和 CMS 共同的关注点但G1 除了追求低停顿外还能建立可预测的停顿时间模型能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数-XX:MaxGCPauseMillis指定)内完成垃圾收集。
毫无疑问 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能 设置不同的期望停顿时间 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过 这里设置的“期望值”必须是符合实际的 不能异想天开 毕竟G1是要冻结用户线程来复制对象的 这个停顿时 间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒 一般来说 回收阶段占到几十到一百甚至接近两百毫秒都很正常 但如果我们把停顿时间调得非常低 譬如设置为二十毫秒 很可能出现的结果就是由于停顿目标时间太短 导致每次选出来的回收集只占堆内存很小的一部分 收集器收集的速度逐渐跟不上分配器分配的速度 导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间 但应用运行时间一长就不行了 最终占满堆引发Full GC反而降低性能 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。
G1垃圾收集分类
YoungGC YoungGC并不是说现有的Eden区放满了就会马上触发G1会计算下现在Eden区回收大概要多久时间如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值那么增加年轻代的region继续给新对象存放不会马上做Young GC直到下一次Eden区放满G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值那么就会触发Young GC
MixedGC 不是FullGC老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区正常情况G1的垃圾收集是先做MixedGC主要使用复制算法需要把各个region中存活的对象拷贝到别的region里去拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC
Full GC 停止系统程序然后采用单线程进行标记、清理和压缩整理好空闲出来一批Region来供下一次MixedGC使用这个过程是非常耗时的。(Shenandoah优化成多线程收集了)
G1收集器参数设置
-XX:UseG1GC:使用G1收集器-XX:ParallelGCThreads:指定GC工作的线程数量-XX:G1HeapRegionSize:指定分区大小(1MB~32MB且必须是2的N次幂)默认将整堆划分为2048个分区-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%值配置整数默认就是百分比)-XX:G1MaxNewSizePercent:新生代内存最大空间-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)Survivor区域里的一批对象(年龄1年龄2年龄n的多个年龄对象)总和超过了Survivor区域的50%此时就会把年龄n(含)以上的对象都放入老年代-XX:MaxTenuringThreshold:最大年龄阈值(默认15)-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)则执行新生代和老年代的混合收集(MixedGC)比如我们之前说的堆默认有2048个region如果有接近1000个region都是老年代的region则可能就要触发MixedGC了-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region如果超过这个值存活对象过多回收的的意义不大。-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)在最后一个筛选回收阶段可以回收一会然后暂停回收恢复系统运行一会再开始回收这样可以让系统不至于单次停顿时间过长。-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值在混合回收的时候对Region回收都是基于复制算法进行的都是把要回收的Region里的存活对象放入其他Region然后这个Region中的垃圾对象全部清理掉这样的话在回收过程就会不断空出来新的Region一旦空闲出来的Region数量达到了堆内存的5%此时就会立即停止混合回收意味着本次混合回收就结束了。
G1垃圾收集器优化建议
假设参数 -XX:MaxGCPauseMills 设置的值很大导致系统运行很久才会做年轻代gc年轻代可能都占用了堆内存的60%了此时才触发年轻代gc。那么存活下来的对象可能就会很多此时就会导致Survivor区域放不下那么多的对象就会进入老年代中。
或者是你年轻代gc过后存活下来的对象过多导致进入Survivor区域后触发了动态年龄判定规则达到了Survivor区域的50%也会快速导致一些对象进入老年代中。 所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值在保证他的年轻代gc别太频繁的同时还得考虑每次gc过后的存活对象有多少避免存活对象太多快速进入老年代频繁触发mixed gc.
什么场景适合使用G1
50%以上的堆被存活对象占用对象分配和晋升的速度变化非常大垃圾回收时间特别长超过1秒8GB以上的堆内存(建议值)停顿时间是500ms以内
每秒几十万并发的系统如何优化JVM
Kafka类似的支撑高并发消息系统大家肯定不陌生对于kafka来说每秒处理几万甚至几十万消息时很正常的一般来说部署kafka需要用大内存机器(比如64G)也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理这里就涉及到一个问题了我们以前常说的对于eden区的young gc是很快的这种情况下它的执行还会很快吗很显然不可能因为内存太大处理还是要花不少时间的假设三四十G内存回收可能最快也要几秒钟按kafka这个并发量放满三四十G的eden区可能也就一两分钟吧那么意味着整个系统每运行一两分钟就会因为young gc卡顿几秒钟没法处理新消息显然是不行的。那么对于这种情况如何优化了我们可以使用G1收集器设置 -XX:MaxGCPauseMills 为50ms假设50ms能够回收三到四个G内存然后50ms的卡顿其实完全能够接受用户几乎无感知那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。
G1天生就适合这种大内存机器的JVM运行可以比较完美的解决大内存垃圾回收时间过长的问题。
6.ZGC收集器
-XX:UseZGC ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器ZGC可以说源自于是Azul System公司开发的C4Concurrent Continuously Compacting Collector 收集器。
ZGC目标 如下图所示ZGC的目标主要有4个 支持TB量级的堆。我们生产环境的硬盘还没有上TB呢这应该可以满足未来十年内所有JAVA应用的需求了吧。支最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右Major GC一般都需要100ms以上G1可以调节停顿时间但是如果调的过低的话反而会适得其反之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关而Root数量和堆大小是没有任何关系的。支奠定未来GC特性的基础。支最糟糕的情况下吞吐量会降低15%。这都不是事停顿时间足够优秀。至于吞吐量通过扩容分分钟解决。
另外Oracle官方提到了它最大的优点是它的停顿时间不会随着堆的增大而增长也就是说几十G堆的停顿时间是10ms以下几百G甚至上T堆的停顿时间也是10ms以下。
不分代(暂时) 单代即ZGC「没有分代」。我们知道以前的垃圾回收器之所以分代是因为源于“「大部分对象朝生夕死」”的假设事实上大部分系统的对象分配行为也确实符合这个假设。
那么为什么ZGC就不分代呢因为分代实现起来麻烦作者就先实现出一个比较简单可用的单代版本后续会优化。
ZGC内存布局
ZGC收集器是一款基于Region内存布局的 暂时不设分代的 使用了读屏障、 颜色指针等技术来实现可并发的标记-整理算法的 以低延迟为首要目标的一款垃圾收集器。
ZGC的Region可以具有如图3-19所示的大、 中、 小三类容量
小型RegionSmall Region 容量固定为2MB 用于放置小于256KB的小对象。中型RegionMedium Region 容量固定为32MB 用于放置大于等于256KB但小于4MB的对象。大型RegionLarge Region 容量不固定 可以动态变化 但必须为2MB的整数倍 用于放置4MB或以上的大对象。 每个大型Region中只会存放一个大对象 这也预示着虽然名字叫作“大型Region” 但它的实际容量完全有可能小于中型Region 最小容量可低至4MB。 大型Region在ZGC的实现中是不会被重分配重分配是ZGC的一种处理动作 用于复制对象的收集器阶段 稍后会介绍到的 因为复制一个大对象的代价非常高昂。
NUMA-aware NUMA对应的有UMAUMA即Uniform Memory Access ArchitectureNUMA就是Non Uniform Memory Access Architecture。UMA表示内存只有一块所有CPU都去访问这一块内存那么就会存在竞争问题争夺内存总线访问权有竞争就会有锁有锁效率就会受到影响而且CPU核心数越多竞争就越激烈。NUMA的话每个CPU对应有一块内存且这块内存在主板上离这个CPU是最近的每个CPU优先访问这块内存那效率自然就提高了
服务器的NUMA架构在中大型系统上一直非常盛行也是高性能的解决方案尤其在系统延迟方面表现都很优秀。ZGC是能自动感知NUMA架构并充分利用NUMA架构特性的。
ZGC运作过程
ZGC的运作过程大致可划分为以下四个大的阶段
并发标记Concurrent Mark与G1一样并发标记是遍历对象图做可达性分析的阶段它的初始标记(Mark Start)和最终标记(Mark End)也会出现短暂的停顿与G1不同的是 ZGC的标记是在指针上而不是在对象上进行的 标记阶段会更新颜色指针(见下面详解)中的Marked 0、 Marked 1标志位。并发预备重分配Concurrent Prepare for Relocate这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region将这些Region组成重分配集Relocation Set。ZGC每次回收都会扫描所有的Region用范围更大的扫描成本换取省去G1中记忆集的维护成本。并发重分配Concurrent Relocate重分配是ZGC执行过程中的核心阶段这个过程要把重分配集中的存活对象复制到新的Region上并为重分配集中的每个Region维护一个转发表Forward Table记录从旧对象到新对象的转向关系。ZGC收集器能仅从引用上就明确得知一个对象是否处于重分配集之中如果用户线程此时并发访问了位于重分配集中的对象这次访问将会被预置的内存屏障(读屏障(见下面详解))所截获然后立即根据Region上的转发表记录将访问转发到新复制的对象上并同时修正更新该引用的值使其直接指向新对象ZGC将这种行为称为指针的“自愈”Self-Healing能力。 ZGC的颜色指针因为“自愈”Self-Healing能力所以只有第一次访问旧对象会变慢 一旦重分配集中某个Region的存活对象都复制完毕后这个Region就可以立即释放用于新对象的分配但是转发表还得留着不能释放掉 因为可能还有访问在使用这个转发表。 并发重映射Concurrent Remap重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用但是ZGC中对象引用存在“自愈”功能所以这个重映射操作并不是很迫切。ZGC很巧妙地把并发重映射阶段要做的工作合并到了下一次垃圾收集循环中的并发标记阶段里去完成反正它们都是要遍历所有对象的这样合并就节省了一次遍历对象图的开销。一旦所有指针都被修正之后 原来记录新旧对象关系的转发表就可以释放掉了。
颜色指针
Colored Pointers即颜色指针如下图所示ZGC的核心设计之一。以前的垃圾回收器的GC信息都保存在对象头中而ZGC的GC信息保存在指针中。
每个对象有一个64位指针这64位被分为
18位预留给以后使用1位Finalizable标识此位与并发引用处理有关它表示这个对象只能通过finalizer才能访问1位Remapped标识设置此位的值后对象未指向relocation set中relocation set表示需要GC的Region集合1位Marked1标识1位Marked0标识和上面的Marked1都是标记对象用于辅助GC42位对象的地址所以它可以支持2^424T内存
为什么有2个mark标记 每一个GC周期开始时会交换使用的标记位使上次GC周期中修正的已标记状态失效所有引用都变成未标记。 GC周期1使用mark0, 则周期结束所有引用mark标记都会成为01。 GC周期2使用mark1, 则期待的mark标记10所有引用都能被重新标记。 通过对配置ZGC后对象指针分析我们可知对象指针必须是64位那么ZGC就无法支持32位操作系统同样的也就无法支持压缩指针了CompressedOops压缩指针也是32位。 颜色指针的三大优势 一旦某个Region的存活对象被移走之后这个Region立即就能够被释放和重用掉而不必等待整个堆中所有指向该Region的引用都被修正后才能清理这使得理论上只要还有一个空闲RegionZGC就能完成收集。 颜色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量ZGC只使用了读屏障。 颜色指针具备强大的扩展性它可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据以便日后进一步提高性能。
读屏障
之前的GC都是采用Write Barrier这次ZGC采用了完全不同的方案读屏障这个是ZGC一个非常重要的特性。
在标记和移动对象的阶段每次「从堆里对象的引用类型中读取一个指针」的时候都需要加上一个Load Barriers。
那么我们该如何理解它呢看下面的代码第一行代码我们尝试读取堆中的一个对象引用obj.fieldA并赋给引用ofieldA也是一个对象时才会加上读屏障。如果这时候对象在GC时被移动了接下来JVM就会加上一个读屏障这个屏障会把读出的指针更新到对象的新地址上并且把堆里的这个指针“修正”到原本的字段里。这样就算GC把对象移动了读屏障也会发现并修正指针于是应用代码就永远都会持有更新后的有效指针而且不需要STW。
那么JVM是如何判断对象被移动过呢就是利用上面提到的颜色指针如果指针是Bad Color那么程序还不能往下执行需要「slow path」修正指针如果指针是Good Color那么正常往下执行即可
❝ 这个动作是不是非常像JDK并发中用到的CAS自旋读取的值发现已经失效了需要重新读取。而ZGC这里是之前持有的指针由于GC后失效了需要通过读屏障修正指针。❞ 后面3行代码都不需要加读屏障Object p o这行代码并没有从堆中读取数据o.doSomething()也没有从堆中读取数据obj.fieldB不是对象引用而是原子类型。 正是因为Load Barriers的存在所以会导致配置ZGC的应用的吞吐量会变低。官方的测试数据是需要多出额外4%的开销 那么判断对象是Bad Color还是Good Color的依据是什么呢就是根据上一段提到的Colored Pointers的4个颜色位。当加上读屏障时根据对象指针中这4位的信息就能知道当前对象是Bad/Good Color了。 PS既然低42位指针可以支持4T内存那么能否通过预约更多位给对象地址来达到支持更大内存的目的呢答案肯定是不可以。因为目前主板地址总线最宽只有48bit4位是颜色位就只剩44位了所以受限于目前的硬件ZGC最大只能支持16T的内存JDK13就把最大支持堆内存从4T扩大到了16T。
ZGC存在的问题
ZGC最大的问题是浮动垃圾。ZGC的停顿时间是在10ms以下但是ZGC的执行时间还是远远大于这个时间的。假如ZGC全过程需要执行10分钟在这个期间由于对象分配速率很高将创建大量的新对象这些对象很难进入当次GC所以只能在下次GC的时候进行回收这些只能等到下次GC才能回收的对象就是浮动垃圾。 ZGC没有分代概念每次都需要进行全堆扫描导致一些“朝生夕死”的对象没能及时的被回收。 解决方案 目前唯一的办法是增大堆的容量使得程序得到更多的喘息时间但是这个也是一个治标不治本的方案。如果需要从根本上解决这个问题还是需要引入分代收集让新生对象都在一个专门的区域中创建然后专门针对这个区域进行更频繁、更快的收集。
ZGC参数设置 启用ZGC比较简单设置JVM参数即可-XX:UnlockExperimentalVMOptions 「-XX:UseZGC」。调优也并不难因为ZGC调优参数并不多远不像CMS那么复杂。它和G1一样可以调优的参数都比较少大部分工作JVM能很好的自动完成。下图所示是ZGC可以调优的参数
ZGC触发时机
ZGC目前有4中机制触发GC
定时触发默认为不使用可通过ZCollectionInterval参数配置。预热触发最多三次在堆内存达到10%、20%、30%时触发主要时统计GC时间为其他GC机制使用。分配速率基于正态分布统计计算内存99.9%可能的最大分配速率以及此速率下内存将要耗尽的时间点在耗尽之前触发GC耗尽时间 - 一次GC最大持续时间 - 一次GC检测周期时间。主动触发默认开启可通过ZProactive参数配置 距上次GC堆内存增长10%或超过5分钟时对比距上次GC的间隔时间跟49 * 一次GC的最大持续时间超过则触发。
如何选择垃圾收集器
优先调整堆的大小让服务器自己来选择如果内存小于100M使用串行收集器如果是单核并且没有停顿时间的要求串行或JVM自己选择如果允许停顿时间超过1秒选择并行或者JVM自己选如果响应时间最重要并且不能超过1秒使用并发收集器4G以下可以用parallel4-8G可以用ParNewCMS8G以上可以用G1几百G以上用ZGC 下图有连线的可以搭配使用 JDK 1.8默认使用 Parallel(年轻代和老年代都是) JDK 1.9默认使用 G1
安全点与安全区域
安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样JVM就可以安全的进行一些操作,比如GC等所以GC不是想什么时候做就立即触发的是需要等待所有线程运行到安全点后才能触发。
这些特定的安全点位置主要有以下几种:
方法返回之前调用某个方法之后抛出异常的位置循环的末尾
大体实现思想是当垃圾收集需要中断线程的时候 不直接对线程操作 仅仅简单地设置一个标志位 各个线程执行过程时会不停地主动去轮询这个标志 一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。 轮询标志的地方和安全点是重合的。
安全区域又是什么 Safe Point 是对正在执行的线程设定的。 如果一个线程处于 Sleep 或中断状态它就不能响应 JVM 的中断请求再运行到 Safe Point 上。 因此 JVM 引入了 Safe Region。 Safe Region 是指在一段代码片段中引用关系不会发生变化。在这个区域内的任意地方开始 GC 都是安全的。
下一篇09-JVM垃圾收集底层算法实现
