第三章：垃圾收集器与分配策略

概述

• 垃圾收集（GarbageCollection GC），GC需要完成的3件事情：

  1. 哪些内存需要回收？
  2. 什么时候回收？
  3. 如何回收？

• 目前内存的动态分配与内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，那为什么我们还要去了解GC和内存分配呢？答案很简单：当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

• 上一章介绍了内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域是线程独享的。栈中的栈帧随着方法的进入和退出而有条不紊的执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上在编译期间就能够确定。因此这几个区域的内存分配和回收都具备确定性，因为方法结束或者线程结束时，内存自然就跟随着回收了。但Java堆显然不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分的内存具有动态性，垃圾收集器所关注的是这部分内存。下面提到的内存也仅指这部分内存。

对象已死吗

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

引用计数算法

• 引用计数算法（Reference Counting）是这样的：给对象添加一个引用计数器，每当一个地方引用它时，计数值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
• 引用计数算法实现简单，判定效率也高。但是，在主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互引用的问题。什么是相互引用呢？假设有个对象A持有对象B的引用，对象B持有对象A的引用。他们的引用计数将永远也达不到0。就好比你要开门就要用到钥匙，但是你的钥匙需要开门后才能拿到。

/**
*   -XX:+PrintGCDetails 可以查看GC日志
*/
public class GC {
    public Object hold = null;

    private static final int _1MB = 1024 * 1024;
    private byte[] bigSize = new byte[2 * _1MB];

