Java虚拟机 ----垃圾回收算法与垃圾回收器

     Java语⾔言中⼀个显著的特点就是引⼊入了了垃圾回收机制，使c++程序员最头疼的内存管理理的问题迎刃⽽而解。由于有个垃圾回收机制，Java中的对象不再有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露露，有效的使用空闲的内存。

一、判断对象是否存活

        在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（“死去”即不可能再被任何途径使用的对象）了。  

  主要有两种算法：引用计数法、可达性分析法

1.1、引用计数法

     在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

                                   

 优缺点
    引用计数收集器器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境⽐比较有利。

    无法检测出循环引用。如父对象有⼀一个对⼦子对象的引⽤用，子对象反过来引用⽗父对象。这样，他们的引用计数永远不不可能为0。

1.2 、可达性分析法

      目前主流的商用程序语言（Java、C#）的内存管理子系统，都是通过可达性分析（Reachability Analysis）算法来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

                                     

    如上图所示，对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的，因此它们将会被判定为可回收的对象。

java中可作为GC Root的对象有：

1.   虚拟机栈中引用的对象（本地变量表）
2.   本地方法栈中引用的对象
3.   方法区中静态属性引用的对象
4.   方法区中常量引用的对象

二、垃圾回收算法

 2.1、标记清除（Mark-Sweep）

标记-清除算法（Mark-Sweep）是一种常见的基础垃圾收集算法，它将垃圾收集分为两个阶段：

•    标记阶段：标记出可以回收的对象。
•    清除阶段：回收被标记的对象所占用的空间。

标记-清除算法之所以是基础的，是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。

优点：实现简单，不需要对象进行移动。

缺点：标记、清除过程效率低，产生大量不连续的内存碎片，提高了垃圾回收的频率。

标记-清除算法的执行的过程如下图所示:

           
2.2 复制算法（Copying）

为甚么出现复制算法？

     为了解决效率问题，⼀种称为“复制”（Copying）的收集算法出现了，它将可用内存按量划分为大小相等的两块，每次只使用其中的⼀块。

   当这⼀块的内存用完了，就将还存活着的对象复制到另外⼀块上面，然后再把已使用过的内存空间⼀次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

优点：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。

缺点：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

         

    现在的商业虚拟机都采用这种收集算法来回收新生代，研究表明，新生代中的对象 98%是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为⼀块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中⼀块 Survivor。 Survivor from 和Survivor to，内存⽐比例例 8：1：1。

   当回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。 HotSpot 默认 Eden 和 Survivor 的大小比例是 8:1，也就是每次新生代中可用的内存为整个新生代容量的 90%（80%+10%），只有 10% 会被浪费。当然，98% 的对象可回收只是一般场景下的数据，我们没办法保证每次回收后都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其它内存（这里指老年代）进行分配担保（Handle Promotion）。如果另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来存活的对象时，这些对象将直接通过分配担保机制进入老年代。

2.3 标记--整理算法（MARK-COMPACT）

标记整理算法解决了了什么问题?
    复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更更关键的是，如果不想浪费 50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100%存活的极端情况，所以在老年代⼀般不能直接选用这种算法
标记-整理算法
   根据老年年代的特点，有人提出了另外⼀种“标记-整理（Mark- Compact）算法，标记过程仍然与“标记-清除”算法⼀样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向⼀端移动，然后直接清理掉端边界以外的内存。   

优点：解决了标记-清理算法存在的内存碎片问题。

缺点：仍需要进行局部对象移动，一定程度上降低了效率。

标记-整理算法的执行过程如下图所示

           

        是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更复杂。从垃圾收集的停顿时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，但是从整个程序的吞吐量来看，移动对象会更划算。此语境中，吞吐量的实质是赋值器与收集器的效率总和。即使不移动对象会使得收集器的效率提升一些，但因内存分配和访问相比垃圾收集频率要高得多，这部分的耗时增加，总吞吐量仍然是下降的。HotSpot虚拟机里面关注吞吐量的ParallelScavenge OLD收集器是基于标记-整理算法的，而关注延迟的CMS收集器则是基于标记-清除算法的，这也从侧面印证这点。
         另外，还有一种“和稀泥式”解决方案可以不在内存分配和访问上增加太大额外负担，做法是让虚拟机平时多数时间都采用标记-清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记-整理算法收集一次，以获得规整的内存空间。前面提到的基于标记-清除算法的CMS收集器面临空间碎片过多时采用的就是这种处理办法。

