GC的性能指标

  • 吞吐量:运行用户代码的时间占总运行时间的比例。
  • 暂停时间:执行垃圾收集时,程序工作线程被暂停的时间。
  • 内存占用:Java堆区所占的内存大小。

高吞吐量较好因为这会让应用程序的用户感觉应用程序线程在做生产性工作。直觉上,吞吐量越高程序运行越快。有时候甚至短暂的200毫秒暂停都可能打断终端用户体验,具有低的较大暂停时间是非常重要的,特别是对于一个交互式应用。

  • 如果选择以吞吐量优先,那么必然需要降低内存回收的执行频率,但是这样会导致GC需要更长的暂停时间来执行内存回收。
  • 如果以低延迟优先为原则,那么为了降低每次执行内存回收的暂停时间,也只能频繁的执行内存回收,单这样又引起了吞吐量的下降。

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

7大垃圾收集器

面试题:JVM垃圾收集器_垃圾收集

面试题:JVM垃圾收集器_垃圾收集器_02

  • 有7种搭配,Serial /Serial Old,Serial/CMS,ParNew/Serial Old,ParNew/CMS,Parallel/Serial Old,Parallel/Parallel Old,G1;
  • 红色虚线,由于维护和兼容性测试的成本,在Jdk 8 时将Serial+CMS,ParNew+Serial Old这2个组合废弃,在Jdk9中进行了移除。
  • 在JDK14中,弃用了Parallel+Serial Old组合。
  • 在Jdk14中,删除CMS垃圾回收器。

Serial回收器:串行回收

  • Serial收集器采用复制算法,串行回收和“stop-the-world”机制的方式执行内存回收,是HotSpot中Client模式下默认新生代垃圾收集器。
  • Serial Old收集器同样采用了串行回收和“stop-the-world”机制的方式执行内存回收,只不过内存回收算法使用的是标记-压缩算法。是HotSpot中Client模式下默认老生代垃圾收集器。在server模式下,可以于新生代的Parallel使用 或者作为老年代CMS收集器的后备垃圾收集方案。

面试题:JVM垃圾收集器_垃圾收集_03

  • 这个收集器是一个单线程的收集器,但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。
  • 优势:简单而高效,对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率,运行在Client模式下的虚拟机也是不错的选择。在用户的桌面应用场景中,可用内存一般不大,可以在较短时间内完成垃圾收集,只要不频繁发生,使用串行回收器是可以接受的。
  • 总结:这种垃圾收集器,在限定单核CPU才可以用,现在都不是单核的了,对于交互较强的应用而言,这种垃圾收集器是不能接受的。一般在java web应用程序中是不会采用串行垃圾收集器的。

ParNew回收器:并行回收

  • ParNew 收集器除了采用并行回收的方式执行内存回收外,2款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法,“stop-the-world”机制。它是很多JVM运行在Server模式下新生代的默认垃圾收集器。

面试题:JVM垃圾收集器_垃圾收集_04

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

Parallel回收器:吞吐量优先

  • Parallel收集器采用了复制算法,并行回收和“stop the world”,和ParNew收集器不同,Parallel收集器的目标是达到一个可控制的吞吐量,它也被称为吞吐量优先的垃圾收集器。自适应调节策略也是Parallel与ParNew一个重要区别。
  • 高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。Parallel Old收集器采用了标记-压缩算法,但同样也是基于并行回收和“stop-the-world”机制。

