光輝歲月

导航

 

  b话不多说,进入正题。

  芜湖起飞~

 

  先来看看一般的垃圾收集器中的gc:

    Minor GC/Young GC:指发生新生代的的垃圾收集动作,Minor GC非常频繁,回收速度一般也比较快。

  

    Major GC/Full GC:一般会回收老年代,年轻代,方法区的垃圾, Major GC的速度一般会比Minor GC的慢10倍以上。     

 

  1.垃圾收集算法

 

  1.1标记-清除算法

 

    算法分为“标记”和“清除”阶段:首先标记出所有需要回收的对象,在标记完 成后统一回收所有被标记的对象。它是最基础的收集算法,效率也很高。

    但是,会有两个问题:

      1:效率问题(需要扫描所有的对象,然后去标记需要清除的垃圾对象),时间复杂度高。

      2:空间问题(清除之后不会压缩空间,存在着大量的碎片空间,不利于连续内存的大对象存放)。

    

    算法执行前;

    我们来看下面的图:

    

 

 

   标记垃圾对象(扫描堆里面所有对象,耗时长):

  

 

 

   清除垃圾对象后:

  

 

 

   图中我们就可以看出,剩余内存空间比较碎片化,并没有被整理。

 

 

  1.2标记-整理算法

    标记过程仍然与“标记-清除”算法一 样,但后续步骤不是直接对可回收对象回收,而是让所有存活的对象向一段移 动,然后直接清理掉端边界以外的内存。

    标记阶段(标记存活对象):

  

 

 

   整理阶段(整理存活对象):

  

 

 

   清除阶段(清除除了存活对象以外的所有空间):

  

 

 

  

 

  1.3复制算法

  将内存分为大小相同的两块,每次使用其中的一块。当这一块的内存使用完后,就将还存活的对象复制到 另一块去,然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内 存区间的一半进行回收。

  将一半内存空间保留:

  

 

   将存活对象有序复制到保留空间中:

  

 

   清理非保留空间:

  

 

   将清理过后的一半空间设置为保留空间,原保留空间设置为可用空间:

  

 

   这样的一个反复过程。

 

 

  1.4分代收集算法

  当前虚拟机的垃圾收集都采用分代收集算法,这种算法没有什么新的思想,只是 根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代, 这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。 比如在新生代中,每次收集都会有大量对象(近99%)死去,所以可以选择复制算 法,只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象 存活几率是比较高的,而且没有额外的空间对它进行分配担保,所以我们必须选 择“标记-清除”或“标记-整理”算法进行垃圾收集。注意,“标记-清 除”或“标记-整理”算法会比复制算法慢10倍以上。

 

 

 

  2.垃圾收集器

  2.1Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)

  Serial(串行)收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一 个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃 圾收集工作,更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程( "Stop The World" ),直到它收集结束。

  新生代采用复制算法,老年代采用标记-整理算法。

  优点:

    Serial收集器由于没有线程交互的开销,自然可以获得很高的单线程收集效率。

  缺点:

    会发生stop the world。

  Serial Old收集器是Serial收集器的老年代版本,它同样是一个单线程收集器。它主要有两大用 途:一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用,另一种用途是 作为CMS收集器的后备方案。

  Serial收集器工作流程:

  

 

 

 

  2.2 ParNew收集器(-XX:+UseParNewGC)

   ParNew收集器其实就是Serial收集器的多线程版本,除了使用多线程进行垃圾收集外,其余行为 (控制参数、收集算法、回收策略等等)和Serial收集器完全一样。默认的收集线程数跟cpu核数 相同,当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数,但是一般不推荐修改。

  新生代采用复制算法,老年代采用标记-整理算法。

  优点:

    多线程版的Serial收集器,效率比Serial要高。

  缺点:

    会发生stop the world。

  ParNew收集器工作流程:

  

 

   它是许多运行在Server模式下的虚拟机的首要选择,除了Serial收集器外,只有它能与CMS收集器 (真正意义上的并发收集器,后面会介绍到)配合工作。

 

  2.3Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),- XX:+UseParallelOldGC(老年代))

  Parallel Scavenge 收集器类似于ParNew收集器,是Server 模式(内存大于2G,2个cpu)下的 默认收集器。

  Parallel Scavenge收集器关注点是吞吐量(高效率的利用CPU)。

    所谓吞吐量就是CPU中用于运行用户代码的时 间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量,如果对于收集器运作不太了解的话,可以选择把内存管理优化交给虚拟机去完 成也是一个不错的选择。

  新生代采用复制算法,老年代采用标记-整理算法。

  流程图就不放了,和parnew收集器是一样的。

 

  Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算 法。在注重吞吐量以及CPU资源的场合,都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。

  

 

  2.4 CMS收集器(-XX:+UseConcMarkSweepGC(old))(gc线程和用户线程并行的收集器,优化了用户体验,主要作用与老年代)

  CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它 非常符合在注重用户体验的应用上使用,它是HotSpot虚拟机第一款真正意义上的并发收集器, 它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。

  从名字上来看就可以看出用的是标记-清除算法。但是cms收集器在工作过程中有4个步骤:

    -初始标记: 暂停所有的其他线程,并记录下gc roots直接能引用的对象,速度很快 ;

    -并发标记: 同时开启GC和用户线程,用一个闭包结构去记录可达对象。但在这个阶段 结束,这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新 引用域,

            所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引 用更新的地方。

    -重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记 产生变动的那一部分对象的标记记录,

            这个阶段的停顿时间一般会比初始标记阶段的时间稍 长,远远比并发标记阶段时间短。

    -并发清理: 开启用户线程,同时GC线程开始对未标记的区域做清扫。

 

   工作流程:

  

 

   优点:

    gc线程和用户线程并行,增加了用户体验。虽然会发生stw,但是停顿时间很短(低停顿)。

  缺点:

    1:会抢占用户资源(和用户线程并发执行,抢占cpu资源)

    2:无法处理浮动垃圾(在并发清理阶段又产生垃圾,这种浮动垃圾只能等到下一次gc再清理了);

    3:它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生,当然 通过参数-XX:+UseCMSCompactAtFullCollection 可以让jvm在执行完标记清除后再做整理。

      (需要配置参数才能清理碎片化空间)

    4:执行过程中的不确定性,会存在上一次垃圾回收还没执行完,然后垃圾回收又被触 发的情况,特别是在并发标记和并发清理阶段会出现,一边回收,系统一边运行,

       也许没回 收完就再次触发full gc,也就是"concurrent mode failure",此时会进入stop the world,用serial old垃圾收集器来回收

      (因为是和用户线程并行,用户线程产生的垃圾对象可能又一次会触发full gc,直接就结束了cms收集器线程,直接触发stw,使用用serial old收集器去清理老年代)。

 

  cms收集器是清理老年代的收集器,配合ParNew收集器回收年轻代来做一次full gc。

 

 

    2.5G1收集器(-XX:+UseG1GC)

  G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机 器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征。(高配置服务器考虑此收集器)

  主要是复制算法实现垃圾回收

  G1收集器内存模型:

  

 

 

   humongous区:G1收集器特有的区,存放大对象(超过region的50%大小的对象会被存放到Humongous区)。

  G1将Java堆划分为多个大小相等的独立区域(Region),JVM最多可以有2048个Region。 一般Region大小等于堆大小除以2048,比如堆大小为4096M,则Region大小为2M,

