JVM 垃圾收集器--《深入理解Java虚拟机》笔记

JVM 垃圾收集器–《深入理解Java虚拟机》笔记

理解Java垃圾收集器，应该从三个方面去理解：

• 哪些内存是垃圾，需要回收，即哪些内存需要回收
• 这些垃圾应该在什么时候回收会比较合适，即什么时候回收；
• 该怎么样去回收这部分内存，即如何回收。

哪些内存需要回收？

我们知道，JVM的内存在运行时的区域分布如下图：

其中程序计数器、虚拟机栈、本地方法栈3个区域都是属于线程私有的，其所占内存随线程而生，随线程而灭。这几个区域的内存分配和回收都具有确定性，在这几个区域内不需要过多的考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟者回收了。
而Java堆和方法区则不一样，一个接口种的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的也是这部分内存。

##什么时候回收？
什么时候回收，当然是在对象不再被使用时，可以理解为对象“已死”。那么怎么判断对象是处于“存活”还是“已死”呢？

对象是否存活判定算法

• 引用计数算法

给每个对象设置一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。这个算法效率很高，计数器值为0的对象必为“已死”的对象不难理解，但是计数器的值不为0的对象难道就一定是“存活”的对象吗？如果对象间相互引用的时候呢？比如A引用B，B引用A，两个对象的计数器都不为0。但是除了A或者B之外，再无任何引用，实际上这两个对象已经不能再被访问，但是由于它们互相引用，导致计数器值不为0，于是引用计数法无法通知GC收集器回收它们。
实际上JVM并不是使用引用计数法来判断对象是否存活。如下面的代码：

public class ReferenceEachOther {
    public Object instance = null;

    private static final int _1MB = 1024*1024;
    /**
     * 这个成员属性唯一的意义就是占点内存，以便能在GC日志中看清楚是否被回收过
     */
    private byte[] bigSize = new byte[10 * _1MB];

    public static void main(String[] args) {

        ReferenceEachOther objA = new ReferenceEachOther();
        ReferenceEachOther objB = new ReferenceEachOther();
        objA.instance = objB;
        objB.instance = objA;

        objA = null;
        objB = null;
        //假设在这行发生GC，objA和objB是否能够被回收？
        System.gc();
    }
}

通过添加VM参数-XX:+PrintGCDetails打开GC日志的打印，上面代码运行结果如下：

由打印出来的日志可以看出，通过GC之后新生代内存(PSYoungGen)“23810K->518K(38400K)”和堆内存“23810K->526K(125952K)”都减少了，意味着JVM并没有因为这两个对象互相引用就不回收它们。

• 可达性分析算法

在主流的商用程序语言的主流实现中都是称通过可达性分析(Reachability Analysis)来判定对象是否存活的。
算法的基本思想：通过一系列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链(Reference Chain)，当一个对象GC Root没有任何引用链相连时，则证明此对象时不可用的。过程如下图：

上图中Object 5和Object 6虽然有引用，但是它们到GC Roots是不可达的，所以它们将会被判定为可回收的对象。显然，GC Roots就会很重要，那么哪些对象属于GC Roots：

• 虚拟机栈(栈帧中的本地变量表)中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI(Native方法)引用的对象

对象引用类型

引用的定义：如果Reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。上面所说的只要对象是可达的，那么就不会回收其内存，但是那是针对强引用的，其他引用会有所不同。Java将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)4种，这4种引用强度一次逐渐减弱，下面一一介绍：

• 强引用：指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
• 软引用：用来描述一些还有用但并非必须的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2提供了SoftRefernce类来实现软引用。
• 弱引用：用来描述非必须的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉指被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用： 也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

对象生存还是死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：
如果对象在可达性分析后发现没用与GC Roots相连接的引用链，那它将会被第一次标记且进行一次筛选，筛选的条件是此对象是否有必要进行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，也就不会有第二次标记过程。
如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环等，将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己–只要重新与引用链上的任何一个对象建立关联即可，譬如把自己(this关键字)赋给某个类变量或者对象成员变量，那在第二次标记时它将被移除“即将回收”集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。
如下面的代码：