    public static void main(String args[]) {
        GC a = new GC();
        GC b = new GC();
        a.hold = b;
        b.hold = a;

        a = null;
        b = null;
        System.gc();
    }
}
--------------------------
[GC (System.gc()) [PSYoungGen: 6092K->680K(38400K)] 6092K->688K(125952K), 0.0031550 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 
[Full GC (System.gc()) [PSYoungGen: 680K->0K(38400K)] [ParOldGen: 8K->570K(87552K)] 688K->570K(125952K), [Metaspace: 2658K->2658K(1056768K)], 0.0085480 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 ………………

• 从6092K->680K可以得知当前虚拟机并不会因为相互引用产生问题。

可达性分析算法

• 在主流的商用程序语言的主流实现中，都是通过可达性分析（Reachability Analysis）来判定对象是否存活。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连，则证明此对象不可用。
  
• 在Java语言中，可作为GC Roots的对象包括：
  
  1. 虚拟机栈（主要是本地变量表）中引用的对象。
  2. 方法区中类静态属性引用的对象。
  3. 方法区中常量引用的对象。
  4. 本地方法栈中JNI（即Natice方法）引用的对象。

再谈引用

• 由上可知，判定对象是否存活都与引用有关。在JDK1.2以前，引用的定义很传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表一个引用。这样定义太过狭隘，一个对象只有被引用或者没有被引用两个状态。在JDK1.2之后。Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）。
  
  1. 强引用就是指在程序代码中普遍存在的（Object o = new Object()），只要强引用还存在，垃圾收集器永远不会回收被引用的对象（内存不够用就抛溢出异常）。
  2. JDK1.2提供了SoftReference类来实现软引用，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围进行第二次回收。
  3. JDK1.2提供了WeakReference类来实现弱引用。被弱引用关联的对象只能生存到下一次垃圾收集发生之前。
  4. JDK1.2提供了PhantomReference类来实现虚引用。它是最弱的一种引用关系。一个对象是否有虚引用完全不会对其生存时间造成影响，也无法通过虚引用来获得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知（这个例子在java编程思想并发编程中有用过）。

生存还是死亡

• 即使在可达性分析算法中不可达的对象，也有一次自我救赎的机会。要真正宣告一个对象死亡，还有经过以下过程：
  
  1. 判断对象是否有必要执行finalize()方法，当对象没有覆盖finalize()方法或者该方法已经在之前被调用过一次，那么虚拟机将视其为没有必要执行，该对象即将被回收。
  2. 如果对象有必要执行finalize()方法，在执行了该方法后，该对象可达（不可达依旧会被回收），则将其移出即将回收的集合。这是对象拯救自己的唯一方式。
• 作者建议大家忘记Java中有这个方法。

回收方法区

• 很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区中进行垃圾收集的性价比一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。
• 永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串”abc”已经进入了常量池，但是当前系统没有任何一个String对象是叫做”abc”的，即没有任何String对象引用常量池中的”abc”常量，此时发生系统回收，且有必要的话，这个”abc”常量就会被系统清理出常量池。
• 判断一个类是否是无用的类相对苛刻得多：
  
  1. 该类所有实例都已经被回收
  2. 加载该类的ClassLoader已经被回收。
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
• 在满足上面三个条件，还需要通过-Xnoclassgc进行控制是否回收无用类。在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSFi这类频繁自定义ClassLoader的场景都需要虚拟机具备类写在的功能，以保证永久代不会溢出。

垃圾收集算法

• 本节只是简单讨论几种算法的思想和发展过程。

标记-清除算法（Mark-Sweep）

• 标记-清除算法是最基础的收集算法，算法分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。它的主要不足有两个：1.效率问题，标记和清除两个过程的效率都不高；2.空间问题，标记的内存空间都是不连续的，清除后会产生大量内存碎片，难以利用（所以应该需要被整理）。

复制算法（Copying）

• 复制算法能够解决效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这块内存用完之后，就将还存活着的对象复制在另一块上，按顺序分配内存。然后将原来使用的内存块全部清理掉。这样也能解决内存碎片的问题。但是这个算法的代价（将内存缩小为原来的一半）未免也太高了点。现在的商业虚拟机都采用这种算法来回收新生代。研究表明，新生代中的对象98%都是朝生夕死的，所以并不需要1:1的比例来划分空间，而是将内存分为一块较大的Eden空间（一般为80%）和两块较小的Survivor空间（一般为10%），每次使用Eden和其中一块Survivor（不妨停下来思考一下复制算法是如何靠着两种内存运作的）。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，只有10%的内存会被浪费。但是我们没有办法保证每次回收都只有不多与10%的对象存活，因此当Survivor空间不够用时，我们需要依赖其他内存（通常指老年代）进行分配担保（Handle Promotion）（这些对象进入老年代内存，稍后会有介绍）。

标记-整理算法（Mark-Compact）

• 复制算法在对象存活率较高时就要进行较多的复制操作，效率会变得更低。且为了应对大量对象都存活的极端情况，还得需要额外的空间进行分配担保，所以老年代一般不能直接选用这种算法（老年代的特点就是基本不会被回收）。
• 根据老年代的特点，有人提出了另外一种标记-整理算法。标记过程和标记-清除算法一致，但后续步骤不是直接对可回收对象进行清理，而是让存活的对象都向一端移动，然后直接清理掉端边界以外的内存。如图所示：
  

分代收集算法

• 当前商业虚拟机的垃圾收集都采用分代收集算法，这种算法没什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。在新生代使用复制算法，而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用标记-清理或标记-整理的算法来进行回收。

hotspot的算法实现

枚举根节点

• 以可达性分析中从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用（常量，类静态属性）与执行上下文（栈帧中的本地变量表）中，现在很多引用仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。
• 另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这里一致性的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况。这点是导致GC进行时必须停顿所有Java执行线程（Stop The World）的其中一个重要原因，即使是在号称不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。
• 目前的主流Java虚拟机使用的都是准确式GC。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些内存是引用。这样，GC在扫描时就可以直接得知这些信息了。

安全点

• 在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但有一个很现实的问题：如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，GC的成本也会提高。
• 实际上，HotSpot也的确没有为每条指令都生成OopMap，只是在特定的位置记录了这些信息，这些位置称为安全点（Safepoint）。即程序执行时并非在所有地方都能停顿下来开始GC，只有到达安全点时才能暂停。Safepoint的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于增大运行负荷。所以，安全点的选定基本上是以程序是否具有让程序长时间执行的特征为标准选定的。长时间执行的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等。
• 对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所有线程（不包括JNI调用的线程）都跑到最近的安全点再停顿下来。这里有两种方案可供选择：抢先式中断和主动式中断。抢先式中断在GC发生时中断所有线程，如果发现有线程中断的地方不在安全点上，就恢复线程，让它跑到安全点上。现在几乎没有虚拟机使用这种方式。
• 主动式中断的思想是让GC需要中断线程的时候，不直接对线程操作，仅仅简单的设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。所以，轮询标志的位置除了安全点外，还要加上创建对象（需要分配内存）的地方。下面代码的test指令是HotSpot生成的轮询指令，当需要暂停线程时，虚拟机就把0x160100的内存页设置为不可读，线程执行到test指令时就会产生一个自陷异常信号，在预先注册的异常处理器中暂停线程实现等待，这样一条汇编指令便能完成安全点轮询和触发线程中断。
  

安全区域

• 使用Safepoint似乎已经完美解决了如何进入GC的问题，但实际情况却并不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，倘若线程已经处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求（然后走到安全的地方去中断挂起），JVM显然也不太可能一直等着这个线程重新被分配CPU时间。对于这种情况，就需要安全区域来实现。
• 安全区域是指在一段代码片段中，引用关系不会发生变化。在这个区域的任意地方开始GC都是安全的。
• 在线程执行到安全区域的代码，首先标识自己已经进入了安全区域，那样，当在这段时间内JVM要发起GC时，就不用管标识自己为安全区域状态的线程了。在线程要离开安全区域时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了那线程就继续执行，否则它就必须等待直到收到可以安全离开安全区域的信号为止。
• 到此，已经介绍了HotSpot虚拟机如何去发起内存回收的问题，但是虚拟机如何具体地进行回收动作仍未涉及（所以看起来会有点愣愣的）。因为内存回收如何进行是由虚拟机所采用的GC收集器决定的，而通常虚拟机中往往不止有一种GC收集器。下面继续来看HotSpot中有哪些GC收集器。

垃圾收集器

• 这里仅讨论HotSpot虚拟机中使用的垃圾收集器（五年前的情况）。
  
• 看上图，Serial、ParNew、Parallel Scavenge属于新生代垃圾收集器，CMS、Serial Old、Parallel Old属于老年代垃圾收集器。两者之间有线连接表示可以配合使用。接下来看看具体介绍。

Serial 收集器

• Serial收集器是最基本、发展历史最悠久的收集器，曾经（JDK1.3之前）是虚拟机新生代的唯一选择。这是一个单线程的收集器，此处的单线程并不只是指它仅用一个线程去执行垃圾收集工作，也代表了它在进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。这也是Stop The World说法的由来（会带来不好的用户体验）。下图示意了Serial/Serial Old收集器的运行过程。
  
• 从JDK1.3开始，一直到JDK1.7（本书出版时最新是1.7），HotSpot虚拟机开发团队为消除或者减少工作线程因内存回收而导致停顿的努力一直在进行着。从Serial收集器到Parallel收集器，再到Concurrent Mark Sweep（CMS）乃至GC收集器的最前沿成果Garbage First（G1）收集器，他们越来越优秀，停顿时间也越来越短，但是仍然没有办法完全消除。

ParNew 收集器

• ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为都和Serial一模一样。
• ParNew收集器除了多线程收集外，并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机首选的新生代收集器。其中一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能和CMS收集器配合工作。在JDK1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器（CMS），这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
• 不幸的是，CMS作为老年代的收集器，却无法与JDK1.4中已经存在的新生代收集器Parallel scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代时，新生代只能选择ParNew或者Serial收集器中的一个。ParNew收集器也是使用-XX:+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX:+UseParNewGC选项来强制指定它。
• ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分百地保证可以超越Serial收集器。它默认开启的收集线程数与CPU数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads 参数来限制垃圾收集的线程数。
• 这里简单解释一下在垃圾收集器的上下文中，并发（concurrent）和并行（parallel）的区别：
  
  1. 并行：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
  2. 并发：指用户线程和垃圾收集线程同时执行（但不一定是并行的，可能会交替执行）。

Parallel Scavenge 收集器

• Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，它几乎和ParNew一样，那么它有什么特别之处呢？
• Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。在此处，吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。例如虚拟机总共运行了100分钟，其中垃圾收集花了1分钟，那吞吐量就是99%。
• 停顿时间越短就越适合需要用户交互的程序，而高吞吐量则可以高效率的利用cpu时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
• Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为吞吐量优先的收集器。除上述两个参数以外，还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开后，就不需要指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机将会动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。这种调节方式称为GC自适应的调节策略，这也是Parallel scavenge收集器与ParNew收集器的一个重要区别。
• MaxGCPauseMillis允许的值是一个大于0的毫秒数，收集器将尽可能保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。举个例子：收集300MB新生代肯定比收集500MB新生代来得快。但是这也导致垃圾收集发生的更频繁一些。原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿时间的确下降了，但吞吐量也下来了。
• GCTimeRatio参数的值应当是一个大于0且小于100的整数。如果把此参数设为19，那允许的最大GC时间就占总时间的5%（即1/(1+19)），默认值是99，就是允许最大1%的垃圾收集时间。

Parallel Old 收集器

• Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。由于Serial Old收集器在服务器应用性能上的拖累，使用了Parallel scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。在老年代很大而且硬件比较高级的环境下，这种组合的吞吐量甚至还不一定有ParNew+CMS组合给力。
• 直到Parallel Old收集器出现后，吞吐量优先收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old。他们的工作过程如下：
  

CMS 收集器

• CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的java应用集中在互联网或者B/S系统的服务端上，这类应用尤其重视服务的相应速度，希望系统停顿时间最短，以给用户带来较好的体验。
• 从名字就可以看出CMS收集器是基于标记-清除算法实现的。所以它仅适用于老年代的回收。它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为四个步骤，包括：
  
  1. 初始标记
  2. 并发标记
  3. 重新标记
  4. 并发清除
• 其中，初始标记、重新标记这两个步骤仍然需要Stop The World。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录（如一块不可回收内存变成可回收了），这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的短。
• 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以和用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
  
• CMS是一款优秀的收集器，它有并发收集、低停顿的优点。但是它也有3个明显的缺点：
  
  1. CMS收集器对CPU资源非常敏感。简单来说在并发标记、并发清理阶段，CMS收集器需要占用一部分CPU资源，导致用户程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集器线程不少于25%的CPU资源。但是当CPU不足4个（例如2个），CMS对用户程序的影响就会变的很大，如果本来CPU的负载就比较大，还要分出一半的计算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。为了应付这种情况，虚拟机提供了一种称为增量式并发收集器的CMS收集器变种，所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想一样，就是在并发标记、清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户的影响就会显得少一些。增量式并发收集器效果很一般，现在已不提倡用户使用（CPU少还不如直接使用Serial Old）。
  2. CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生。我们知道重新标记阶段可以收集并发标记中用户线程所产生的新的垃圾，但并发清理过程中用户线程所产生的垃圾却因没有经过标记而无法被清理（这部分垃圾就叫浮动垃圾）。不仅如此，由于整个收集过程伴随的着用户线程的并发执行，我们不能等老年代几乎满了再进行收集，需要预留一部分内存空间在并发收集时以供用户线程使用。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以通过调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获得更好的性能，在JDK1.6中，CMS收集器的启动阈值已经提高到92%。但是这也伴随着一定的风险。要是CMS运行期间预留的内存无法满足程序需要，就会出现Concurrent Mode Failure失败。这时虚拟机将启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，这样停顿的时间就很长了。因此-XX:CMSInitiatingOccupancyFraction的值设的太高反而会导致大量Concurrent Mode Failure，性能反而降低。
  3. 第三个缺点是算法导致的，我们知道标记-清理算法会产生很多内存碎片（使用标记-整理算法是无法实现并发的）。当内存碎片过多，将会给大对象的分配带来麻烦。往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认开启），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片的问题没有了，但停顿的时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值是0，表示每次Full GC时都进行碎片整理）。

G1收集器

• G1是一款面向服务端应用的垃圾收集器。HotSpot赋予它的使命是未来可以替换掉JDK1.5发布的CMS收集器。与其他GC收集器相比，G1具备如下特点：
  
  1. 并发与并行：G1能充分利用多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之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留着新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region的集合。
• G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region垃圾堆积的价值大小（回收空间大小以及所需时间经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也是Garbage-First名字的由来）
• G1把内存化整为零的思想，理解起来似乎很容易，但其中的实现细节却远远没有想象中那么简单。把Java堆分为多个Region后，垃圾收集是否真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在：Region不可能孤立的。一个对象分配在某个Region里，它并非只能被本Region中的其他对象引用，而是可以和整个Java堆任意的对象发生引用关系。那在做可达性判定对象是否存活的时候，岂不是还得扫描整个Java堆从能保证准确性？其实这个问题在其他收集器中也存在，在以前的分代收集中，新生代的规模一般比老年代要小很多，新生代的收集也比老年代要频繁很多，如果回收新生代时也不得不扫描老年代的话，那么Minor GC的效率可能会下降不少。
• 在G1收集器中，Region之间的对象引用以及其他收集器中的新生代和老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个对应的Remembered Set，虚拟机在发现程序在对Reference类型数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region（分代例子中就是检查老年代是否引用了新生代的对象），如果是，便通过CardTable把相关信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点枚举范围中加入Remembered Set即可保证不对全堆枚举也不会有遗漏。
• 如果不计算维护Remembered Set的操作，G1收集器运作大致分为以下几个步骤：
  
  1. 初始标记
  2. 并发标记
  3. 最终标记
  4. 筛选回收
• 这几个步骤和CMS收集器及其相似。前两个阶段几乎一样，最终标记则是修正在并发标记期间因用户程序继续运作而导致标记发生变动的那一部分记录，虚拟机会将并发标记期间对象变化情况记录在Remembered Set Logs中，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可以并行执行（指并行标记）。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。这个阶段其实也可以做到与用户一起并发执行，但是因为只回收一部分Region，时间是用户可以控制的，而且停顿用户线程将大幅度提高收集效率。
  

理解GC日志

• -XX:+PrintGCDetails -XX:+PrintGCTimeStamps第一个命令可以显示GC日志，第二个命令可以显示GC时间点。来看一下典型的日志：

public class Test {
    public static void main(String[]args) {
        System.gc();
        System.out.println("============");
    }
}
==========
0.058: [GC 
[PSYoungGen: 1997K->600K(38400K)] 1997K->600K(124928K), 0.0039005 secs] 
[Times: user=0.05 sys=0.00, real=0.00 secs] 
0.062: [Full GC 
[PSYoungGen: 600K->0K(38400K)] 
[ParOldGen: 0K->524K(86528K)] 600K->524K(124928K) 
[PSPermGen: 2695K->2694K(21504K)], 0.0086473 secs] 
[Times: user=0.00 sys=0.00, real=0.01 secs] 

• 最前面的数字0.058和0.062代表了GC发生的时间，这个数字的含义是从Java虚拟机启动以来经过的秒数。
• GC日志开头的[GC和[Full GC说明了这次垃圾收集的停顿类型，而不是用来区分新生代GC和老年代GC的。如果有Full，说明这次GC是发生了Stop-The-World的。
• 接下来的PSYoungGen和ParOldGen等表示GC发生的区域，这里显示的区域名称和使用的GC收集器是密切相关的。如Serial收集器的新生代名为Default New Generation，所以显示为DefNew。在这里PSYoungGen代表的是Parallel Scavenge收集器，ParOldGen代表的是Parallel Old收集器。PSPermGen代表是永久带，使用的收集器也是Parallel Scavenge+Parallel Old。
• 后面方括号内部的1997K->600K(38400K)含义是GC前该内存区域已使用容量->GC后已使用容量（总容量）。而方括号后面的1997K->600K(124928K)含义是GC前Java堆已使用容量->GC后Java堆已使用容量（Java堆总容量）。
• 再往后0.0039005 secs表示GC所占用的时间，单位是秒。而[Times: user=0.05 sys=0.00, real=0.00 secs] 则是GC占用时间更详细的记录。user代表用户态消耗的CPU时间，sys代表内核态消耗的CPU时间，real代表操作从开始到结束经过的墙钟时间。墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O，等待线程阻塞，而CPU时间不包括这些耗时。当系统有多CPU或者多核的话，多线程操作会叠加CPU时间，所以user和sys时间超过real时间是完全正常的。

垃圾收集器参数总结

参数	描述
UseSerialGC	虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old的收集器组合进行内存回收
UseParNewGC	打开此开关后，使用ParNew+Serial Old的收集器组合
UseConcMarkSweepGC	打开此开关后，使用ParNew+CMS+Serial Old的收集器组合。Serial Old作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器
UseParallelGC	虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合
UseParallelOldGC	打开此开关后，使用Parallel Scavenge + Parallel Old的收集器组合
SurvivorRatio	新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden：Survivor=8:1
PretenureSizeThreshold	直接晋升老年代的对象大小
MaxTenuringThreshold	晋升到老年代的对象年龄。每个对象坚持过一次Minor GC之后，年龄就会增加1，当超过这个值就会晋升到老年代
UseAdaptiveSizePolicy	当使用parallel Scavenge时，打开这个开关能让JVM动态调整Java堆各个区域的参数
HandlePromotionFailure	是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况
ParallelGCThreads	设置并行GC时进行内存回收的线程数
GCTimeRatio	GC时间占总时间的比例，默认是99，即允许1%的GC时间。仅在Parallen Scavenge收集器时有效
MaxGCPauseMillis	设置GC的最大停顿时间。仅在Parallen Scavenge收集器时有效
CMSInitatingOccupancyFraction	设置CMS收集器在老年代空间被使用多少后触发垃圾收集，默认值为68%。仅在使用CMS收集器时有效
UseCMSCompactAtFullCollection	设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅在使用CMS收集器时有效
CMSFullGCsBeforeCompaction	设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理。仅在使用CMS收集器时有效

内存分配与回收策略

• 下面会讲解几条最普遍的内存分配规则，并通过代码去验证这些规则。下面的例子统一使用Serial+Serial Old收集器组合。

对象优先在Eden分配

• 大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
• 给出下面的例子：

/**
 * -XX:+UseSerialGC 如果不使用这个参数，我的机器默认使用的是PS，它会自动将分配的4M大对象扔进老年代，不会有Minor GC过程
 * -verbose:gc
 * -Xms20M
 * -Xmx20M
 * -Xmn10M
 * -XX:+PrintGCDetails
 * -XX:SurvivorRatio=8
 * @author Administrator
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;
        allocation1 = new byte[2 * _1MB];
        allocation2 = new byte[2 * _1MB];
        allocation3 = new byte[2 * _1MB];
        allocation4 = new byte[4 * _1MB];//出现一次Minor GC
    }

    public static void main(String args[]) {
        testAllocation();
    }
}
===================
[GC[DefNew: 7303K->525K(9216K), 0.0033123 secs] 7303K->6669K(19456K), 0.0033410 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4787K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e29788, 0x00000000fa200000)
  from space 1024K,  51% used [0x00000000fa300000, 0x00000000fa383770, 0x00000000fa400000)
  to   space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 tenured generation   total 10240K, used 6144K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  60% used [0x00000000fa400000, 0x00000000faa00030, 0x00000000faa00200, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2702K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0a3948, 0x00000000fb0a3a00, 0x00000000fc2c0000)
No shared spaces configured.

• 分析GC日志我们可以发现[GC[DefNew: 7303K->525K(9216K), 0.0033123 secs] 7303K->6669K(19456K), 0.0033410 secs]，DefNew的大小是9216K，刚好是Eden+一个Survivor=9MB。经过这次GC后，java堆占用的对象的大小从7303K到了6669K，再根据下面的分配情况可以得知：在创建allocation4时，由于Eden的大小不足4MB而发生了一次Minor GC，此次GC的效果是，将allocation1~3从Eden通过分配担保机制（Survivor只有1M）移入了老年代（tenured generation）。

大对象直接进入老年代

• 在上一个例子中，4MB的对象最终通过分配担保机制被移入了老年代。然而系统经历了一次意义不高的Minor GC。所以我们干嘛不一开始就把这样的大对象直接丢入老年代呢？
• 虚拟机提供了一个-XX:PretenureSizeThreshold参数（单位为B），令大于这个设置值的对象直接在老年代中分配。该参数只对Serial和ParNew收集器有效，Parallel Scavenge收集器不认识这个参数，并不需要设置。
• 同样一个例子，我们多加一个-XX:PretenureSizeThreshold=3145728，也就是大于3MB的直接移入老年代，得到下面的GC日志：

Heap
 def new generation   total 9216K, used 7631K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  93% used [0x00000000f9a00000, 0x00000000fa173cb8, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 4096K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  40% used [0x00000000fa400000, 0x00000000fa800010, 0x00000000fa800200, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2738K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0ac858, 0x00000000fb0aca00, 0x00000000fc2c0000)
No shared spaces configured.

• 可以发现此次程序运行没有发生GC，结果令人满意。

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

• 既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认15岁），就将会被晋升到老年代中。我们可以通过-XX:MaxTenuringThreshold设置年龄的阈值。
• 通过下面的例子对这个参数进行验证：

/**
 * -XX:+UseSerialGC
 * -verbose:gc
 * -Xms20M
 * -Xmx20M
 * -Xmn10M
 * -XX:+PrintGCDetails
 * -XX:SurvivorRatio=8
 * -XX:MaxTenuringThreshold=1
 * -XX:+PrintTenuringDistribution
 * @author Administrator
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;
        allocation1 = new byte[_1MB / 4];
        allocation2 = new byte[4 * _1MB];
        allocation3 = new byte[4 * _1MB];
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];
    }

    public static void main(String args[]) {
        testAllocation();
    }
}
=======
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:     804680 bytes,     804680 total
: 5511K->785K(9216K), 0.0035783 secs] 5511K->4881K(19456K), 0.0036158 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:        136 bytes,        136 total
: 5045K->0K(9216K), 0.0011770 secs] 9141K->4881K(19456K), 0.0011905 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4260K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e28fd0, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200088, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 4881K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  47% used [0x00000000fa400000, 0x00000000fa8c4448, 0x00000000fa8c4600, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2738K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0ac848, 0x00000000fb0aca00, 0x00000000fc2c0000)
No shared spaces configured.

• 设置阈值为1的结果和书上一致。设置阈值为15的结果却书上的期望不同（这里留个疑问）。当阈值设为1时，第一次申请allocation3时，因为Eden不足以分配下一个4MB，所以进行了一次Minor GC，将allocation1移入Survivor，allocation2通过分配担保进入了老年代。第二次申请allocation3时，又会进行一次Minor GC，此时将之前那个已经释放的allocation3所占用的4MB释放，且因为allocation1经历了第二次GC后还存活，被移入了老年代。所以新生代的空间就会被释放干净。最终，我们可以看到新生代中占用了第二个allocation3的4MB，老年代中占用了allocation1和allocation2。
• 讲道理，将阈值设为15，那么最终老年代中只会存在allocation2，而新生代的Survivor中应该还保存着allocation1，然而我实验下来的结果却是和上面大同小异（除了max 和 new threshold不一样之外），我也不知道为什么：

[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age   1:     800640 bytes,     800640 total
: 5511K->781K(9216K), 0.0031663 secs] 5511K->4877K(19456K), 0.0032194 secs] [Times: user=0.02 sys=0.02, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:        136 bytes,        136 total
: 4962K->0K(9216K), 0.0011577 secs] 9058K->4877K(19456K), 0.0011706 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4260K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e28fd0, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200088, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 4877K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  47% used [0x00000000fa400000, 0x00000000fa8c3480, 0x00000000fa8c3600, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2702K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0a3938, 0x00000000fb0a3a00, 0x00000000fc2c0000)
No shared spaces configured.

动态对象年龄判定

• 上面留了一个疑问，就是为何-XX:MaxTenuringThreshold=1和15的结果是一样的。原来，为了能更好的适应不同程序的内存状况，虚拟机并不是永远要求对象年龄必须达到阈值才晋升老年代。如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间一半，年龄大于或等于该年龄的对象就可以直接进入老年代（我想测验一下必须是相同年龄所有对象，还是大于等于某年龄所有对象）。所以，查看上面日志，第一次GC中，因为781K大于1024K的一半，所以在第二次GC时，直接将Survivor空间下的这些内存移入了老年代。我们调低allocation1的大小，使其第一次GC后，Survivor空间小于512K，就不会出现意想不到的情况了。
• 遗憾的是：无论我怎么调整，预留的空间总是大于一半。所以我决定重新做一个例子：

/**
 * -XX:+UseSerialGC
 * -verbose:gc
 * -Xms20M
 * -Xmx20M
 * -Xmn10M
 * -XX:+PrintGCDetails
 * -XX:SurvivorRatio=8
 * -XX:MaxTenuringThreshold=15
 * -XX:+PrintTenuringDistribution
 * @author Administrator
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;
        allocation1 = new byte[_1MB / 4];//被分配进Eden
        allocation2 = new byte[4 * _1MB];//被分配进Eden
        allocation3 = new byte[4 * _1MB];//进行一次GC，allocation2进入老年代，allocation1进入Survivor，allocation3分配进Eden
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，旧allocation3被清理，allocation1进入老年代，新allocation3分配进Eden
        allocation1 = null;
        allocation1 = new byte[_1MB / 4];//被分配进Eden，此时老allocation1还未被清理
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，旧allocation3被清理，allocation1进入Survivor，这次就没有大于512K了，新allocation3分配进Eden,
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，这里-XX:MaxTenuringThreshold的作用得以体现，如果为1，allocation1会进入老年代。
        //经历了4次Minor GC 没有进行Full GC，老allocation1没有被清理
    }

    public static void main(String args[]) {
        testAllocation();
    }
}
===============
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age   1:     800640 bytes,     800640 total
: 5511K->781K(9216K), 0.0028338 secs] 5511K->4877K(19456K), 0.0028734 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:        136 bytes,        136 total
: 4962K->0K(9216K), 0.0011143 secs] 9058K->4877K(19456K), 0.0011257 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:     262160 bytes,     262160 total
- age   2:        136 bytes,     262296 total
: 4448K->256K(9216K), 0.0005413 secs] 9325K->5133K(19456K), 0.0005498 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   2:     262160 bytes,     262160 total
- age   3:        136 bytes,     262296 total
: 4352K->256K(9216K), 0.0001912 secs] 9229K->5133K(19456K), 0.0002035 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4516K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e28fd0, 0x00000000fa200000)
  from space 1024K,  25% used [0x00000000fa200000, 0x00000000fa240098, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 4877K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  47% used [0x00000000fa400000, 0x00000000fa8c3480, 0x00000000fa8c3600, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2702K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0a3958, 0x00000000fb0a3a00, 0x00000000fc2c0000)
No shared spaces configured.

• 终于，在-XX:MaxTenuringThreshold=15，可以看到from space 25%的空间被占用了，这说明我们的想法都是正确的。然后我依次加入256KB，并触发一次Minor GC，到达Survivor中：256KB 4岁 256KB 2岁 256KB 1岁。如果大于2岁的都被移入老年代，说明文章的描述有误（不是等于某年龄，而是大于等于某年龄），如果没有发生移入老年代的行为，说明描述没有问题。

/**
 * -XX:+UseSerialGC
 * -verbose:gc
 * -Xms20M
 * -Xmx20M
 * -Xmn10M
 * -XX:+PrintGCDetails
 * -XX:SurvivorRatio=8
 * -XX:MaxTenuringThreshold=1
 * -XX:+PrintTenuringDistribution
 * @author Administrator
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4, allocation5, allocation6;
        allocation1 = new byte[_1MB / 4];//被分配进Eden
        allocation2 = new byte[4 * _1MB];//被分配进Eden
        allocation3 = new byte[4 * _1MB];//进行一次GC，allocation2进入老年代，allocation1进入Survivor，allocation3分配进Eden
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，旧allocation3被清理，allocation1进入老年代，新allocation3分配进Eden
        allocation1 = null;
        allocation1 = new byte[_1MB / 4];//被分配进Eden，此时老allocation1还未被清理
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，旧allocation3被清理，allocation1进入Survivor，这次就没有大于512K了，新allocation3分配进Eden,
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//进行一次GC，这里-XX:MaxTenuringThreshold的作用得以体现，如果为1，allocation1会进入老年代。
        //经历了4次Minor GC 没有进行Full GC，老allocation1没有被清理
        //此时allocation1 2岁
        allocation4 = new byte[_1MB / 4 + 1];//被分配进Eden,多分配一字节，避免刚刚好占一半
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//触发GC 此时allocation1 3岁 allocation4 1岁
        allocation5 = new byte[_1MB / 4 + 1];//被分配进Eden
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//触发GC 此时allocation1 4岁 allocation4 2岁 allocation5 1岁
        allocation6 = new byte[_1MB / 4 + 1];//被分配进Eden
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];//触发GC 此时allocation1 5岁 allocation4 3岁 allocation5 2岁 allocation6 1岁
    }

    public static void main(String args[]) {
        testAllocation();
    }
}
===========
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age   1:     800640 bytes,     800640 total
: 5511K->781K(9216K), 0.0028247 secs] 5511K->4877K(19456K), 0.0028637 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:        136 bytes,        136 total
: 4962K->0K(9216K), 0.0011011 secs] 9058K->4877K(19456K), 0.0011155 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:     262160 bytes,     262160 total
- age   2:        136 bytes,     262296 total
: 4448K->256K(9216K), 0.0005914 secs] 9325K->5133K(19456K), 0.0005997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   2:     262160 bytes,     262160 total
- age   3:        136 bytes,     262296 total
: 4352K->256K(9216K), 0.0001830 secs] 9229K->5133K(19456K), 0.0001903 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 3 (max 15)
- age   1:     262168 bytes,     262168 total
- age   3:     262160 bytes,     524328 total
- age   4:        136 bytes,     524464 total
: 4672K->512K(9216K), 0.0001847 secs] 9549K->5389K(19456K), 0.0001924 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 2 (max 15)
- age   1:     262168 bytes,     262168 total
- age   2:     262168 bytes,     524336 total
: 4906K->512K(9216K), 0.0002868 secs] 9783K->5645K(19456K), 0.0002938 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 2 (max 15)
- age   1:     262168 bytes,     262168 total
- age   2:     262168 bytes,     524336 total
: 4892K->512K(9216K), 0.0002516 secs] 10025K->5901K(19456K), 0.0002586 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4772K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e28fd0, 0x00000000fa200000)
  from space 1024K,  50% used [0x00000000fa300000, 0x00000000fa380030, 0x00000000fa400000)
  to   space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 tenured generation   total 10240K, used 5389K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  52% used [0x00000000fa400000, 0x00000000fa943530, 0x00000000fa943600, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2702K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  12% used [0x00000000fae00000, 0x00000000fb0a39c8, 0x00000000fb0a3a00, 0x00000000fc2c0000)
No shared spaces configured.

• 细节不多说，相信现在你和我一样已经能看懂GC日志了。可以看到Survivor中的年龄的确和我们预测的一致（136 KB可能是其他垃圾）。但是结果却不像书里所说那样。我感觉是描述完全是相反的。如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间一半，年龄大于或等于该年龄的对象就可以直接进入老年代，我感觉应该再加一条：如果在Survivor空间中小于等于某年龄所有对象大小的总和大于Survivor空间一半，年龄大于该年龄的对象就可以直接进入老年代。这只是我通过例子得出来的猜想。

空间分配担保

• 在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代。如果是，那么分配担保是没有风险的。如果不是的话，虚拟机会查看HandlePromotionFailure设置值是否允许担保失败（担保失败会进行Full GC）。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，那么就会进行Minor GC（这次Minor GC是有风险的，如果失败也会进行Full GC。即使绕了一大弯，还是建议打开HandlePromotionFailure，避免无谓的Full GC）。如果小于，或者HandlePromotionFailure不允许冒险，那这次也要进行一次Full GC。
• 要注意，在JDK6 Update24之后，HandlePromotionFailure参数就不再被使用了。JDK6 Update24的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则进行Full GC。