当然也可以 用参数"-XX:G1HeapRegionSize"手动指定Region大小,但是推荐默认的计算方式。 G1保留了年轻代和老年代的概念,但不再是物理隔阂了,它们都是(可以不连续)Region的集合。

  (上图中的每个小格子都代表一个region)

  

  特性1:默认年轻代对堆内存的占比是5%,如果堆大小为4096M,那么年轻代占据200MB左右的内存, 对应大概是100个Region,可以通过“-XX:G1NewSizePercent”设置新生代初始占比,在系统运行中,JVM会不停的给年轻代增加更多的Region,但是最多新生代的占比不会超过60%,可以 通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前 一样,默认8:1:1,假设年轻代现在有1000个region,eden区对应800个,s0对应100个,s1对应100个(适应minor gc中年轻代由小到大扩大:开始假设gc时间为默认的200ms,但是由于一开始年轻代很小,清理这些region达不到200ms的时间,这个时候是不会触发gc的,jvm认为这是浪费性能的操作,直接给年轻代分配更多的内存,而不是去执行gc)。

  特性2:一个Region可能之前是年轻代,如果Region进行了垃圾回收,之后可能又会变成老年代,也就是说Region的区域功能可能会动态变化。

  特性3:G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样,唯一不同的是对大对象 的处理,G1有专门分配大对象的Region叫Humongous区,而不是让大对象直接进入老年代的 Region中。在G1中,大对象的判定规则就是一个大对象超过了一个Region大小的50%,比如按 照上面算的,每个Region是2M,只要一个大对象超过了1M,就会被放入Humongous中,而且 一个大对象如果太大,可能会横跨多个Region来存放(多个连续的Humongous区)。

 

  G1收集器工作步骤:

    -初始标记:同CMS的初始标记。

    -并发标记:同CMS的并发标记。

    -最终标记:同CMS的重新标记。

    -筛选回收:筛选回收阶段首先对各个Region的回收价值和成本进行 排序,根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制 定回收计划,比如说老年代此时有1000个Region都满了,但是因为根据预期停顿时间,本次垃圾回收可能只能停顿200毫秒,那么通过之前回收成本计算得知,可能回收其中800个 Region刚好需要200ms,那么就只会回收800个Region,尽量把GC导致的停顿时间控制在 我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行,但是因为只回收一 部分Region,时间是用户可控制的,而且停顿用户线程将大幅提高收集效率。不管是年轻代 或是老年代,回收算法主要用的是复制算法,将一个region中的存活对象复制到另一个 region中,这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次,G1采用复制 算法回收几乎不会有太多内存碎片。

    (会按照这些region清空所需时间排列,从最短耗时的region开始清理,加起来所得到默认的停顿200ms的那些region清理)。

    G1收集器在后台维护了一个优先列表,每次根据允许的收集时间,优先选择回收价值最大的 Region(这也就是它的名字Garbage-First的由来),比如一个Region花200ms能回收10M垃 圾,另外一个Region花50ms能回收20M垃圾,在回收时间有限情况下,G1当然会优先选择后面 这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式,保证了G1收集 器在有限时间内可以尽可能高的收集效率。

 

  用图解的话,跟cms不同处就是筛选回收:

  

 

 

 

  优点:

    1:并行与并发:G1能充分利用CPU、多核环境下的硬件优势,使用多个CPU(CPU或者 CPU核心)来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执 行GC动作,G1收集器仍然可以通过并发的方式让java程序继续执行。

    2:虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但是还是保留了分代的概念。

    3:与CMS的“标记--清理”算法不同,G1从整体来看是基于“标记整理”算法 实现的收集器;从局部上来看是基于“复制”算法实现的。(不需要压缩空间,自动做到碎片压缩,因为都是一个个region,都是比较大的空间了,不再是碎片化的空间)

    4:可预测的停顿:这是G1相对于CMS的另一个大优势,降低停顿时间是G1 和 CMS 共同 的关注点,但G1 除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。(可以控制stw的时间)

 

  G1垃圾收集器的gc:

    Minor GC(YoungGC):YoungGC并不是说现有的Eden区放满了就会马上触发,而且G1会计算下现在Eden区回收大 概要多久时间,如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值,那么增加年轻代 的region,继续给新对象存放,不会马上做Young GC,直到下一次Eden区放满,G1计算回收时 间接近参数 -XX:MaxGCPauseMills 设定的值,那么就会触发Young GC。

    MixedGC:不是FullGC,老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercen)设定的值((默认45%)则触发,回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区,正常情况G1的垃圾收集是先做MixedGC,主要使用复制算法,需要把各个region中 存活的对象拷贝到别的region里去,拷贝过程中如果发现没有足够的空region能够承载拷贝对象 就会触发一次Full GC

    Full GC:停止系统程序,然后采用单线程进行标记、清理和压缩整理,好空闲出来一批Region来供下 一次MixedGC使用,这个过程是非常耗时的。

 

  G1收集器参数设置

     -XX:+UseG1GC:使用G1收集器

    -XX:ParallelGCThreads:指定GC工作的线程数量

    -XX:G1HeapRegionSize:指定分区大小(1MB~32MB,且必须是2的幂),默认将整堆划分为 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:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值,在混合回收的时 候,对Region回收都是基于复制算法进行的,都是把要回收的Region里的存活对象放入其他 Region,然后这个Region中的垃圾对象全部清理掉,这样的话在回收过程就会不断空出来新的 Region,一旦空闲出来的Region数量达到了堆内存的5%,此时就会立即停止混合回收,意味着 本次混合回收就结束了。

    -XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收 该region,如果超过这个值,存活对象过多,回收的的意义不大。

    -XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次),在最后一个筛 选回收阶段可以回收一会,然后暂停回收,恢复系统运行,一会再开始回收,这样可以让系统不至 于单次停顿时间过长。

posted on 2020-07-31 17:23  光輝歲月  阅读(167)  评论(0编辑  收藏  举报