public class EscapeGCByFinalize {

    private static EscapeGCByFinalize SAVE_HOOK = null;

    public void iAlive() {
        System.out.println("Alive");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed!");
        //将对象赋给类变量
        EscapeGCByFinalize.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable {
        SAVE_HOOK = new EscapeGCByFinalize();
        //对象第一次拯救自己
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，这里暂停1秒
        Thread.sleep(1000);
        if(SAVE_HOOK != null) {
            SAVE_HOOK.iAlive();
        }
        else {
            System.out.println("Dead");
        }

        //下面这段代码与上面的完全相同，但是这次自救却失败了，因为finalize方法已经被虚拟机调用过了
        SAVE_HOOK = null;
        System.gc();
        //因为finalize方法优先级很低，这里暂停1秒
        Thread.sleep(1000);
        if(SAVE_HOOK != null) {
            SAVE_HOOK.iAlive();
        }
        else {
            System.out.println("Dead");
        }
    }
}

执行结果：

从执行结果看到，SAVE_HOOK对象的finalize方法确实被GC收集器触发过，并且在被收集前成功逃脱了。另外一个值得注意的地方是，代码中有两段完全一样的代码片段，执行结果却是一次逃脱，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此第二阶段代码的自救行动失败了。

方法区回收

方法区亦成为永久代(HotSpot虚拟机中)，在永久代中进行垃圾收集“性价比”一般比较低，在永久代中垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。比如一个字符串“abc”，如果当前系统中没有任何一个String对象叫做“abc”的，即没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中其他类(接口)、方法、字段的符号引用也与此类似。
判定一个常量是否是“废弃常量”比较简单，但是要判断一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足以下3个条件才能算是“无用的类”：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
• 加载该类的ClassLoader已经被回收；
• 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法；

虚拟机可以对满足上述3个条件的无用类进行回收，这里说仅仅是“可以”，而并不是和对象一样，不使用就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息，其中-verbose:class和-XX:+TraceClassLoading可以在product版虚拟机中使用，-XX:+TraceClassUnLoading参数需要FastDebug版的虚拟机支持(这个没用过)。
在大量使用发射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

如何回收？

垃圾收集算法，书中介绍了四种：

• 标记-清除算法

标记-清除(Mark-Sweep)算法为最基础的算法，分为标记和清除两个阶段：
标记–首先标记出所有需要回收的对象；
清楚–标记完成之后统一回收所有被标记的对象；
整个过程可以用下图表示：

算法原理很好理解，这个算法有两个不足的地方：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清楚之后会产生大量不不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。后续的算法都是基于这种思路对其不足进行改进而得到的，因此这个算法为基础算法。

• 复制算法
  相对于标记-清除算法，复制算法的出现是为了解决效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的空间一次清理掉。复制算法的过程如下图：
  

复制算法实现简单，运行高效，但是代价有点高，将内存缩小为了原来的一半。因此这种算法对新生代对象比较实用，IBM公司研究表明，新生代中的对象98%是“朝生夕死”的，所以不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survior空间，每次使用Eden和其中一块Survior空间。当回收时，将Eden空间和Survior中还存活的对象一次性的复制到另外一个Survior空间上，最后清理掉Eden和刚才用过的Survior空间。HotSpot虚拟机默认Eden和Survior的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%，只有10%的内存会被“浪费”。当然，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survior空间不够用时，需要依赖其他内存(如老年代)进行分配担保(Handle Promotion).

• 标记-整理算法
  复制收集算法在对象存活率较高时就要进行较多的复制操作，效率会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以老年代一般不能直接选用这种算法。
  标记-整理算法是一种应用于老年代中的垃圾回收算法，标记过程仍然与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存，过程如下图：
  

• 分代收集算法
  当前商业虚拟机的垃圾收集都是采用“分代收集”(Generational Collection)算法，这种算法并没有什么新的思想，只是根据对象存活的周期的不同采用最合适的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；而老年代中因为对象存活率高、没有额外空间对它分配进行担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

HotSpot的垃圾回收算法实现

• 枚举根节点
  在实现GC Roots可达性分析时，有两个难点：

1. 可作为GC Roots的节点主要在全局性引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里的引用，那么必然会消耗很多时间；
2. 可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中晋系–这里“一致性”的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间节点上，不可以出现分析过程中对象应用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有Java执行线程(Sun将这件事情成为“Stop The World”)的其中一个主要原因，即使是在号称(几乎)不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

目前主流的Java虚拟机使用的都是准确式GC(即虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32位的整数123456，他到底是一个reference类型指向123456的内存地址还是一个数值为123456的整数，虚拟机是有能力分辨出来的，这样能在GC时准确判断堆上的数据是否还可能被使用)，所以当系统停顿下来后，并不需要一个不漏的检查完所有执行上下文和全局引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。
在HotSpot的实现中，是使用一组成为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内生命偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

• 安全点
  在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将需要大量的额外空间内存，这样GC的空间成本会变得很高.
  实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置成为安全点(Safepoint)，即程序执行时并非在所用的地方都能停顿下来开始GC，只有在达到安全点时才能暂停。Safepoint的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于增大运行时的负荷。所以，安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的——因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间执行，“长时间执行”最明显的特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等。所以具有这些功能的指令才会产生Safepoint.
• 安全区域
  使用Safepoint似乎已经完美的解决了如何进入GC的问题，但实际情况却并不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？所谓程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新分配CPU时间。对于这种情况，就需要安全区域(Safe Region)来解决。
  安全区域是一段代码片段中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要坚持系统是否已经完成了跟节点枚举，如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。
  至此，介绍完了如何回收的问题，包括用什么算法回收和在什么时候回收！

HotSpot垃圾收集器实现举例

下图展示了7种不同分代的收集器，连线表示可以搭配使用

下面一一介绍这7种收集器的特性、基本原理和使用场景，在介绍之前，先说明一下并发收集器和并行收集器的概念
并行(Parallel)：指多条垃圾收集器线程并行工作，但此时用户线程仍然处于等待状态；
并发(Concurrent)：指用户线程与垃圾收集线程同时执行(但不一定是并行的，可能会交替执行)，用户线程在继续用行，而垃圾收集程序运行于另一个CPU上

• Serial收集器
  这是一个使用复制算法的单线程收集器，“单线程”的意义不仅仅说明它只会用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。
  运行原理如下图：
  