2.4、分代收集算法

     当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法，顾名思义是根据对象的存活周期将内存划分为几块。一般包括年轻代、老年代 和 永久代，如图所示：

         

2.4.1、新生代（Young generation）

       绝大多数最新被创建的对象会被分配到这里，由于大部分对象在创建后会很快变得不可达，所以很多对象被创建在新生代，然后消失。对象从这个区域消失的过程我们称之为 minor GC。

     新生代 中存在一个Eden区和两个Survivor区。新对象会首先分配在Eden中（如果新对象过大，会直接分配在老年代中）。在GC中，Eden中的对象会被移动到Survivor中，直至对象满足一定的年纪（定义为熬过GC的次数），会被移动到老年代。

      可以设置新生代和老年代的相对大小。这种方式的优点是新生代大小会随着整个堆大小动态扩展。参数 -XX:NewRatio 设置老年代与新生代的比例。例如 -XX:NewRatio=8 指定 老年代/新生代 为8/1. 老年代 占堆大小的 7/8 ，新生代 占堆大小的 1/8（默认即是 1/8）。

例如：

-XX:NewSize=64m -XX:MaxNewSize=1024m -XX:NewRatio=8

2.4.2、老年代（Old generation）

    对象没有变得不可达，并且从新生代中存活下来，会被拷贝到这里。其所占用的空间要比新生代多。也正由于其相对较大的空间，发生在老年代上的GC要比新生代要少得多。对象从老年代中消失的过程，可以称之为major GC（或者full GC）。

2.4.3、永久代（permanent generation）

      像一些类的层级信息，方法数据 和方法信息（如字节码，栈 和 变量大小），运行时常量池（JDK7之后移出永久代），已确定的符号引用和虚方法表等等。它们几乎都是静态的并且很少被卸载和回收，在JDK8之前的HotSpot虚拟机中，类的这些**“永久的”** 数据存放在一个叫做永久代的区域。

   永久代一段连续的内存空间，我们在JVM启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小。但是JDK8之后取消了永久代，这些元数据被移到了一个与堆不相连的称为元空间 (Metaspace) 的本地内存区域。

小结
        当执行一次Minor GC时，Eden空间的存活对象会被复制到To Survivor空间，并且之前经过一次Minor GC并在From Survivor空间存活的仍年轻的对象也会复制到To Survivor空间。
     有两种情况Eden空间和From Survivor空间存活的对象不会复制到To Survivor空间，而是晋升到老年代。一种是存活的对象的分代年龄超过-XX:MaxTenuringThreshold（用于控制对象经历多少次Minor GC才晋升到老年代）所指定的阈值。另一种是To Survivor空间容量达到阈值。

       JDK8堆内存一般是划分为年轻代和老年代，不同年代 根据自身特性采用不同的垃圾收集算法。

      对于新生代，每次GC时都有大量的对象死亡，只有少量对象存活。考虑到复制成本低，适合采用复制算法。因此有了From Survivor和To Survivor区域。

      对于老年代，因为对象存活率高，没有额外的内存空间对它进行担保。因而适合采用标记-清理算法和标记-整理算法进行回收。

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。垃圾回收有两种类型，Minor GC 和 Full GC。

       Minor GC：新生代垃圾收集。对新生代进行回收，不会影响到年老代。因为新生代的 Java 对象大多死亡频繁，所以 Minor GC 非常频繁，一般在这里使用速度快、效率高的算法，使垃圾回收能尽快完成。
       Full GC：也叫 Major GC，对整个堆进行回收，包括新生代和老年代（JDK8 取消永久代）。由于Full GC需要对整个堆进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。它的收集频率较低，耗时较长。

      

三、HotSpot的算法实现

3.1、枚举根节点

• 可达性分析枚举GC Roots时 ，必须stop the world
• 目前JVM使用准确式GC，停顿时并不需要一个个检查，而是从预先存放的地方直接取。（HotSpot保存在OopMap数据结构中）

3.2 、安全点

      在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本就会变得无法忍受的高昂。

    实际上HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint）。有了安全点的设定，也就决定了用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。

    如何在垃圾收集发生时让所有线程（这里其实不包括执行JNI调用的线程）都跑到最近的安全点，然后停顿下来。这里有两种方案可供选择：抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension）。

3.2.1 抢先式中断

    抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

