文章目录

  • 垃圾回收器概述
  • 评估GC的性能指标
  • 吞吐量(throughput)
  • 暂停时间(pause time)
  • 七种经典的垃圾回收器
    • 垃圾收集器组合关系
    • Serial回收器 串行回收
    • ParNew回收器 并行回收
    • Parallel Scavenge回收器 吞吐量优先
    • CMS回收器 低延迟
    • G1收集器 区域化分代式

垃圾回收器概述

  • 垃圾收集器没有在任何规范中进行过多的规定,可以由不同的厂商,不同版本的JVM来实现
  • 由于jdk的版本处于高速迭代过程中,因此java发展至今已经衍生了众多的GC版本
  • 垃圾回收器分类
    • 按线程数分,可分为串行垃圾回收器和并行垃圾回收器
    • 按工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器
    • 按碎片处理方式分,可分为压缩式垃圾回收器和非压缩式垃圾回收器
    • 按工作的内存空间分,可分为年起代垃圾收集器和老年代垃圾收集器

评估GC的性能指标

  • 吞吐量: 运行用户代码的时间占总时间的比例 (总运行时间: 程序运行时间+内存回收时间)

  • 垃圾收集开销: 吞吐量的补数,垃圾收集器所用时间与总时间的比例

  • 暂停时间: 执行垃圾收集时,程序的工作线程被暂停的时间

  • 收集频率: 相对于应用程序的执行,收集操作发生的频率

  • 内存占用: Java堆区所占的内存大小

  • 快速: 一个对象从诞生到被回收所经历的时间

这三者共同构成一个"不可能三角",三者总体的表现随着技术的进步越来越好,一款优秀的收集器通常最多同时满足其中两项

现在标准: 在最大吞吐量优先的情况下,降低暂停时间

吞吐量(throughput)

  • 吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

  • 高吞吐量的情况下,应用程序能容忍较高的暂停时间,因此高吞吐量的应用程序由更长的时间基准,快速响应是不必考虑的

暂停时间(pause time)

  • 暂停时间是指一个时间段内应用程序线程暂停,让GC线程执行的状态

七种经典的垃圾回收器

  • 串行回收器: Serial,Serial Old
  • 并行回收器: ParNew,Parallel Scavenge,Parallel Old
  • 并发回收器: CMS,G1
  • 新生代收集器: Serial,ParNew,Parallel Scavenge
  • 老年代收集器: Serial Old,Paralled Old,CMS
  • 整堆收集器: G1
垃圾收集器组合关系

  • 其中Serial Old作为CMS出现"Concurrent Mode Failure"失败的后备预案
  • (红色虚线)在jdk8时将这两个组合声明为废弃,并在jdk9中完全取消
  • (绿色虚线)在jdk14中废弃
  • (绿色虚线)jdk14中,删除CMS垃圾收集器
Serial回收器 串行回收
  • Serial收集器是最基本,历史最悠久的垃圾收集器,jdk1.3之前回收新生代唯一的选择
  • Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器
  • Serial收集器采用复制算法,串行回收"Stop the World"机制的方式执行垃圾回收
  • 除了年起代之外,Serial收集器还提供了用于执行老年代垃圾收集的Serial Old收集器,Serial Old收集器同样也采用了串行回收"Stop the World"机制,只不过内存回收算法使用的是标记-压缩算法
    • Serial Old是运行在Client模式下默认的老年代垃圾回收器
    • Serial Old在Server模式下主要有两个用途: 1.与新生代的Parallel Scavenge配合使用,2.作为老年代CMS收集器的后背垃圾收集器方案
  • 这个收集器是一个单线程的收集器,但它的"单线程"的意义并不仅仅说明它只会使用一个CPU或一条收集线程区完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有所有的工作线程,直到它收集结束
  • 优势: 简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销,专心做垃圾收集,自然可以获得最高的单线程收集效率
  • 在HotSpot虚拟机中,使用-XX:+UserSerialGC参数可以指定年轻代和老年代都使用串行收集器,等价于新生代用Serial GC,老年代用Serial Old GC
