垃圾收集器

一、垃圾收集算法

    ① 分代收集理论

 　　 核心：根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择不同的垃圾收集算法。

　　　　　 比如在新生代，每次收集都会有大量的对象死去，所以可以选择复制算法，只需要付出少量对象的复制就可以完成每次垃圾收集。

 　　　　   而老年代的对象存活几率比较高，而且没有额外的空间对它分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

　② 复制算法

　　  核心：为了解决效率问题，引出了复制算法。它将内存分为大小相同的两块空间，每次只使用一块。当这一块的内存使用完后，将存活对象复制到另外一块内存，然后再把当前使用空间一次清理掉。

 　　 优点：效率高。 缺点：浪费内存空间，内存使用率低。

　③ 标记-清除算法

　　  核心：分为两个阶段“标记”和“清除”。 将存活对象标记出来，然后对未标记对象进行清除。或者反过来，对未存活对象标记，然后进行清除。

         缺点： 1.如果标记的对象太多，那么回收效率不高  2. 内存碎片化，会产生大量的内存碎片。     

　④ 标记-整理算法

　　  核心：区别于标记清除算法的地方在于，标记完对象后，会先将对象移动到一端（向同一端移动），然后对分界线另一端进行清除。

二、垃圾收集器（优化垃圾收集器最核心的点就是为了减少STW时间）

　　本文着重讲解CMS垃圾收集器和G1垃圾收集器

 

    如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现

    ① Serial

　　单线程收集器（新生代采用复制算法，老年代采用标记-整理算法）

    ② Paraller Scavenge

　　Serial收集器的多线程版本。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。

　　CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

    ③ ParNew 

　　ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

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

   ④  CMS（Concurrent Mark Sweep）

　　<1> 是一种以获取最短回收停顿时间为目标的收集器。非常符合使用在注重用户体验的系统中，第一次实现了让垃圾收集线程和用户线程（基本上）同时工作。　

　　从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的。它的整个回收过程大概如下：

　　

　　1. 初始标记：暂停所有的其他线程（STW），并记录下所有 GC Roots（局部变量表中引用的对象、本地方法引用的对象、方法区中静态属性引用的对象、方法区中静态常量池中引用的对象）直接能引用的对象，速度很快。

　　2. 并发标记：并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。

　　3. 重新标记：修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记

　　4. 并发清理：开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。

　　5. 并发重置：重置本次GC过程中的标记数据。

　　<2> 优点：并发收集、低停顿。

　　<3> 缺点：① 对CPU资源敏感（会和服务抢资源）。 ② 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了) ③ 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-

　　XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理 ④ 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，

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

 　　<4>  CMS的相关核心参数

　　　　① -XX:+UseConcMarkSweepGC  启用cms垃圾收集器

　　　　②-XX:ConcGCThreads  并发的GC线程数

　　　　③-XX:+UseCMSCompactAtFullCollection  FullGC之后做压缩整理（减少碎片）

　　　　④-XX:CMSFullGCsBeforeCompaction  多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次 

　　　　⑤ -XX:CMSInitiatingOccupancyFraction  当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）

　　　　⑥-XX:+UseCMSInitiatingOccupancyOnly  只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整

　　　　⑦-XX:+CMSScavengeBeforeRemark  在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段

　　　　⑧ -XX:+CMSParallellnitialMarkEnabled  表示在初始标记的时候多线程执行，缩短STW

　　　　⑨-XX:+CMSParallelRemarkEnabled  在重新标记的时候多线程执行，缩短STW

   ⑤  G1（garbage first）

　　　　主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征

　　　　1. G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。一般Region大小等于堆大小除以2048，

　　　　　比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。

　　　　2. G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。默认年轻代对堆内存的占比是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个。
　　　　3. 一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。

　　　　总结：G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，

　　　　而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，

　　　　每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。
　　　　Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。
　　　　Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

　　　　G1收集器一次GC的运作过程大致分为以下几个步骤：

　　　　初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；
　　　　并发标记（Concurrent Marking）：同CMS的并发标记
　　　　最终标记（Remark，STW）：同CMS的重新标记
　　　　筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，

　　　　比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，

　　　　那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，

　　　　但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活

　　　　对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起

　　　　并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

　　　　G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，

　　　　比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。

　　　　这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

　　　　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 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才
　　　　触发年轻代gc。那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。
　　　　或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor
　　　　区域的50%，也会快速导致一些对象进入老年代中。所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，

　　　　在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

　　　　什么场景适合使用G1
　　　　1. 50%以上的堆被存活对象占用
　　　　2. 对象分配和晋升的速度变化非常大
　　　　3. 垃圾回收时间特别长，超过1秒
　　　　4. 8GB以上的堆内存(建议值)
　　　　5. 停顿时间是500ms以内

 

　　三色标记：

　　在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。这里我们引入“三色标记”来给大家解释下，把Gcroots可达性分析遍历对象过程中遇到的对象， 按照“是否访问过”这个条件标记成以

　　下三种颜色：

　　黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。
　　灰色： 表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。
　　白色： 表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。

 

　　

　　

　　多标-浮动垃圾

　　在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过
　　(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动
　　垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。
　　另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分
　　对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

　　

　　漏标-读写屏障

　　漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（Incremental Update） 和原始快照（Snapshot At The Beginning，SATB） 。
　　增量更新就是当黑色对象插入新的指向白色对象的引用关系时， 就将这个新插入的引用记录下来， 等并发扫描结束之后， 再将这些记录过的引用关系中的黑色对象为根， 重新扫描一次。 这可以简化理解为， 黑色对象一旦新插入了指向
　　白色对象的引用之后， 它就变回灰色对象了。原始快照就是当灰色对象要删除指向白色对象的引用关系时， 就将这个要删除的引用记录下来， 在并发扫描结束之后，
　　再将这些记录过的引用关系中的灰色对象为根， 重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)
　　以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过写屏障实现的。