面试题:JVM垃圾收集器_应用程序_05

  • Parallel收集器和Parallel Old收集器的组合,在Server模式下的内收性能很不错,在Java8中,默认是此垃圾收集器。
  • 参数:
    • -XX:+UseParallelGC:手动指定年轻代使用Parallel并行收集器执行内存回收任务。
    • -XX:+UseParallelOldGC:手动指定老年代都是使用并行回收收集器。
      • 适用于新生代和老年代。默认jdk8是开启的
      • 默认开启一个,另外一个也会被开启。
    • -XX:ParallelGCThreads:设置年轻代并行收集器的线程数。一般地,最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能。
    • -XX:MAXGCPauseMillis:设置垃圾收集器最大停顿时间,时间为毫秒。
    • -XX:GCTimeRatio:垃圾收集时间占总时间的比例,用于衡量吞吐量的大小。
    • -XX:+UseAdaptiveSizePolicy:设置具有自适应调节策略。
      • 在这种模式下,年轻代的大下,Eden和Survivor的比例,晋升老年代的对象年龄等参数会被自动调整,已达到在堆大小,吞吐量和停顿时间的平衡点。
      • 在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆,目标的吞吐量和停顿时间,让虚拟机自己完成调优工作。

CMS回收器:低延迟

  • CMS是HotSpot虚拟机中第一款真正意义的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。它采用的是标记-清除算法,并且也会STW,它的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短就越适合与用户交互的程序,良好的响应速度能够提升用户体验,一般应用互联网或者B/S系统的服务端上。
  • CMS作为老年代的收集器,无法与新生代收集器Parallel配合工作,所以在JDK1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器的一个。

面试题:JVM垃圾收集器_内存回收_06

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

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