ParNew回收器 并行回收

  • 如果说Serial GC是年轻代中的单线程垃圾收集器,那么ParNew收集器则是Serial收集器的多线程版本

  • ParNew收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别,ParNew收集器在年轻代中同样也是采用复制算法,"Stop the World"机制

  • ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器

  • 对于新生代,回收次数频繁,使用并行方式高效,对于老年代,回收次数少,使用串行方式节省资源(CPU并行需要切换线程,串行可以省去切换线程的资源)

  • 由于ParNew收集器是基于并行回收,那么是否可以判定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效?

    • ParNew收集器运行在多CPU的环境下,由于可以充分利用多CPU,多核心等物理硬件资源优势,可以更快地完成垃圾收集,提升程序的吞吐量
    • 但是在单个CPU的环境下,ParNew收集器,不比Serial收集器更高效,虽然Serial收集器是基于串行回收,但是由于CPU不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销

  • 除Serial外,目前只有ParNew GC能与CMS收集器配合工作

  • 通过"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务,它表示年轻代使用并行收集器,不影响老年代

  • 通过"-XX:ParallelGCThreads"限制线程数量,默认开启和CPU数据相同的线程数

Parallel Scavenge回收器 吞吐量优先
  • HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外,Parallel Scavenge收集器同样也采用了复制算法,并行回收和"Stop the World"机制
  • 和ParNew收集器不同,Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器
  • 自适应调节策略也是Parallel Scavenge与ParNew一个重要区别
  • 高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务,因此,常见在服务器环境中使用,例如那些执行批量处理,订单处理,工资支付,科学计算的应用程序
  • Parallel收集器在jdk1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器,用来代替老年代的Serial Old收集器
  • Parallel Old收集器采用了标记-压缩算法,同样也是基于并行回收和"Stop the World"机制
  • "-XX:+UseParallelGC"手动指定年轻代使用Parallel并行收集器执行内存回收任务
  • "-XX:+UseParallelOldGC"手动指定老年代使用并行回收收集器
  • 上面两个参数分别适用于新生代和老年代,jdk8默认是开启的.上面两个参数,默认开启一个,另一个也会被开启(互相激活)
  • "-XX:ParallelGCThreads"设置年轻代并行收集器的线程数,最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能,在默认情况下,CPU数量小于8,ParallelGCThreads的值等于CPU数量,当CPU数量大于8,ParallelGCThreads的值等于3+(5*CPU_COUNT/8)
  • "-XX:MaxGCPauseMillis"设置垃圾收集器最大停顿时间(即STW的时间)单位是毫秒(该参数使用需谨慎)
    • 为了尽可能地把停顿时间控制在MaxGCPauseMillis以内,收集器在工作时会调整Java堆大小或者其他一些参数
    • 对于用户来讲,停顿时间越短体验越好,但是在服务器端,我们注重高并发,整体的吞吐量,所以服务器端适合Parallel,进行控制
  • "-XX:GCTimeRatio"垃圾收集时间占总时间的比例(=1/(N+1)),用于衡量吞吐量的大小
    • 取值范围(0,100),默认99,也就是垃圾回收时间不超过1%
    • 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性,暂停时间越长,Radio参数就越容易超过设定的比例
  • "-XX:+UseAdaptiveSizePolicy"设置Parallel Scavenge收集器具有自适应调节策略
    • 在这种模式下,年轻代的大小,Eden和Survivor的比例,晋升老年代的对象年龄等参数会被自动调整,已到达在堆大小,吞吐量和停顿时间之间的平衡点
    • 在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆,目标的吞吐量和停顿时间,让虚拟机自己完成调优工作