3.2.2  主动式中断

     主动式中断：线程轮询安全点标识，然后挂起

    垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的.

3.3、安全区域

          程序“不执行”的时候呢？所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间。对于这种情况，就必须引入安全区域（Safe Region）来解决。

        当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那线程就当作没事发生过，继续执行；否则它就必须一直等待，直到收到可以 离开安全区域的信号为止。

四 jvm垃圾回收器

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器

                    

       在 JVM 中，具体实现有 Serial、ParNew、Parallel Scavenge、CMS、Serial Old（MSC）、Parallel Old、G1 等。在上图你可以看到 不同垃圾回收器 适合于不同的内存区域，如果两个垃圾回收器之间 存在连线，那么表示两者可以 配合使用。

      如果当 垃圾回收器 进行垃圾清理时，必须 暂停 其他所有的工作线程，直到它完全收集结束。我们称这种需要暂停工作线程才能进行清理的策略为 Stop-the-World（STW）。

    图中有 7 种不同的 垃圾回收器，它们分别用于不同分代的垃圾回收。

•  年轻代回收器：Serial 、PerNew、Parallel([ˈpærəlel] ) Scavenge([ˈskævɪndʒ]  清除)
• 老年代回收器：Serial Old 、CMS 、Parallel Old.
• 整堆回收器：G1 

   一般三种搭配 1、Serial 和 Serial Old  2、PerNew和CMS 3、Parallel Scavenge和Parallel Old（JDK8默认的） 

  垃圾收集器跟内存大小的关系

1. Serial 几十兆

2. PS 上百兆 - 几个G

3. CMS - 20G

4. G1 - 上百G

5. ZGC - 4T - 16T（JDK13）

几个相关概念：

并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。

并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

4.1、单线程垃圾回收器

   应用场景：适用于Client模式下的虚拟机。

   4.1.1 Serial

     Serial 回收器是最基本的新生代垃圾回收器，是 单线程的垃圾回收器。由于垃圾清理时，Serial 回收器不存 线程间的切换，因此，特别是在单CPU的环境下，它的 垃圾清除效率 比较高。对于 Client 运行模式的程序，选择 Serial 回收器是一个不错的选择。

Serial 新生代回收器 采用的是 复制算法。

4.1.2、Serial Old（-XX:+UseSerialGC）

     Serial Old 回收器是Serial 回收器的老生代版本，属于单线程回收器，它使用 标记-整理 算法。对于 Server 模式下的虚拟机，在 JDK1.5 及其以前，它常与 Parallel Scavenge 回收器配合使用，达到较好的吞吐量，另外它也是CMS 回收器在 Concurrent Mode Failure 时的 后备方案。

Serial Old 老年代回收器 采用的是 标记 - 整理算法。

Serial 回收器和 Serial Old 回收器的执行效果如下：

                    

4.2 多线程垃圾回收器(吞吐量优先)

   指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。

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

     ParNew 回收器是在 Serial 回收器的基础上演化而来的，属于 Serial 回收器的 多线程版本，同样运行在 新生代区域。在实现上，两者共用很多代码。在不同运行环境下，根据 CPU 核数，开启 不同的线程数，从而达到 最优 的垃圾回收效果。对于那些 Server 模式的应用程序，如果考虑采用 CMS 作为 老生代回收器 时，ParNew 回收器是一个不错的选择。
    除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。

   特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，

            可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。和Serial收集器一样存在Stop The World问题

    应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

   -XX:+UseParNewGC = ParNew + SerialOld 

                     

4.2.2 Parallel Scavenge (-XX:+UseParallelGC)

与吞吐量关系密切，故也称为吞吐量优先收集器。

特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。

          该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：

• -XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间。这个参数配置太小的话会发
  生频繁GC。

• -XX:GCRatio 直接设置吞吐量的大小。

4.2.3、Parallel Old（-XX:+UseParallelOldGC）

   Parallel Old 回收器是 Parallel Scavenge 回收器的 老生代版本，属于 多线程回收器，采用 标记-整理算法。Parallel Old 回收器和 Parallel Scavenge 回收器同样考虑了 吞吐量优先 这一指标，非常适合那些 注重吞吐量 和 CPU 资源敏感 的场合。

特点：用于老年代、多线程，采用标记-整理算法。

应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

Parallel Scavenge/Parallel Old收集器工作过程图：

       

4.3 并发收集器 停顿时间优先(响应时间)