  Serial收集器相比于其他收集器的优势在于：简单而高效(与其他收集器的单线程比)，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很多，收集几十兆甚至一百兆的新生代，停顿时间完全可以控制在几十毫秒最多一百毫秒以内，只要不是频繁发生，这点停顿时可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
  相关参数：
  -XX:SurvivorRatio(Eden区与Survivor区的大小比值)
  -XX:PretenureSizeThreshold(对象超过多大是直接在旧生代分配)
• ParNew收集器
  ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行并行垃圾收集之外，其余行为包括Serial收集器可用的控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。ParNew收集器运行过程如下图：
  
  ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK1.5时期，HotSpot推出一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器(Concurrent Mark Sweep)。
  ParNew默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境下，可以使用
  -XX:ParallelGCThreads参数来限制垃圾收集的线程数
• Parallel Scavenge收集器
  Parallel Scavenge是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能的缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。
  Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMills参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
  MaxGCPauseMills参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。需要注意的是，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间在下降，但吞吐量也降下来了。
  GCTimeRatio参数的值应当是一个大于0且小于等于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如参数设置为19，那允许的最大GC时间就占总时间的5%(即1/(1+19))，默认99，就是允许最大1%(即1/(1+99))的垃圾收集时间。
  由于与吞吐量关系密切，Parallel Scavenge收集器经常称为“吞吐量优先”收集器。除上述两个参数外，Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象的大小(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提工最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略(GC Ergonomics)。如果使用此策略的话，我们只要把基本的内存数据设置好(如-Xmx设置最大堆)，然后使用MaxGCPauseMillis参数(更关注最多停顿时间)或者GCTimeRation(更关注吞吐量)参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Paralle Scavenge收集器与ParNew收集器的一个重要区别。

以上都是新生代的垃圾收集器，用到的都是复制算法，接下来描述的是老年代垃圾收集器，用到的都是标记-整理算法。

• Serial Old收集器
  Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要一样也是在与给Client模式下的虚拟机使用。如果在Server模式下，那么它主要由两大用途：在JD看1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。Serial Old的运行过程可以参考Serial的图。
• Parallel Old收集器
  Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程“标记-整理”算法。这个收集器在JDK1.6中才开始提供的。
  在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。运行过程图可以参考Parallel Scavenge的图。
• CMS收集器
  CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。从名字“Mark Sweep”就可以看出，CMS收集器是基于“标记-整理”算法实现的，它的运行过程相对于前面几种收集器来说更复杂一点，主要包括四个步骤：

1. 初始标记(CMS initial mark): 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，这个步骤需要"Stop The World"
2. 并发标记(CMS concurrent mark): 并发标记阶段就是进行GC Roots Tracing的过程
3. 重新标记(CMS remark): 重新标记则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个步骤需要"Stop The World"。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短。
4. 并发清除(CMS Concurrent sweep): 清除对象

由于整个过程中耗时最长的并发标记和兵法清楚过程收集线程都可以与用户线程一起工作，所以，从总体上说，CMS收集器的内存回收是与用户线程一起并发执行的。整个收集过程如下图：

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，Sun公司的一些官方文档中也称之为并发低停顿收集器。但是CMS还没有达到完美的程度，它有以下3个缺点：

1. 对CPU资源比较敏感。在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程(或者说CPU资源)而导致应用程序变慢，吞吐量会降低。CMS默认启动的回收线程数是(CPU+3)/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量增加而下降。但是当CPU不足4个时，譬如两2个时，CMS对用户程序的影响就可能变得很大，如果本来CPU的负载就比较大，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度降低了50%，让人难以接受。
2. CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。
3. CMS是基于“标记-清除”算法实现的收集器，这意味着收集结束会有大量的空间碎片产生。当空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发一次Full GC。当然，CMS提供了一个参数 -XX:+UseCMSCompactAtFullCollection开关参数(默认时开启的)，用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程时无法并发的，空间碎片问题没有了，但停顿时间不得不变长。虚拟机还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的FullGC后，跟着来一次带压缩的(默认为0，表示每次进入FullGC时都进行碎片整理)。

• G1收集器
  G1收集器时当今收集器技术发展的最前沿成果之一，G1是一款面向服务端应用的垃圾收集器。G1收集器的运作大致可以分为以下几个步骤：

1. 初始标记(Initial Marking): 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短
2. 并发标记(Concurrent Marking): 并发标记阶段时从GC 、Roots开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
3. 最终标记(Final Marking): 最终标记时为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
4. 筛选回收(Live Data Counting and Evacuation): 最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

通过下图可以比较清楚地看到G1收集器的运作步骤：

在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域(Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离了，它们都是一部分Region(不需要连续)的集合。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获的的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大Region(这也就是Garbage-First名称的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以获取尽可能高的收集效率。需要注意的是，Region不可能是孤立的，一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那么在做可达性判断确定对象是否存活的时候，岂不是还得扫描整个Java堆才能保证准确性？在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在堆Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象)，如果是，便通过高CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

G1是一款面向服务端应用的垃圾收集器，与其他GC收集器相比，如上图，G1具备如下特点：

1. 并行与并发：G1能够充分利用多CPU、多核环境下的硬件优势，使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World停顿时间，部分其他收集器原本不需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
2. 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
3. 空间整合：与CMS的“标记-整理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部(两个Region之间)上来看是基于“复制”算法实现的，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前出发下一次GC。
4. 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间时G1和CMS共同的关注点，但是G1出了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确制定在一个长度为M毫秒的时间片段内，消耗在垃圾收集器上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。

G1介绍相关博客推荐：https://javadoop.com/post/g1