CMS回收器 低延迟

  • 在jdk1.5时期,HotSpot退出了一款在强交互应用中几乎认为有划时代意义的垃圾收集器,CMS(Concurrent-Mark-Sweep)收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集器线程与用户线程同时工作

  • CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间,停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验.目前很大一部分的Java应用集中在web网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验,CMS收集器就非常符合这类应用的需求

  • CMS的垃圾收集算法采用标记-清除算法,并且也会"Stop the World "

  • CMS作为老年代的收集器,却无法与jdk1.4中已经存在的新生代收集器Parallel Scavenge配合工作,所以在jdk1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个

  • 在G1出现之前,CMS使用还是非常广泛的,一直到今天,仍然有很多系统使用CMS GC

  • CMS整个过程比之前的收集器都要复杂,整个过程分为4个阶段,即初始标记阶段,并发标记阶段,重新标记阶段和并发清除阶段

    • 初始标记阶段(Initial-Mark): 在这个阶段中,程序中所有的工作线程都将会因为"Stop the World"机制而出现短暂的暂停,这个阶段主要任务仅仅只是标记出GC Roots能直接关联到的对象,一旦标记完成之后就会恢复之前被暂停的所有应用线程,由于直接关联对象比较少,所以这里速度非常快
    • 并发标记阶段(Concurrent-Mark): 从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长,但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行
    • 重新标记阶段(Remark): 由于在并发标记阶段中,程序工作线程会和垃圾收集线程同时运行或交叉运行,因此为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短
    • 并发清除阶段(Concurrent-Sweep): 此阶段清理删除掉标记阶段判定的已经死亡的对象,释放内存空间,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的

  • 由于最耗费时间的并发标记与并发清除阶段都是不需要暂停用户线程的,所以整体的回收是低停顿的

  • 尽管CMS收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行"Stop the world"机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要"Stop the World",只是尽可能地缩短暂停时间

  • 另外,由于在垃圾收集阶段用户线程没有中断,所以在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用,因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行.要是CMS运行期间预留的内存无法满足程序需要,就会出现一次"Concurrent Mode Failure"失败,这时虚拟机将启动后备预案: 临时启动Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了

  • CMS收集器的垃圾收集算法采用的是标记-清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象占用的内存空间极有可能是不连续的内存块,不可避免地将会产生一些内存碎片,那么CMS在为新对象分配内存空间时,将无法使用指针碰撞技术,而只能够选择空闲列表执行内存分配

  • CMS的优点:并发收集,低延迟

  • CMS的弊端

    • 会产生内存碎片,导致并发清除后,用户线程可用的空间不足,在无法分配大对象的情况下,不得不提前触发Full GC
    • CMS收集器对CPU资源非常敏感,在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量降低
    • CMS收集器无法处理浮动垃圾,可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生,在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或交叉运行的,那么在并发阶段如果产生新的垃圾对象,CMS将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行GC时释放这些之前未被回收的内存空间

  • “-XX:+UseConcMarkSweepGC” 手动指定使用CMS收集器执行内存回任务,开启该参数后会自动将-XX:+UseParNewGC打开,即ParNew(Young区)+CMS(Old区)+Serial Old组合

  • “-XX:CMSlnitiatingOccupanyFraction” 设置堆内存使用率的阈值,一旦达到该阈值,便开始回收

    • jdk5及以前版本的默认值为68,即当老年代的空间使用率达到68%时,会执行一次CMS回收,jdk6及以后版本默认值为92%
    • 如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低CMS的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能,反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器,因此通过该选项便可以有效降低Full GC的执行次数

  • “-XX:+UseCMSCompactAtFullCollection” 用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生,不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了

  • “-XX:CMSFullGCsBeforeCompaction” 设置在执行多少次Full GC后对内存空间进行压缩整理

  • “-XX:ParallelCMSThreads” 设置CMS的线程数量

    • CMS默认启动的线程数是(ParallelGCThreads+3)/4,ParallelGCThreads是年起代并行收集器的线程数,当CPU资源比较紧张时,收到CMS收集器线程数的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕
G1收集器 区域化分代式

  • 应用程序所应对的业务越来越庞大,复杂,用户越来越多,没有GC就不能保证应用程序正常运行,而经常造成STW的GC又跟不上实际的需求,所以才会不断地尝试对GC进行优化,G1(Garbage-First)收集回收器是在java7 update 4之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一

  • 与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量

  • 官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起"全功能收集器"的重任与期望

  • G1是一个并行回收器,它把堆内存分割为很多不相关的区域(Region)(物理上不连续),使用不同的Region来表示Eden,幸存者0区,幸存者1区,老年代等

  • G1 GC有计划地避免在整个java堆中进行全区域的垃圾收集.G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region

  • 由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给G1一个名字,垃圾优先(Garbage First)

  • G1是一款面向服务端应用的垃圾收集器,主要针对备份多核CPU及大容量内存的机器,以极高的概率满足GC停顿时间的同时,还兼具高吞吐量的性能特性

  • 在jdk1.7版本正式启用,移除了Experimental的标识,是jdk9以后的默认垃圾收集器,取代CMS以及Parallel+Parallel Old组合.被Oracle官方称为"全功能的垃圾收集器"

  • 与此同时,CMS已经在jdk9中被标记为废弃(deprecated),G1在jdk8中还不是默认的垃圾收集器,需要使用-XX:+UseG1GC

  • 并行与并发

    • 并行性: G1在回收期间,可以有多个GC线程同时工作,有效利用多核计算机能力,此时用户线程STW
    • 并发性: G1拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况

  • 分代收集

    • 从分代上看,G1依然属于分代型垃圾收集器,它会区分年起代和老年代,年轻代依然又Eden区和Survivor区,但从堆的结构上看,它不要求整个Eden区,年轻代或者老年代都是连续的,也不再坚持固定大小和固定数量
    • 将堆空间分为若干区域(Region),这些区域中包含逻辑上的年轻代和老年代
    • 和之前的各类收集器不同,它同时兼顾年轻代和老年代

  • 空间整合

    • CMS: "标记-清除"算法,内存碎片,若干次GC后进行一次碎片清理
    • G1将内存划分为一个个的Region,内存的回收是以Region作为基本单位的,Region之间是复制算法,但整体上实际可看作是标记-压缩算法,两种算法都可以避免内存碎片,这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC,尤其是当java堆非常大的时候,G1的优势更加明显

  • 可预测的停顿时间模型(软实时soft real-time)

    • 这是G1相对于CMS的另一个优势,G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒
    • 由于分区的原因,G1可以只选取部分区域进行内存回收,这样缩小了范围,因此对于全局停顿情况的发生也能得到较好的控制
    • G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region,保证了G1收集器在有限的时间内可以获取尽可能高的收集效率
    • 相比于CMS,G1未必能做到CMS在最好情况下的延时停顿,但是最差情况要好很多

  • G1回收器的缺点

    • 相对于CMS,G1还不具备全方位,压倒性优势,比如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比CMS要高
    • 从经验上来说,在小内存应用上CMS的表现大概率会优于G1,而G1在大内存应用上则发挥其优势,平衡点在6-8GB之间

  • 参数设置

    • -XX:+UseG1GC 手动指定使用G1收集器执行内存回收任务
    • -XX:G1HeapRegionSize 设置每个Region的大小,值是2的幂,范围是1MB到32MB之间,目标是根据最小的Java堆大小划分出约2048个区域,默认是堆内存的1/2000
    • -XX:MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标(JVM会尽力实现,但不保证达到),默认值是200ms
    • -XX:ParallelGCThread 设置STW时GC线程数的值,最多设置为8
    • -XX:ConcGCThreads 设置并发标记的线程数,将n设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右
    • -XX:InitiatingHeapOccupancyPercent 设置触发并发GC周期的Java堆占用率阈值,超过此值,就触发GC,默认值是45

  • G1回收器的常见操作步骤

    • G1的设计原则就是简化JVM性能调优,开发人员只需要简单的三步即可完成调优

      • 第一步: 开启G1垃圾收集器
      • 第二步: 设置堆的最大内存
      • 第三步: 设置最大的停顿时间
    • G1中提供了三种垃圾回收模式,YoungGC,Mixed GC和Full GC在不同的条件下被触发

  • G2收集器的适用场景

    • 面向服务端应用,针对具有大内存,多处理器的机器(在普通大小的堆里表现并不惊喜)
    • 最主要的应用是需要低GC延迟,并具有大堆的应用程序提供解决方案
    • 如: 在堆大小约6GB或更大时,可预测的暂停时间可以低于0.5秒(G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长)
    • 用来替换掉jdk1.5中的CMS收集器,在下面的情况时,使用G1可能比CMS好
      • 超过50%的Java堆被活动数据占用
      • 对象分配频率或年代提升频率变化很大
      • GC停顿时间过长(长至0.5至1秒)
    • HotSpot垃圾收集器里,除了G1以外,其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作,而G1 GC可以采用应用线程承担后台运行的GC工作,即当JVM的GC线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程

  • 分区Region 化整为零

    • 使用G1收集器时,它将整个Java堆划分成为约2048个大小相同的独立Region块,每个Region块大小根据堆空间的实际大小而定,整体被控制在1MB到32MB之间,且为2的n次幂,由-XX:G1HeapRegionSize设定,所有的Region大小相同,且在JVM生命周期内不会被改变
    • 虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分Region(不需要连续)的集合,通过Region的动态分配方式实现逻辑上的连续
    • 一个region有可能属于Eden,Survivor或者old内存区域,但是一个region只可能属于一个角色
    • G1垃圾收集器还增加了一种新的内存区域,Humongous内存区域,主要用于存储大对象,如果超过1.5个region,就放到H
    • 对于堆中的大对象,默认直接会被分配到老年代,但是如果它是一个短期存在的大对象,就会对垃圾收集器造成负面影响,为了解决这个问题,G1划分了一个Humongous区,它用来专门存放大对象,如果一个H区装不下一个大对象,那么G1会寻找连续的H区来存储,为了能找到连续的H区,有时候不得不启动Full GC,G1的大多数行为都把H区作为老年代的一部分来看待

  • G1的垃圾回收过程主要包括如下三个环节

    • 年轻代GC(Young GC)
    • 老年代并发标记过程(Concurrent Marking)
    • 混合回收(Mixed GC)
    • (如果需要,单线程,独占式,高强度的Full GC还是继续存在的,他针对GC的评估失败提供了一种保护机制,即强力回收)

  • 应用程序分配内存,当年轻代的Eden区用尽时开始年轻代回收过程,G1的年轻代收集阶段是一个并行的独占式收集器,在年轻代回收期,G1暂停所有应用程序线程,启动多线程执行年轻代回收,然后从年轻代区间移动存活对象到Survivor区间或者老年区间,也有可能是两个区间都会涉及

  • 当堆内存使用达到一定值(默认45%)时,开始老年代并发标记过程

  • 标记完成马上开始混合回收过程,对于一个混合回收期,G1从老年区间移动存活对象到空闲区间,这些空闲区间也就成为了老年代的一部分,和年轻代不同,老年代的G1回收期和其他GC不同,G1的老年代回收不需要整个老年代被回收,一次只需要扫描/回收一小部分老年代的Region就可以了,同时,这个老年代Region是和年轻代一起被回收的

  • G1回收器垃圾回收过程: Remembered Set

    • 一个对象被不同区域引用的问题
    • 一个Region不可能是孤立的,一个Region中的对象可能被其他任意Region中对象引用,判断对象存活时,是否需要扫描整个Java堆才能保证准确
    • 在其他的分代收集器,也存在这样的问题(而G1更突出)
    • 回收新生代也不得不同时扫描老年代
    • 这样的话会降低Minor GC的效率
    • 无论G1还是其他分代收集器,JVM都是使用Remembered Set来避免全局扫描
    • 每个Region都有一个对应的Remembered Set
    • 每次Reference类型数据写操作时,都会产生一个Write Barrier暂时中断操作
    • 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region(其他收集器: 检查老年代对象是否引用了新生代对象)
    • 如果不同,通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中
    • 当进行垃圾收集时,在GC根节点的枚举范围加入Remembered Set,就可以保证不进行全局扫描,也不会有遗漏

  • G1回收过程一: 年轻代GC

    • JVM启动时,G1先准备好Eden区,程序在运行过程中不断创建对象到Eden区,当Eden空间耗尽时,G1会启动一次年轻代垃圾回收过程
    • 年轻代垃圾回收只会回收Eden区和Survivor区
    • YGC时,首先停止应用程序的执行(STW),G1创建回收集(Collection Set),回收集是指需要被回收的内存分段的集合,年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分
    • 第一阶段,扫描根

      • 根指static变量指向的对象,正在执行的方法调用链上的局部变量等,根据引用连同RSet记录的外部引用作为扫描存活对象的入口
    • 第二阶段,更新RSet
      • 处理[^dirty card queue]中的card,更新RSet,此阶段完成后,RSet可以准确的反映老年代对所在的内存分段中对象的引用
    • 第三阶段,处理RSet
      • 识别被老年代对象指向的Eden中的对象,这些被指向的Eden中的对象被认为是存活的对象
    • 第四阶段,复制对象
      • 此阶段,对象树被遍历,Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段,Survivor区内存分段中存活的对象年龄未达阈值,年龄会加1,达到阈值会被复制到Old区中空的内存分段,如果Survivor空间不够,Eden空间的部分数据会直接晋升到老年代空间
    • 第五阶段,处理引用
      • 处理Soft Weak,Phantom,Final,JNI Weak等引用,最终Eden空间的数据为空,GC停止工作,而目标内存中的对象都是连续存储的,没有碎片,所以复制过程可以达到内存整理的效果,减少碎片

  • G1回收过程二: 并发标记

    • 1.初始标记阶段: 标记从根节点直接可达的对象,这个阶段是STW的,并且会触发一次年轻代GC
    • 2.根区域扫描(Root Region Scanning): G1扫描Survivor区直接可达的老年代区域对象,并标记引用的对象,这一过程必须在YGC之前完成
    • 3.并发标记(Concurrent Marking): 在整个堆中进行并发标记(和应用程序并发标记),此过程可能被YGC中断,在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那这个区域会被立即回收,同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)
    • 4.再次标记(Remark): 由于应用程序持续进行,需要修正上一次的标记结果,是STW的,G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning(SATB)
    • 5.独占清理(cleanup,STW): 计算各个区域的存活对象和GC回收比例,并进行排序,识别可以混合回收的区域,为下阶段做铺垫,是STW的,这个阶段并不会真正的做垃圾收集
    • 6.并发清理阶段: 识别并清理完全空闲的区域

  • G1回收过程三: 混合回收

    当越来越多的对象晋升到老年代Old Region时,为了避免堆内存被耗尽,虚拟机会触发要给混合的垃圾收集,即Mixed GC,该算法并不是一个Old GC,除了回收整个Young Region,还会回收一部分Old Region.这里需要注意: 是一部分老年代,而不是全部老年代,可以选择哪些Old Region进行收集,从而可以对垃圾回收的耗时进行控制,也要注意的是Mixed GC并不是Full GC

    • 并发标记结束后,老年代中百分百为垃圾的内存分段被回收,部分为垃圾的内存分段被计算出来,默认情况下,这些老年代的内存的分段会分8次(可以通过-XX:G1MixedGCCountTarget设置)被回收
    • 混合回收的回收集(Collection Set)包括八分之一的老年代内存分段,Eden区内存分段,Survivor区内存分段.混合回收的算法和年轻代回收的算法完全一样,只是回收集多了老年代的内存分段
    • 由于老年代中的内存分段默认分8次回收,G1会优先回收垃圾多的内存分段,垃圾占内存分段比例越高的,越会被先回收,并且有一个阈值会决定内存分段是否被回收,-XX:G1MixedGCLiveThresholdPercent,默认是65%,意思是垃圾占内存分段比例要达到65%才会被回收,如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间
    • 混合回收并不一定要进行8次,有一个阈值-XX:G1HeapWastePercent,默认为10%,意思是允许整个堆内存中有10%的空间被浪费,意味着如果发现可以回收的垃圾占堆内存的比例低于10%,则不再进行混合回收,因为GC会花费很多的时间,但是回收到的内存却很少

  • G1回收可选的过程四: Full GC

    • G1的初衷就是要避免Full GC的出现,但是如果上述方式不能正常工作,G1会停止应用程序的执行(STW),使用单线程的内存回收算法进行垃圾回收,性能会非常低,应用程序停顿时间会很长
    • 要避免Full GC的发生,一旦发生需要进行调整,什么时候会发生Full GC呢? 比如堆内存太小,当G1在复制存活对象的时候没有空的内存分段可用,则会回退到Full GC,这种情况可以通过增大内存解决
    • 导致G1 Full GC的原因可能有两个`
      • Evacuation的时候没有足够的to-space来存放晋升的对象
      • 并发处理过程完成之前空间耗尽
垃圾收集器 分类 作用位置 使用算法 特点 适用场景
Serial 串行运行 作用于新生代 复制算法 响应速度优先 适用于单CPU环境下的client模式
ParNew 并行运行 作用于新生代 复制算法 响应速度优先 多CPU环境Server模式与CMS配合使用
Parallel 并行运行 作用于新生代 复制算法 吞吐量优先 使用于后台运算而不需要太多交互的场景
Serial Old 串行运行 作用于老年代 标记-压缩算法 响应速度优先 适用于单CPU环境下的Client模式
Parallel Old 并行运行 作用于老年代 标记-压缩算法 吞吐量优先 适用于后台运算而不需要太多交互的场景
CMS 并发运行 作用于老年代 标记-清除算法 响应速度优先 适用于物联网或B/S业务
G1 并发,并行运行 作用于新生代,老年代 标记-压缩算法,复制算法 响应速度优先 面向服务端应用

[^dirty card queue]: 对于应用程序的引用赋值语句object.field=object,JVM会在之前和之后执行特殊的操作以在dirty card queue中入队一个保存了对象引用的信息的card,在年轻代回收的时候,G1会对dirty card queue中所有的card进行处理,以更新RSet实时准确的反映引用关系,不在引用赋值语句处直接更新RSet是因为性能的需要,RSet的处理需要线程同步,开销会很大,使用队列性能会好很多

JVM垃圾回收器 七种经典垃圾回收器相关推荐

  1. java 回收器_Java虚拟机-经典垃圾回收器

    上图列举了七种作用于不同分代的垃圾收集器,如果两个收集器存在连线就说明可以搭配使用.收集器所处的区域表示它所属的年轻代还是老年代 属于年轻代的回收器 Serial收集器 简单高效且内存消耗小,适用于客 ...

  2. JVM常见的七种垃圾收集器的简单比较

    1.Serial收集器曾经是虚拟机新生代收集的唯一选择,是一个单线程的收集器,在进行收集垃圾时,必须stop the world,它是虚拟机运行在Client模式下的默认新生代收集器. 2.Seria ...

  3. JVM -- 垃圾回收器7种（四）

    阅读前可参考 https://blog.csdn.net/MinggeQingchun/article/details/126947384 https://blog.csdn.net/MinggeQi ...

  4. ＜JVM上篇：内存与垃圾回收篇＞13-垃圾回收器

    13. 垃圾回收器 13.1. GC 分类与性能指标 13.1.1. 垃圾回收器概述 13.1.2. 垃圾收集器分类 13.1.3. 评估 GC 的性能指标 吞吐量 暂停时间 吞吐量 vs 暂停时间 ...

  5. JVM 垃圾回收算法与ART CC回收器实现概述

    前言 在作者的上一篇文章<Android R常见GC类型与问题案例>中,对Demo应用的Heap堆结构与Space类型及相对应内存分配算法做了简要的探究,同时对Android R机器运行中 ...

  6. JVM学习----七种垃圾收集器（GC）

    文章目录 GC垃圾收集器 七种经典的垃圾回收器 查看默认垃圾收集器 新生代 Serial垃圾收集器(单线程. 复制算法) ParNew 垃圾收集器 (Serial的多线程版本. 复制算法) Paral ...

  7. 垃圾收集器回收种类 以及七种垃圾收集器

    垃圾收集器回收种类 垃圾收集器是垃圾回收算法的具体实现 串行垃圾回收器(Serial) 它为单线程环境设计且只使用一个线程进行垃圾回收,会暂停用户线程 (并行垃圾回收器)Parallel 多个垃圾收集 ...

  8. Java 的七种垃圾收集器

    了解 Java 中的内存管理. 用 C 或 C++ 这样的编程语言写一个应用时,需要编写代码来销毁内存中不再需要的对象.当应用程序扩展得越来越复杂时,未使用对象被忽略释放的可能性就越大.这会导致内存泄 ...

  9. JVM七种垃圾回收器

    一 七种垃圾回收器总结: 垃圾收集器 分类 作用位置 使用算法 特点 适用场景 Serial 串行运行 作用于新生代 复制算法 响应速度优先 适用于单CPU环境下的client模式 ParNew 并行 ...

最新文章

  1. POJ NOI MATH-7828 最大公约数与最小公倍数
  2. 2019第十届蓝桥杯C/C++ B组省赛 —— 第四题：数的分解
  3. css多浏览常见问题
  4. 致盲目标检测算法，阿里清华发起 “对抗攻击” 挑战赛！
  5. 数据库外键名称不要用自动生成的名字
  6. china-pub春季教材展，给力优惠，买二赠一
  7. SQL知识（浓缩版）快速入门（基础语法、概念）
  8. 刘强东的自白：我为啥要和苏宁打价格战？
  9. 数据可视化工具在医疗领域的应用
  10. window.print() 实现A4纸张打印及去掉页眉页脚及打印链接
  11. python写打飞机游戏
  12. vue 美食杰项目 登录验证
  13. 产品设计需求分析研究
  14. 【电脑桌面不见了怎么办】
  15. 【零基础】极星量化入门十一：远程遥控的简单办法
  16. python图书推荐系统的设计_图书推荐系统毕业设计
  17. 怎么给图片名称快速重命名？来跟我学着两个实用方法
  18. openwrt linux rootfs 分区表,arm盒子快速移植OpenWrt rootfs
  19. 【腾讯敏捷转型No.8】你爱上手机QQ了么？
  20. Python的对象与类

热门文章

  1. React jsPdf+html2canvas 前端生成pdf（分页截断 + 图片质量）
  2. 了解Git的一段时间
  3. 将Excle里的数据直接复制粘贴到Oracle数据库的方法
  4. 亲们 ，paypal账户您们都是怎么提现结汇呢？
  5. python如何另存文件_python如何保存文本文件
  6. 什么是CFO，CEO，CHO，CTO，CIO，CMO？
  7. 公众号中调用支付宝支付
  8. 【统计每个部门获得前三高工资的所有员工及所有员工占前三工资总和的比例】
  9. socket协议介绍
  10. 加油吧！数字化转型@有了桌面云，再也不愁我的英语学习了