4.3.1 CMS（-XX:+UseConcMarkSweepGC）

CMS（Concurrent Mark Sweep）回收器是在最短回收停顿时间为前提的回收器，属于多线程回收器，采用标记-清除算法。

特点：基于标记-清除算法实现。并发收集、低停顿。

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。

相比之前的回收器，CMS 回收器的运作过程比较复杂，分为四步：

初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。

并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。

重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。

并发清除：对标记的对象进行清除回收。

 CMS收集器的内存回收过程是与用户线程一起并发执行的。

 CMS收集器的工作过程图：

                 

 

       初始标记（CMS initial mark）和 重新标记（CMS remark）会导致 用户线程 卡顿，Stop the World 现象发生。

 

CMS收集器的缺点：

• 对CPU资源非常敏感。

        CMS回收器过分依赖于 多线程环境，默认情况下，开启的 线程数 为（CPU 的数量 + 3）/ 4，当 CPU 数量少于 4 个时，CMS 对 用户查询 的影响将会很大，因为他们要分出一半的运算能力去 执行回收器线程；

• 无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。
• 因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。

4.4 G1回收器（垃圾区域Region优先）

  G1 是 JDK 1.7 中正式投入使用的用于取代 CMS 的 压缩回收器。它虽然没有在物理上隔断 新生代 与 老生代，但是仍然属于 分代垃圾回收器。G1 仍然会区分 年轻代 与 老年代，年轻代依然分有 Eden 区与 Survivor 区。

    G1 首先将 堆 分为 大小相等 的 Region，避免 全区域 的垃圾回收。然后追踪每个 Region 垃圾 堆积的价值大小，在后台维护一个 优先列表，根据允许的回收时间优先回收价值最大的 Region。同时 G1采用 Remembered Set 来存放 Region 之间的 对象引用 ，其他回收器中的 新生代 与 老年代 之间的对象引用，从而避免 全堆扫描。G1 的分区示例如下图所示：

                

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

特点如下：

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

     分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

     空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。

     可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1为什么能建立可预测的停顿时间模型？

   因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

G1与其他收集器的区别：

       其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

G1收集器存在的问题：

       Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。

G1收集器是如何解决上述问题的？

       采用Remembered Set来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

如果不计算维护 Remembered Set 的操作，G1收集器大致可分为如下步骤：

初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

最终标记：为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set  Logs里面，把Remembered Set  Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

                 

五、 内存分配与回收策略

        对象的内存分配通常是在 Java 堆上分配（随着虚拟机优化技术的诞生，某些场景下也会在栈上分配，后面会详细介绍），对象主要分配在新生代的 Eden 区，如果启动了本地线程缓冲，将按照线程优先在 TLAB 上分配。少数情况下也会直接在老年代上分配。总的来说分配规则不是百分百固定的，其细节取决于哪一种垃圾收集器组合以及虚拟机相关参数有关，但是虚拟机对于内存的分配还是会遵循以下几种规则：

5.1 对象优先在Eden分配

      HotSpot虚拟机提供了-XX：+PrintGCDetails这个收集器日志参数。

      多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存。

这里我们提到 Minor GC，如果你仔细观察过 GC 日常，通常我们还能从日志中发现 Major GC/Full GC。

• Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频繁，一般回收速度也非常快
• Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。

5.2 大对象直接进入老年代

   对象就是指需要大量连续内存空间的Java对象，最典型的大对象便是那种很长的字符串，或者元素数量很庞大的数组。

    HotSpot虚拟机提供了-XX:PretenureSizeThreshold=参数，指定大于该设置值的对象直接在老年代分配，这样做的目的就是避免在Eden区及两个Survivor区之间来回复制，产生大量的内存复制操作。

5.3 长期存活对象将进入老年代

          可以通过参数-XX:MaxTenuringThreshold设置

        虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15 cms g1是6） 就会被晋升到老年代。

5.4 动态对象年龄判定

      为了更好的适应不同程序的内存情况，虚拟机并不是永远要求对象的年龄必需达到某个固定的值（比如前面说的 15）才会被晋升到老年代，而是会去动态的判断对象年龄。如果在 Survivor 区中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于等于该年龄的对象就可以直接进入老年代。

5.5 空间分配担保

       在新生代触发 Minor GC 后，如果 Survivor 中任然有大量的对象存活就需要老年队来进行分配担保，让 Survivor 区中无法容纳的对象直接进入到老年代。