总结:尽管CMS是并发回收,但是在初始化标记和重新标记这2个阶段仍然需要执行STW机制,但是时间不会太长,目前所有的垃圾收集器都做不到不需要STW,只是尽可能缩短暂停时间。由于最耗时的并发标记和并发清除都不需要暂停工作,所以整体的回收都是低停顿的。由于在垃圾收集阶段用户线程没有中断,所以在回收过程中,还应该确保应用程序用户线程有足够的内存可用,应该当堆内存使用率达到某一阈值,便开始回收。

  • CMS收集器采用的是标记-清除算法,这意味着不可避免的会产生一些内存碎片,那么CMS在为新对象分配内存空间的时候,将无法使用指针碰撞,而只能选择空闲列表执行内存分配。
  • 为什么CMS不能用标记-压缩算法? 答:因为在并发清除的时候,用压缩整理内存的话,原来的用户线程使用的内存还怎么用?要保证用户线程能继续执行,前提的它运行的资源不受响应,整理压缩更适合STW这种场景执行。
  • 优点:
    • 并发收集
    • 低延迟
  • 缺点:
    • 会产生内存碎片,用户线程可用的空间不足。在无法分配大对象的情况下,会提前触发FGC.
    • CMS收集器对CPU资源非常敏感。在并发阶段,会因为占用部分线程导致应用程序变慢,总的吞吐量降低。
    • CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生,在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的,那么在并发标记阶段如果产生新的垃圾对象,CMS将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行GC时释放之前未被回收的内存空间。
  • 参数:
    • -XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空问进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带來的问题就是停顿时间变得更长了。
    • XX:CMSFullGCsBeforeCoinpaction 设 罝 在 执 行 多少次 Full GC后对内存空间进行压缩整理。
    • -XX:ParallelCMSThreads 设置CMS的线程数量。CMS 默认启动的线程数是(ParallelGCThreads+3) /4,ParallelGCThreacis是年较代并行收集器的线程数。当CPU资源比较紧张时,受到CMS收集器线程的影响,应用程序的忡能在垃圾回收阶段可能会非常糟糕。
    • -XX:+UseConcMar]cSweepGC手动指定使用CMS收集器执行内存回收任务。
      • 幵/3该参数后会自动将-XX:+UseParNewGC打幵。即:ParNew<YounglKffl)+CMS (01d[X/H)+serial
    • -XX: CMSlnitiatingOccupanyFraction 设置推内存使用率的阈值,—旦达到该阈值,便开始进行回收。
    • JDK5及以前版木的默认值为68,即当老年代的空间使用率达到68%时,会执行—次CMS回收。JDK6及以上版本驮认值为92%
    • 如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低CMS的触发频率,减少老年代回收的次数可以较为明显地改#应用程序性能。反之,如采应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代审行收集器。因此通过该选项便可以有效降低Full GC的执行次数。
    • -XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存 压缩整理过程无法并发执行,所带來的问题就是停顿时间变得更长了。
    • -XX:CMSFullGCsBeforeCoinpaction 设罝在执行多少次Full GC后对 内存空间进行压缩整理。
    • -XX:ParallelCMSThreads 设置CMS的线程数。
      • CMS 默认后动的线程数是(ParallelGCThreads+3>/4, ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张 时,受到CMS收染器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕。

G1收集器:区域分代化

  • 概念:

    • 既然我们己经有前面几个强大的GC,为什么还要发布Garbage First (G1) GC ,原因就在于成用程所应对的业务越来越庞大、复杂,用户越来越多,没有GC 就不能保证应用程序正常进行,而经常造成STW的GC又跟不上实际的需求,所 以才会不断地尝试对GC进行优化。G1 (Garbage-First)垃圾回收器是在 Java7 update 4之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一。 与此冋时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降 低哲停时间(pause time),同时廉顾良好的吞吐量。官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担 当起“全功能收集器”的重任与期望。
    • 为什么名字叫做Garble First (G1)?
      • 因为G1是一个并行回收器,它把堆内存分刺为很多不相关的区域(Region)(物理上不连续的)。使用不同的Region来表示Eden、幸存者0,幸存者1,老年代等。
      • G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个 Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region。
      • 由于这种方式的侧重点在于回收垃圾最大量的区间 (Region),所以我们给 G1—个名字:垃圾优先( Garbage First)。
    • Gl (Garbage-First)是一款面向服务端应用的垃圾收集器,主要针对配备多核CPU及大容量内存的机器,以极高概率满足GC停顿时间的同时,还兼具高吞吐量的性能特征。 在JDK1.7版本正式启用,移除了Experimental的标识,是JDK 9以后的默认垃圾回收器,取代了CMS回收器以及Parallel + Parallel Old组合。被Oracle官方称为“全功能的垃圾收集器”。于此同时,CMS己经在JDK 9中被标记为废弃(deprecated)。在jdk8中还不是默认的垃圾回收器,需要使用-XX:+UseGlGC來起用。
  • 优点

    • 并行与并发

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

      • 从分代上看,G1依然屈于分代型垃圾回收器,它会区分年轻代和老年代,年轻代依然有Eden区和Survivor区, 但从堆的结构上看,它不要求整个Eden区、年轻代或者老年代都是连续的,也不再坚持固定大小和固定数量。
      • 将堆空间分为若干个E域(Region〉,这些区域中包含了逻辑上的年轻代和老年代。
      • 和之前的各类回收器不同,它同时兼顾年轻代和老年代。对比其他回收器,或者工作在年轻代,或者工作在老年代。
    • 空间整合

      • CMS: “标记-沾除”算法、内存碎片、荇干次GC后进行一次碎片整理
      • G1将内存划分为一个个的region。内存的回收处以region作为基本单位的。 Region之间复制算法,但整体上实际可苕作足标记-压缩(Mark-Compact) 算法,两种算法都可以避免内存碎片。这种特性有利于程序长时间运行,分配 大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当 Java堆非常大的时候,G1的优势更加明显。
    • 可预测的停顿时间模型(即:软实时 soft real-time)

      • 这是G1相对CMS的另一大优势,G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M亳秒的时间片段内,消耗在垃圾收集上的时间不得超过N亳秒。
    • 由于分区的原因,G1可以只选取部分医域进行内存回收,这样缩小了回收的范围,因此对于全局停顿情况的发生也能得到较好的控制。

    • G1跟踪各个 Region里面的垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许的收集 时间,优先回收价值最大的Region。保证G1收粜器在有限的时间内可以获取尽可能高的收集效率。

    • 相比CMS GC, G1未必能做到CMS在最好情况下的延时停顿,但是最差情况要好很多。

  • 缺点

    • 相较于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作线程数的值,最多设汽.为8 。
      • -XX:ConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParallelGCThreads)的 1/4左右。
      • XX: InitiatingHeapOccupancyPercent 设置触发并发GC周期的 Java堆占用率阈值。超过此值,就触发GC。默认值是45。
  • 操作步骤

    • 设置G1垃圾收集器
  • 设置堆的最大内存

    • 设置最大的停顿时间
  • 提供了三种垃圾回收模式:YGC,Mixed GC和FGC,在不同的条件下触发。

  • 适用场景

    • 商向服务端应用,针对 M有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)

    • 最主要的应用是需要GC低延迟,并具有大堆的应用程序提供解决方法。

    • 在堆大小约6 GB或更大时,可预测的暂停时间可以低0.5秒:( G1通过每次只 清理一部分而不时全部的Region的增量式清理来保证每次GC停顿时间不会过长)。

    • 用来替换掉JDK1.5的CMS收集器。

      • 超过50%的;Java堆被活动数据占用
      • 对象分配频率或年代提升频率变化很大
      • GC停顿时间过长(长于0.5至1秒)
    • HotSpot垃圾收集器里,除 了G1以外,其他的垃圾收集器使用内置的JVM线程执行 GC的多线程操作,而G1 GC可以采用应用线程承担后台运行的GC工作,即当]VM的GC线程处现速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程。

  • 分区Region:化整为零

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

    • 主要环节:年轻代GC,老年代并发标记过程,混合回收,可能会有Full GC。

    • 应用程序分配内存,当年轻代的Eden区用尽时开始年轻代回收过程:G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期,G1 GC皙停所有应用程序线程,启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Survivor区间或者老年区间,也有可能是两个区间都会涉及。 当堆内存使用达到一定值(默认45%)时,开始老年代并发标记过程。 标记完成马上开始混合回收过程。对于一个混合回收期,G1 GC从老年区间移动存活对象 到空闲区间,这些空闲区间也就成为了老年代的一部分。和年轻代不同,老年代的G1回收器和其他GC不通,G1的老年代回收器不需要整个老年代被回收,一次只需要扫描/回收一小部分老年代的Region就可以了。同时,这个老年代Region是和年轻代一起被回收的。

    • RSet:

      • 无论 G1还是其他分代收集器,JVM都足使用Remembered Set来避免全局扫描;
      • 每个Region都存一个对应的Remembered Set;
      • 每次Reference类型数据写操作时,都会产生一个Write Barrier料时中断操作;
      • 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region (其他收集器:检查老年代对象是否引用了新生代对象);
      • 如果不同,通过CardTable把相关引用信息记录到引用指叫对象的所在Region对应的 Remembered Set中;
      • 当进行垃圾收集时,在GC根节点的枚举范围加入Remembered Set:就可以保证不进行全局扫描,也不会有遗漏。

      面试题:JVM垃圾收集器_内存回收_07

    • 回收过程一:年轻代GC

      • 概念:]VM启动时, G1先准备好Eden区,程序在运行过程中不断创建对象到Eden 区,当Eden空间耗尽时,G1会启动一次年轻代垃圾回收过程。 年轻代垃圾回收只会回收Eden区和Survivor区。 YGC时,首先G1停止应用程序的执行(Stop-The-World) , G1创建回收集(Collection Set),回收集是指需要被回收的内存分段的集合,年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。
      • 第一阶段,扫描根。 根是指static变软指向的对象,正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口。
      • 第二阶段,更新RSet。 处理dirty card queue(见备注)中的card,更新RSet。此阶段完成后,RSet可以准确的反 映老年代对所在的内存分段中对象的引用。
      • 第三阶段,处理RSet。 识別被老年代对象指叫的Eden中的对象,这些被指向的Eden中的对象被认为是存活的对象。
      • 第四阶段,复制对象。 此阶段,对象树被遍历,Edeng内存段中存活的对象会被复制到Survivor区中空的内存分段, Survivor区内存段中存活的对象如果年龄未达阈值,年龄会加1,达到阈值会被复制到 Old区中空的内存分段。如果Survivor空间不够,Eden空间的部分数据会直接晋升到老年代 空间。
      • 第五阶段,处理引用。 处理Soft, Weak, Phantom, Final, JNI Weak 等引用。最终Eden空间的数据为空,GC停止工作,而目标内存中的对象都是连续存储的,没有碎片,所以复制过程可以达到内存整理的效果,减少碎片。
    • 回收过程二:并发标记过程

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

      • 当越来越多的对象晋升到老年代old region时,为了避免堆内存被耗尽, 虚拟机会触发一个混合的垃圾收集器, 即Mixed GC,该算法并不是一个 Old GC,除了回收整个 Young Region, 还会回收一部分的Old Region。这里需要注意:是一部分老年代,而不是全部老年代。可以选择哪些Old Region进行收集,从而可以对垃圾回 收的耗时时间进行控制。也要注意的是Mixed GC并不是Full GC。
      • 并发标记结束以后,老年代中百分百为垃圾的内存分段被回收了,部分为垃圾的内存分 段被计算了出来。默认情况下,这些老年代的内存分段会分8次(可以通过XX:GlMixedGCCountTarget 设置)被回收。
      • 混合回收的回收集(Collection Set)包括八分之一的老年代内存分段,Eden区内存 分段,Survivor区内存分段。混合回收的箅法和年轻代回收的箅法完全一样,只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
      • 由于老年代中的内存分段默认分8次回收,G1会优先回收垃圾多的内存分段。垃圾占内 存分段比例越高的,越会被先回收。并且有一个阈值会决定内存分段是否被回收,- XX:GlMixedGCLiveThresholdPercent,默认力65%,意思是垃圾占内存分段比例要达到会被回收。如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间。
      • 混合回收并不一定要进行8次。有一个阈值-XX:GlHeapWastePercent,默认值为10%, 意思是允许整个堆内存中杳10%的空间被浪费,盘味着如果发现可以回收的垃圾占堆内存的比例低于10%.则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存 却很少。
    • 回收过程四:Full GC

      • G1的初衷就是要避免Full GC的出现。侃是如果上述方式不能正常工作,G1 会停止应用程序的执行(Stop-The-World),使用单线程的内存回收算法 进行垃圾回收,性能会非常差,应用程序停顿时间会很长。
      • 出现原因:1. Evacuation的时候没有足够的to-space来存放晋升的对象。2. 并发处理过程完成之前空间耗尽。
    • 补充:

      • 从Oracle官方透露出来的信总可获知,回收阶段(Evacuation)其实 也有想过设计成与用户程序一起并发执行,但这件事做起来比较复杂,考虑到G1只是回收一部分Region,停顿时间是用户可控制的,所以并不迫切去实现,而选择把这个特性放到了 G1之后出现的低延迟垃圾 收集器(即ZGC)中。另外,还考虑到G1不是仅仅而向低延迟,停顿用 户线程能够最人幅度提高垃圾收集效率,为了保证吞吐量所以才选择完全暂停用户线程的实现方案。
    • 建议优化

      • 年轻代大小
        1. 避免使用 -Xmn或 -XX:NewRatio等相关选项显式设置年轻代大小
        2. 固定年轻代的大小会覆盖暂停时间目标。
      • 哲停时间目标不要太过严苛
        1. G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间。
        2. 评估G1 GC的吞吐量时,皙停时间目标不要太严苛。H标太过严苛表示你愿意承受更多的垃圾回收开销,而这些会直接影响到吞吐量。

    面试题:JVM垃圾收集器_内存回收_08