JVM成神路之GC分代篇分代GC器CMS收集器及YoungGCFullGC

　　引言
　　本篇则重点会对于分代收集器的实现进行全面详解，其中会涵盖串行收集器、并行收集器、三色标记、SATB算法、GC执行过程、并发标记、CMS收集器等知识，本篇则偏重于分析GC机制的落地实现，也就是垃圾收集器（Garbage Collector）。一、堆空间回顾与GC收集器概述
　　GC覆盖的范围有堆空间与元空间，而主要的作用范围则是堆空间，所以先简单回顾堆空间后，再对于GC中的一些概念进行阐述，有了这些基础后再对GC收集器进行阐述。1.1、堆空间回顾
　　JVM的堆空间结构会根据运行时具体采用的GC收集器来决定。在所有的GC收集器中，大体会将堆空间分为分代、分区两大类：
　　如上图，分代堆空间中会分为新生代与年老代两个区域，而新生代又会分为Eden*1、Survivor*2三块。其中新生代采用复制算法，HotSpot中因为调整了Eden与Survivor区域的比例为8:1:1，所以说新生代的内存最多浪费10%，最大容量为80%+10%=90%。而当Survivor空间不足以存放存活对象时，会依赖于年老代进行分配担保，承接符合标准的对象进入年老代空间。1.2、GC收集器概述
　　上篇的垃圾收集相关算法是GC机制的方法论，而垃圾收集器则是GC机制的具体实现。
　　但在Java的生态中，存在很多款GC收集器，其中并不存在一款最好最优的收集器，也不存在所谓的万能收集器。因为实际开发过程中，我们需要根据项目的业务类型，选出对应用程序而言最合适的收集器即可。
　　不过在了解GC收集器之前，首先得明白几个GC收集器中常见的名词。1.2.1、GC收集器中的名词解释
　　在GC收集器中存在一些经常出现的名词，这些名词也是在认识GC收集器之前不得不了解的，如：串行回收、并行回收、独占执行、并发执行、吞吐量、停顿时间、吞吐量优先、响应时间优先等。串行、并行与独占、并发①串行Serial收集：所有用户线程停止，单条GC线程回收堆的情况被称为串行回收。②并行Parallel收集：所有用户线程停止，多条GC线程回收堆的情况（需多核CPU支持）。③独占Monopoly执行：这里是指GC工作时，GC线程会抢占所有资源执行，整个应用程序会被停止。④并发Concurrent执行：这里的并发是指用户线程和GC线程同时（交替）执行的情况，不会停下某类线程。吞吐量
　　吞吐量是性能优化中的一个重要指标，它是指CPU用于执行用户代码的时间与CPU总耗时的比值，在Java中，吞吐量的计算公式为：
　　吞吐量 = 用户代码执行总时长 /（用户代码执行总时长 + 垃圾回收总时长）。
　　如JVM在线上执行了100min，其中执行用户代码花费了99min，垃圾回收总用时1min，那么吞吐量则为99min/(99min+1min)=99%。停顿时间
　　停顿时间是指GC收集器在工作时，所有用户线程（整个应用程序）的暂停时间。对于独占类的GC收集器而言，停顿时间会比较长。而对于并发类的GC收集器来说，因为GC线程和用户线程是交替执行的，所以程序的停顿时间会缩短，但总体GC效率不如独占GC收集器，因此系统的吞吐量会降低。
　　基于独占收集器和并发收集器的特性而言，就牵扯出了两个调优时的新名词：吞吐量优先与响应时间优先。 相对而言，在设计系统架构选择GC收集器或进行调优时，最终都是在追求更高的吞吐量以及更短的响应时间。吞吐量优先：为了确保程序的更高吞吐，允许GC发生时出现长时间暂停。响应时间优先：为了确保用户更好的体验，可以牺牲一定的吞吐量换取更快的响应速度，发生GC时暂停时间越短越好。1.2.2、Java中的GC收集器概述
　　在如今的官方JDK中，JVM的GC收集器具体实现存在十款，分别为Serial、ParNew、Parallel Scavenge、CMS、Serial Old（MSC）、Parallel Old、G1、ZGC、Shenandoah、Epsilon等，如下：
　　在上图中共有十款GC收集器，它们可以根据回收时的属性分为分代和分区两种类型：分代收集器：Serial、ParNew、Parallel Scavenge、CMS、Serial Old（MSC）、Parallel Old分区收集器：G1、ZGC、Shenandoah
　　其中Epsilon是个例外，这款收集器是JDK11提供的，这款GC收集器俗称为＂废物收集器＂，装载该收集器的Java程序，在运行期间不会发生任何GC相关的操作，程序所分配的堆空间一旦用完，Java程序就会因OOM原因退出。Epsilon收集器主要是用于程序上线前做测试使用，如：性能测试、内存压力测试、VM接口测试等。在程序启动时选择装载Epsilon收集器，这样可以帮助我们过滤掉GC机制引起的性能假象。
　　而本篇重点是叙述分代GC，所以重点先分析一下分代收集器。六款分代收集器，它们分别作用于不同的区域：新生代收集器：Serial、ParNew、Parallel Scavenge年老代收集器：CMS、Serial Old（MSC）、Parallel Old
　　如上图所示，两者之间存在连线则代表两个GC收集器可以搭配使用，所以一共存在六种搭配方案：
　　新生代
　　年老代
　　Serial
　　CMS（主用）/Serial Old（备用）
　　Serial
　　Serial Old（MSC）
　　ParNew
　　CMS（主用）/Serial Old（备用）
　　ParNew
　　Serial Old（MSC）
　　Parallel Scavenge
　　Serial Old（MSC）
　　Parallel Scavenge
　　Parallel Old
　　在上表中，可以看到CMS是可以和MSC搭配的，关于具体为何我们后续分析，也包括为什么Parallel Scavenge不能和CMS进行搭配，后续分析完GC收集器实现后再阐述。二、分代GC收集器详解
　　JVM中的分代GC收集器，除开被划分为新生代和年老代外，也会根据其收集过程，分为单线程和多线程属性的收集器。其中Serial、Serial Old（MSC）属于单线程的收集器，而ParNew、Parallel Scavenge、CMS、Parallel Old则属于并发型的多线程收集器。但接下来我们会从分代角度出发，对GC收集器进行全面阐述。2.1、新生代GC收集器详解
　　前面提到过新生代收集器主要包含Serial、ParNew、Parallel Scavenge，首先来看看作用于新生代的Serial收集器。2.1.1、Serial收集器（单线程）
　　Serial是最原始的新生代收集器，同时它属于单线程的GC收集器，所以也被称为串行收集器。顾名思义，它在执行GC工作时，是以单线程运行的，并且该收集器在发生GC时，会产生STW，也就是会停止所有用户线程。但正由于会停止其他用户线程，所以在执行GC时并不会出现线程间的切换。因此，在单颗CPU的机器上，它的清理效率非常高。一般来说，采用Client模式运行的JVM，选取该款收集器作为内嵌GC是个不错的选择。
　　Serial收集器小结：
　　启动参数：-XX:+UseSerialGC（开启该参数后，年老代会使用MSC）。
　　收集动作：串行GC，单线程。
　　采用算法：复制算法。
　　STW：GC过程在STW中执行。
　　GC发生时，执行过程如下：
　　因为该款收集器GC过程中是需要全程发生在STW中的，所以基于系统层面来说，对用户体验感欠佳。就好比你在线看片（指电影），看两分钟转几圈，看一段时间后又看圈，反反复复的卡顿....，对于你而言，这显然一件令人难以接受的事情。2.1.2、ParNew收集器（多线程）
　　ParNew收集器是基于Serial收集器的演进版，从严格意义上来看，它可以被称为Serial收集器的多线程版本，同样是作用于新生代区域的收集器。在整个实现上，除开GC收集阶段会使用多条线程回收外，其他实现几乎与Serial收集器大致相同。
　　ParNew收集器小结：
　　启动参数：-XX:+UseParNewGC。
　　收集动作：并行GC，多线程。
　　采用算法：复制算法。
　　STW：GC过程发生在STW中，采用多线程回收。
　　GC发生时，执行过程如下：
　　因为该款收集器与Serial唯一的不同点就在于使用了多线程，所以GC发生时仍旧会造成程序停顿。但也因为使用了多线程回收，因此能够在很大程度上缩短系统的停顿时间，从而能够带来比Serial更好的用户体验。
　　但该款GC收集器因为采用了多线程，所以需要多核CPU的支持，该收集器会根据CPU核数，开启不同的GC线程数，从而达到最优的垃圾回收效果（也可以通过-XX:ParallelGCThreads参数指定）。但如若是单核的机器上运行时，其效率可能还不如Serial。
　　一般如果你的程序是以Server模式运行的程序，而老年代又采用了CMS收集器，那么新生代搭配ParNew是个不错的选择。2.1.3、Parallel Scavenge收集器（多线程）
　　Parallel Scavenge同样是一款作用于新生代的多线程GC收集器，但与ParNew收集器不同的是：ParNew通过控制GC线程数量来缩短程序暂停时间，更关心程序的响应时间，而Parallel Scavenge更关心的是程序运行的吞吐量，也就是更注重一段时间内，用户代码执行时长与程序执行总时长的占比。
　　Parallel Scavenge收集器小结：
　　启动参数：-XX:+UseParallelGC。
　　收集动作：并行GC，多线程。
　　采用算法：复制算法。
　　STW：GC过程发生在STW中，采用多线程回收。
　　GC发生时，执行过程如下：
　　从上述小结来看，PS收集器和ParNew收集器好像并未有太大的区别。但实际上它们两者之间基于的底层GC框架完全不同，同时关注的方向也完全不同。PS收集器的目标是让程序达到一个可控制的吞吐量（Throughput），所以PS也被称为吞吐量优先的垃圾收集器。
　　PS收集器可以通过-XX:MaxGCPauseMillis与-XX:GCTimeRatio参数精准控制GC发生时的时间以及吞吐量占比。同时与ParNew收集器最大的不同在于：PS收集器还可以通过开启-XX:+UseAdaptiveSizePolicy参数，让JVM启动自适应的GC调节策略，开启该参数后，JVM会根据当前系统的运行状态调整吞吐比与GC时间，从而确保能够提供最合适的停顿时间和吞吐量。那如果使用PS收集器的时候，我们通过参数手动将GC时间设的很小，然后将吞吐占比设的很高，岂不是GC回收会变得非常完美？答案是：并非如此。因为在追求响应时间的时候必然会牺牲吞吐量，而追求吞吐量的同时必然会牺牲响应时间。好比你通过参数将GC时间设置的很小，那么PS在运行时会将新生代空间调小，如从原本的1GB调整到800MB，收集800MB的空间必然速度会比1GB的快很多。但与之相对应的收集频率会增高，可能原本原来60s收集一次，每次收集停顿100ms，而现如今内存被调小后，40s就要发生一次GC，每次GC停顿80ms，你可以对比这两者之间的区别：24min/1GB空间-GC开销：(24min/60s)*100ms=24000ms24min/800MB空间-GC开销：(24min/40s)*80ms=28800ms因此，最终可以得到一个结果，虽然响应时间确实降低了，但吞吐量也降了下来了。
　　所以一般线上情况，对于调优没有丰富经验的情况下，我们不应该自己去手动调整这些参数，而是开启JVM的自适应策略，由JVM自行调整。2.2、年老代GC收集器详解
　　年老代收集器主要有CMS、Serial Old（MSC）、Parallel Old三款，与新生代的收集器一样，同样存在单线程和多线程收集器之分，接下来我们对年老代收集器进行依次分析。2.2.1、Serial Old（MSC）收集器（单线程）
　　Serial Old（MSC）与Serial收集器相同，同样是一款单线程串行回收的收集器，但不同的是：MSC是一款作用于年老代空间的收集器，它采用标记-整理算法对年老代空间进行回收。同时，该款收集器也可作为CMS的备用收集器使用。
　　Serial Old（MSC）收集器小结：
　　启动参数：-XX:+UseSerialGC（开启该参数后，新生代会使用Serial）。
　　收集动作：串行GC，单线程。
　　采用算法：标记-整理算法。
　　STW：GC过程发生在STW中，采用单线程执行串行回收。
　　GC发生时，执行过程如下：
　　Serial Old（MSC）与新生代收集器Serial差距不大，回收过程也是采用单线程做串行收集，属于Serial的年老代版本。2.2.2、Parallel Old收集器（多线程）
　　Parallel Old则是Parallel Scavenge收集器的年老代版本，同样采用多线程进行并行收集，其内部采用标记-整理算法。与新生代的PS收集器相同的是：PO同样追求的是吞吐量优先。
　　Parallel Old收集器小结：
　　启动参数：-XX:+UseParallelOldGC。
　　收集动作：并行GC，多线程。
　　采用算法：标记-整理算法。
　　STW：GC过程发生在STW中，采用多线程回收。
　　GC发生时，执行过程如下：
　　PO作为PS收集器的年老代版本，其特性与PS大致相同，所以该款收集器同样适用于注重吞吐量或对CPU资源敏感的系统。2.2.3、CMS收集器（多线程/并发）
　　CMS收集器全称为ConcurrentMarkSweep，该款回收器是GC机制中的一座里程碑，在该款收集器中首次实现了并发收集的概念，也就是不停止用户线程，GC线程与用户线程一同工作的情况。同时该款收集器追求的是最短的回收时间，属于多线程收集器，其内部采用标记-清除算法。
　　CMS收集器小结：
　　启动参数：-XX:+UseConcMarkSweepGC。
　　收集动作：并发GC，多线程并行执行。
　　采用算法：标记-清除算法。
　　STW：GC过程会发生STW，但并非整个GC过程都在STW中执行，采用多线程回收。
　　GC发生时，执行过程如下：
　　从上面的CMS执行图中可以明确看出，CMS对比其他的GC收集器，回收过程明显复杂很多，CMS收集器的回收工作会分为四个步骤：初始标记、并发标记、重新标记以及并发清除。①初始标记：仅标记GcRoot节点直接关联的对象，该阶段速度会很快，需在STW中进行。②并发标记：该阶段主要是做GC溯源工作（GcTracing），从根节点出发，对整个堆空间进行可达性分析，找出所有存活对象，该阶段的GC线程会与用户线程同时执行。③重新标记：这个阶段主要是为了修正＂并发标记＂阶段由于用户线程执行造成的GC标记变动的那部分对象，该阶段需要在STW中执行，并且该阶段的停顿时间会比初始阶段要长不少。④并发清除：在该阶段主要是对存活对象之外的垃圾对象进行清除，该阶段不需要停止用户线程，是并发执行的。PS：其实在并发标记和重新标记中间存在两步细节操作：预清理以及可终止的预清理。
　　在整个收集过程中，除开初始标记与重新标记阶段，其他的收集动作都是与用户线程并发执行的。因此，CMS收集器在发生GC时，造成的程序暂停是非常短暂的，对于用户体验感而言，相对比之前的收集器而言是最优者。也正由于CMS收集器并发收集、停顿延迟低的特性，所以在有些地方也被称为并发低停顿收集器。
　　从如上的总结看来，CMS好像很不错哎~，但实际上，CMS也存在几个致命的缺点：会产生且无法回收浮动垃圾、对CPU资源非常依赖、GC完成后会造成大量内存碎片。①CMS是一款完全基于多线程环境研发的收集器，默认情况下，回收过程中开启的线程数为(CPU核数+3)/4，也就代表着：一台八核的机器至少要开启2~3条GC线程。而当CPU核数少于4时，CMS的GC线程则会对用户线程性能造成很大影响，因为需要让出一半的CPU运算资源去执行GC回收工作。②由于CMS收集器的回收工作是并发清除垃圾对象的，因此，在清除阶段用户线程依旧在执行，而用户线程执行就必然会造成新的垃圾产生，但这部分新产生的垃圾对象是无法标记的，所以只能等到下次GC发生时才可回收，而这部分垃圾则被称为＂浮动垃圾＂。③因为CMS采用的是标记-清除算法，所以在回收工作结束之后会造成大量的内存碎片。 为何不采用标-整算法呢？因为CMS是并发执行的，所以如果将存活对象压缩到内存一端，那么用户线程中的所有对象引用都需改变，实现起来及其复杂且影响效率。
　　因为CMS在回收时会产生浮动垃圾以及内存碎片，所以CMS一般来说都必须要要搭配一款其他的收集器作为后备方案，而可选项有且只有一个：那就是Serial Old（MSC），当内存太过碎片化导致无法分配新对象时，或回收一次后存活对象+浮动垃圾占比达到指定阈值时则会触发Serial Old（MSC）收集器回收。
　　决定着是否触发Serial Old（MSC）的关键参数有三个：-XX:CMSInitIatingOccupancyFaction：需要指定一个百分比，当存活对象+浮动垃圾占比达到该值时会触发MSC工作。XX:UseCMSCompactAtFullCollection：该参数默认开启，当内存太过碎片化导致无法分配新对象时，触发MSC发生FullGC。XX:CMSFullGCsBeforeCompaction：该参数可以设置间隔多少次FullGC后发生一次整理内存碎片的FullGC（MSC的GC），默认为0，既每次FullGC都会触发MSC回收。2.3、分代GC收集器总结
　　就目前而言，分析过的GC收集器中，根据分代特征，可分为新生代、年老代收集器。基于线程角度出发，则可分为单线程串行、多线程并行收集器。而从关注度来看，又可分为吞吐量优先、响应时间优先两大类。
　　一般而言，如果你的程序是更为关注用户体验度，那么可以采用响应速度优先的收集器工作，因为该类收集器造成的程序暂停不会很久。但如若你的程序不需要与用户有特别多的交互，如批量处理、订单处理、报表计算、科学计算等类型的后台系统，那你则可以采用吞吐量优先的收集器，因为高吞吐量可以高效率地利用CPU资源。三、收集器组合方案、CMS三色标记与跨代引用3.1、GC组合方案分析
　　在第二个段落中，我们详细分析了JVM中每款不同的GC收集器，但在实际开发过程中，我们的程序采用哪个组合更好呢？其实并不存在所谓的最好组合，你要选择那套组合作为Java程序的收集器，更多的需根据具体的业务场景来决定。
　　如果你的程序追求低延迟，用户交互度较为频繁，那你可以采用ParNew + CMS组合（这也是淘宝早期的选择，但后面采用了自研JVM）。
　　如若你的程序追求高吞吐，后台计算工作较多，那么Parallel Scavenge + Parallel Old这组PS+PO的收集器会更适合你。
　　但你的程序写出来后，更多的情况下部署在单核或双核的机器时，那么最经典的Serial + Serial Old组合绝对是你的最佳选择。
　　我们再一次将目光聚集在这张图上，需要值得注意的是：在JDK1.8之前，可以采用虚线组合，但在JDK1.8之后，取消了上图中红线的组合，被视为弃用的收集器组合（但如果要用，也是可以用的）。到了JDK1.9时，红线组合被移除，也就代表着在1.9中无法再指定红线组合作为收集器使用。而到了后面的JDK14时，绿线组合也被弃用，同时官方也移除了CMS收集器，为了给G1铺路，使用G1代替了CMS。3.1.1、为何PS收集器不能和CMS收集器搭配使用？
　　因为在HotSpot中，底层存在一个分代GC的框架，Serial/SerialOld/ParNew/CMS都是基于该框架实现的，而在该框架内的新生代收集器和年老代收集器是可以相互之间搭配使用的，这也是所谓的mix-and-match规则。但PS收集器在实现时，发现原本的分代GC框架并不适用，则最终采用了自己的特殊框架进行了实现，所以PS收集器并不在前面所说的那个分代GC框架中。因此，PS不能跟使用了那个框架的CMS搭配使用。3.2、三色标记算法
　　三色标记算法是自CMS收集器后，应用比较广泛的一种并发标记算法，它可以让JVM在发生GC时，只发生短暂的STW即可实现存活对象标记的一种算法。JVM中的CMS以及后续的不分代收集器，之所以可以做到低延迟的根本原因便在于此处。
　　三色标记思想：在该算法中，将对象分为了黑、白、灰三种颜色，释义如下：
　　黑：已经被标记完成，且依旧存活的对象。
　　灰：当前对象已经被标记完成，但关联节点（属性成员）还未标记的对象。
　　白：未曾标记过的对象，或不具备引用的对象（垃圾对象）。3.2.1、三色标记执行过程
　　废话不多说，先上一张三色标记的执行过程图：
　　实现了三色标记算法的GC收集器，在启动时会分别创建：黑、白、灰三个集合，在最开始所有的对象都在白色集合中。在GC发生时，发生短暂的STW，将所有与GcRoots直接相连的对象转入灰色集合中。之后并发执行，对灰色集合中的对象进行遍历，根据可达性分析算法进行对象存活标记，当一个对象的所有成员全部被标记完成后，该对象则会被移入到黑色集合中。同时，也会将该对象中被标记的成员从白色集合移入灰色集合中。不断重复上一步操作，直至灰色集合彻底没了对象为止。标记完成所有对象后，再次触发STW，通过write-barrier写屏障检测对象是否有变化，如果发生了改变则重新标记，纠正并发标记期间的＂误标＂。并发执行清除工作，将白色集合中的所有对象全部回收（因为根据GCRoots节点进行可达性分析后，所有的存活对象都会从白色集合移入到黑色集合中，所以依旧留在白色集合中的对象必然为垃圾对象，这些对象就是需要被回收的对象）。最终等待清除工作完成后，代表着整个GC过程结束，再把标记复位，将所有的对象再次放入白色集合中，等待迎接下次GC的到来。3.2.2、三色标记-并发标记导致的错标问题
　　采用三色标记算法的GC收集器为了追求低延迟，一般在标记完GCRoots直接关联的对象后，就会结束STW，转而采取并发标记的手段对其他对象进行标记。但因为并发标记是GC线程与用户线程一起工作的，所以很有可能导致出现如下情况：
　　被标记的黑色对象中，突然断开了对另一个对象的引用，导致另外一个原本已经被标记为黑色的对象突然变为了垃圾。
　　但是因为该对象已经被标记了，所以收集器不会对该对象进行再次标记，而等到清除工作发生时，因为当前这个对象在最初是被标记为了黑色，所以收集器也不会回收它。这种情况则被称为三色标记导致的＂错标/误标/多标＂，也被称为并发标记产生的浮动垃圾。
　　对于该问题而言并非什么大事，因为这次错标产生的浮动垃圾，在下次GC时依旧会被回收，正所谓＂躲得过初一，躲不过十五＂，是垃圾早晚都会被＂干掉＂，这点在JVM中是毋庸置疑的，因此这个问题不必太过留意。3.2.3、三色标记-并发执行导致的漏标问题
　　假设在执行三色标记的过程中，出现了如下情况：
　　①一条用户线程在执行过程中，断开了一个未标记的白色对象连接，然后该对象又被一个已经标记成黑色的对象建立起了引用连接。如下图：
　　白色对象断开了左侧灰色对象的引用，又与右侧的黑色对象建立了新的引用关系。
　　②一条用户线程在执行过程中，正好在GC线程标记时，将一个灰色对象与一个未标记的白色对象之间的引用连接断开了，然后当GC标记完成这个灰色对象，将其标记为黑色后，之前断开的白色对象又重新与之建立起了引用关系。如下图：
　　GC标记前，白色对象断开了与灰色对象的引用，四秒钟之后GC标记灰色对象完成，而此时恰巧白色对象又重新与标记结束后成为黑色的对象重新建立了引用关系。
　　而当出现这两种情况时，因为重新建立引用的白色对象＂父节点＂已经被标记黑色了，所以GC线程不会再次标记该对象以及其成员对象，所以这些白色对象会被一直停留在白色集合中。最终导致的结果就是这些依旧存在引用的存活对象会被＂误判＂为垃圾对象清除掉。而这种情况会直接影响到应用程序的正确性，是不可接受的。
　　先来思考一下引起漏标问题的原因：
　　条件一：灰色对象断开了与白色对象的引用（直接引用或间接引用都可）。
　　条件二：已经标为黑色的对象重新与白色对象建立了引用关系。
　　只有当一个对象同时满足了如上两个条件时才可发生漏标问题。
　　上个简单的代码案例理解一下：Object X = obj.fieldX; // 获取obj.fieldX成员对象 obj.fieldX = null; // 将原本obj.fieldX的引用断开 objA.fieldX = X; // 将断开引用的X白色对象与黑色对象objA建立引用 复制代码
　　从如上代码角度来看，假设obj是一个灰色对象，此时先获取它的成员fieldX并将其赋值给变量X，让其堆中实例与变量X保持着引用关系。紧接着再将obj.fieldX置空，断开与obj对象的引用关系，最后再与黑色对象objA建立起引用关系，最终关系如下：
　　灰色对象obj，白色对象obj.fieldX/X，黑色对象objA。
　　白色对象X在GC机制标记灰色对象obj成员属性之前，与灰色对象断开了引用，然后又＂勾搭＂上了黑色对象objA，此刻白色对象X就会被永远停留在白色集合中，直至清除阶段到来，被＂误判＂为垃圾回收掉。
　　其实解决漏标问题的思路也挺简单的，线程安全问题是存在三个必要条件的，破坏掉其中任意条件后，线程安全问题就不会出现。而刚刚前面也分析过，对象漏标的问题也存在两个必要条件，那么我们也只需要破坏掉其中任意条件即可。比如上述案例中，我们只要能够通过特殊手段记录一下X对象，然后将它作为灰色对象再遍历标记一次即可。采用三色标记算法的收集器又是如何具体解决漏标问题的呢？CMS：增量更新 + 写屏障G1：STAB + 写屏障ZGC：读屏障
　　在本篇中，先对CMS解决漏标的方案进行分析，对于G1、ZGC收集器的漏标问题解决则放到下篇文章中进行阐述。3.2.4、CMS解决漏标问题：增量更新 + 写屏障
　　在了解写屏障之前，我们首先来看看HotSpot中为对象成员赋值的实现，大体逻辑如下：void oop_field_store(oop* field, oop new_value) {      *field = new_value; // 赋值操作：新值替换老值 }  复制代码
　　而所谓的写屏障，则是指在赋值操作前后加入一些逻辑处理（类似于SpringAOP面向切面前后置处理的思想），如下：void oop_field_store(oop* field, oop new_value) {     pre_write_barrier(field); // 写前屏障     *field = new_value; // 赋值操作：新值替换老值     post_write_barrier(field, value);  // 写后屏障 }  复制代码
　　而CMS收集器则是通过在写屏障的后置处理中，实现了增量更新的逻辑，从而解决了漏标问题。
　　增量更新（Increment Update）是专门针对于对象新增引用的，当一个未标记的白色对象被其他对象重新引用时，这个白色对象会被记录下来，如下：// 写后屏障 void post_write_barrier(oop* field, oop new_value) {     if($gc_phase == GC_CONCURRENT_MARK && !isMarkd(field)) {       remark_set.add(new_value); // 记录新引用的对象（白色对象）   } } 复制代码
　　从如上源码中可以观察出：对于赋值的新增引用，会在写后屏障中会被放到一个特定的集合记录，等并发标记阶段的GCRoots遍历标记完成后，在重新标记阶段会去找到集合里面的引用，再把源头标记为灰色，然后重新去扫描标记这些对象。
　　CMS通过写屏障+增量更新这种手段，破坏了之前分析漏标问题时的第二个条件：已经标为黑色的对象重新与白色对象建立了引用关系。
　　通过增量更新的手段，会将这些重新建立了引用的＂源头＂再次恢复为灰色对象，然后在重新标记阶段会再次标记，同时为了避免重新标记阶段时再次发生漏标问题，所以重新标记阶段是必须要发生STW的。3.3、跨代引用
　　跨代引用是指年老代空间中的对象引用了新生代的对象，或者新生代中的对象引用了年老代中的对象。面对这种情况，在进行可达性分析扫描存活对象时，不可能从新生代一直扫描至年老代的，因为这样就会出现整堆扫描的情况，效率必然会很低。
　　在HotSpot虚拟机中，为了解决跨代引用的问题，会专门在内存中开辟一块小空间用于维护这些特殊的引用，从而达到让GC不必扫描整个堆空间的目的。而开辟的这块小空间则被称为记忆集、卡表。3.1、记忆集（Remember Set）
　　我们都知道在发生新生代GC时都会通过根可达算法先判断垃圾对象，之后再对非存活对象进行统一回收，但是如果有年老代对象引用了新生代对象，那么根据根可达算法的特性，年老代也会被加入扫描范围，这样下来一次新生代的GC代价太大。所以为了解决跨代引用的问题，在新生代引入了记录集的数据结构，记录从非收集区到收集区的引用指针集合，避免在通过根可达算法判断对象存活时把整个老年代加入扫描范围。
　　GC时，GC收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需进行详细的根搜索过程。
　　记忆集可根据不同的记忆粒度实现：
　　①字宽/字长精度：精确到每个字宽(32bit/64bit)，每一个跨代引用指针
　　②对象精度：精确到每个对象，对象的字段中包含跨代引用指针
　　③卡精度：精准到每一块内存区域，内存区域中有对象存在跨代指针3.2、卡表（Card Table）
　　卡表是记忆集第三种精度的实现，也是HotSpot虚拟机中记忆集的实现方式，卡表中记录中记忆集的记录精度、与堆内存区域的映射关系等。
　　在HotSpot中卡表是使用一个字节数组实现：CARD_TABLE[this addredd >>9]=0，数组中每个元素对应着其标识的内存区域，称为卡页，hotSpot使用的卡页大小为2^9 即512字节，也就是说内存中每连续的512字节会被当作一个卡页作为卡表的一个元素。
　　如果有年老代的对象引用了新生代的对象，那么该新生代对象所在区域对应的卡页元素设置为1，反之则为0。(G1以后的GC收集器不分代，所以G1以后的记忆集不是通过数组实现的，而是通过哈希表结构实现)。
　　JVM对于卡页的维护也是通过写屏障的方式。四、GC日志解读
　　对于GC机制而言，这块区域是程序员做JVM调优的关键，而调优前必然得读懂GC发生后产生的日志。在JVM中GC日志相关的参数如下：①-XX:+PrintGC或-verbose:gc：打印GC日志②-XX:+PrintGCDetails：打印GC的详细日志③-XX:+PrintGCTimeStamps：输出GC的时间戳（以基准时间的形式）④-XX:+PrintGCDateStamps：输出GC的时间戳（以日期的形式）⑤-XX:+PrintHeapAtGC：在发生GC的前后打印出堆的信息⑥-Xloggc:/xxx/xxx/xx.log：GC日志文件的保存路径
　　其中-XX:+PrintGC或-verbose:gc参数只能输出GC时堆空间总体的变化信息，来个简单的案例理解一下：// 启动参数：-Xms8M -Xmx8M -XX:+PrintGC public class GC {     static void newObject(){         for (int i = 0; i <= 10000; i++)             new Object();     }      public static void main(String[] args) throws InterruptedException {         for (;;){             newObject();         }     } } 复制代码
　　执行上述案例后，你的控制台中会得到如下日志：[GC (Allocation Failure)  1527K->868K(7680K), 0.0011957 secs] [GC (Allocation Failure)  1924K->1201K(7680K), 0.0032349 secs] ...... 复制代码
　　我们从输出的日志中随意找出一条来用于分析，如下：
　　[GC[1] (Allocation Failure)[2] 1527K[3]->868K[4](7680K)[5], 0.0011957 secs[6]]
　　该日志只会大概的将堆空间的总体情况打印出来，日志信息解读如下：[1]：此次GC的类型 GC：表示Young GC，新生代发生的GC类型 Full GC：全局GC，新生代、年老代以及元空间的GC类型[2]：此次GC产生的原因 Allocation Failure：新创建的对象分配失败导致的GC Metadata GC Threshold：元空间数据达到分配的空间阈值导致的GC System.gc()：程序中手动通过System.gc()触发的GC ......[3]：GC发生前，堆的已用空间大小[4]：GC发生后，堆的已用空间大小[5]：堆空间的总大小[6]：GC持续的时间
　　如下图：
　　整条GC日志的规律为：GC类型+GC原因+堆空间描述+耗时描述。4.1、GC日志详细信息解读
　　在前面提到过-XX:+PrintGC参数只能输出GC时堆的总体变化信息，这种日志对于线上遇到突发状况而言，几乎是很难从中获取到有用信息的。因此，一般而言线上都会采用-XX:+PrintGCDetails参数获取GC的详细日志信息。案例如下：// 启动参数：-Xms8M -Xmx8M -XX:+PrintGCDetails public class GC {     // 作为GC Roots     static List