一、JVM 简介

CMS 收集器无法处理浮动垃圾

CMS 收集器无法处理浮动垃圾，可能出现 “Concurrent Mode Failure” 失败而导致另一次 Full

GC 的产生。由于 CMS 并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的

垃圾不断产生，这一部分垃圾出现在标记过程之后， CMS 无法在当次收集中处理掉它们，只

好留待下一次 GC 时再清理掉。这一部分垃圾就称为 “ 浮动垃圾 ” 。也是由于在垃圾收集阶段用

户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此 CMS 收集器

不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供

并发收集时的程序运作使用。要是 CMS 运行期间预留的内存无法满足程序需要，就会出现一

次 “Concurrent Mode Failure” 失败，这时虚拟机将启动后备预案：临时启用 Serial Old 收集

器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

CMS 收集器会产生大量空间碎片

CMS 是一款基于 “ 标记 — 清除 ” 算法实现的收集器，这意味着收集结束时会有大量空间碎片产

生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩

余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次 Full GC 。

g) G1 收集器 ( 唯一一款全区域的垃圾回收器 )

G1 （ Garbage First ）垃圾回收器是用在 heap memory 很大的情况下，把 heap 划分为很多很多的

region 块，然后并行的对其进行垃圾回收。

G1 垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩。

G1 垃圾回收器回收 region 的时候基本不会 STW ，而是基于 most garbage 优先回收 ( 整体来看是基于 " 标

记 - 整理 " 算法，从局部 ( 两个 region 之间 ) 基于 " 复制 " 算法 ) 的策略来对 region 进行垃圾回收的。无论如

何， G1 收集器采用的算法都意味着

结果如下图：

一个 region 有可能属于 Eden ， Survivor 或者 Tenured 内存区域。图中的 E 表示该 region 属于 Eden 内存区

域， S 表示属于 Survivor 内存区域， T 表示属于 Tenured 内存区域。图中空白的表示未使用的内存空间。

G1 垃圾收集器还增加了一种新的内存区域，叫做 Humongous 内存区域，如图中的 H 块。这种内存区域

主要用于存储大对象 - 即大小超过一个 region 大小的 50% 的对象。

年轻代垃圾收集

在 G1 垃圾收集器中，年轻代的垃圾回收过程使用复制算法。把 Eden 区和 Survivor 区的对象复制到新的

Survivor 区域。

如下图：

老年代垃收集

对于老年代上的垃圾收集， G1 垃圾收集器也分为 4 个阶段，基本跟 CMS 垃圾收集器一样，但略有不同：

初始标记 (Initial Mark) 阶段 - 同 CMS 垃圾收集器的 Initial Mark 阶段一样， G1 也需要暂停应用

程序的执行，它会标记从根对象出发，在根对象的第一层孩子节点中标记所有可达的对象。

但是 G1 的垃圾收集器的 Initial Mark 阶段是跟 minor gc 一同发生的。也就是说，在 G1中，你

② 内存间交互操作

class Singleton{
    // 确保产生的对象完整性
    private volatile static Singleton instance = null;
    private Singleton() {}
    public static Singleton getInstance() {
        if(instance==null) { // 检查对象是否初始化
            synchronized (Singleton.class) {
                if(instance==null) // 确保多线程情况下对象只有一个
                    instance = new Singleton();
           }
       }
        return instance;
   }
}