Java虚拟机之垃圾收集器/内存分配与回收策略

以下内容摘自《深入理解Java虚拟机——JVM高级特性与最佳实战》

第3章　垃圾收集器与内存分配策略

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。

3.1　概述

说起垃圾收集（Garbage Collection，GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史远远比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的三件事情：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

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

把时间从半个世纪以前拨回到现在，回到我们熟悉的Java语言。第2章介绍了Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或线程结束时，内存自然就跟随着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存，本书后续讨论中的“内存”分配与回收也仅指这一部分内存。

3.2　对象已死？

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

3.2.1　引用计数算法

很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。笔者面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案。

客观地说，引用计数算法（Reference Counting）的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如微软的COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言以及在游戏脚本领域中被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但是，Java语言中没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间的相互循环引用的问题。

举个简单的例子，请看代码清单3-1中的testGC()方法：对象objA和objB都有字段instance，赋值令objA.instance = objB及objB.instance = objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。

代码清单3-1　引用计数算法的缺陷

    /**  
    * testGC()方法执行后，objA和objB会不会被GC呢？  
    * @author zzm  

    */  
    public class ReferenceCountingGC {  
    public Object instance = null;  
    private static final int _1MB = 1024 * 1024;  
    /**  
    * 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过  
    */  
    private byte[] bigSize = new byte[2 * _1MB];  
    public static void testGC() {  
        　ReferenceCountingGC objA = new ReferenceCountingGC();  
        　ReferenceCountingGC objB = new ReferenceCountingGC();  
        　objA.instance = objB;  
        　objB.instance = objA;  

        　objA = null;  
        　objB = null;  

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

运行结果：

[Full GC (System) [Tenured: 0K->210K(10240K), 0.0149142 
secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 
0.0150007 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]  
Heap  
def new generation   total 9216K, used 82K 
[0x00000000055e0000, 0x0000000005fe0000, 0x0000000005fe0000)  
 Eden space 8192K,   1% used [0x00000000055e0000, 
0x00000000055f4850, 0x0000000005de0000)  
 from space 1024K,   0% used [0x0000000005de0000, 
0x0000000005de0000, 0x0000000005ee0000)  
 to   space 1024K,   0% used [0x0000000005ee0000, 
0x0000000005ee0000, 0x0000000005fe0000)  
tenured generation   total 10240K, used 210K 
[0x0000000005fe0000, 0x00000000069e0000, 0x00000000069e0000)  
  the space 10240K,   2% used [0x0000000005fe0000, 
0x0000000006014a18, 0x0000000006014c00, 0x00000000069e0000)  
compacting perm gen  total 21248K, used 3016K 
[0x00000000069e0000, 0x0000000007ea0000, 0x000000000bde0000)  
  the space 21248K,  14% used [0x00000000069e0000, 
0x0000000006cd2398, 0x0000000006cd2400, 0x0000000007ea0000)  
No shared spaces configured. 

从运行结果中可以清楚地看到GC日志中包含“4603K->210K”，意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。

3.2.2　可达性分析算法

在主流的商用程序语言中（Java和C#，甚至包括前面提到的古老的Lisp），都是使用可达性分析算法(根搜索算法)（GC Roots Tracing）判定对象是否存活的。这个算法的基本思路就是通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如图3-1所示，对象object 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

在Java语言里，可作为GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中的引用的对象。
• 方法区中的类静态属性引用的对象。
• 方法区中的常量引用的对象。

• 本地方法栈中JNI（即一般说的Native方法）的引用的对象。

  
       图3-1　可达性分析算法判定对象是否可回收

3.2.3　再谈引用

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否存活都与“引用”有关。在JDK 1.2之前，Java中的引用的定义很传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。这种定义很纯粹，但是太过狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态，对于如何描述一些“食之无味，弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存之中；如果内存在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。

在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，这四种引用强度依次逐渐减弱。

• 强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

• 软引用用来描述一些还有用，但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。

• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。

• 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。

3.2.4　生存还是死亡？

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”(即宣布该对象死亡)。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己—只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那它就真的离死不远了。从代码清单3-2中我们可以看到一个对象的finalize()被执行，但是它仍然可以存活。

代码清单3-2　一次对象自我拯救的演示

    /**  
    * 此代码演示了两点：  
    * 1.对象可以在被GC时自我拯救。  
    * 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次  
    * @author zzm  
    */  
    public class FinalizeEscapeGC {  

    public static FinalizeEscapeGC SAVE_HOOK = null;  

    public void isAlive() {  
        　System.out.println("yes, i am still alive :)");  
    }  

    @Override  
    protected void finalize() throws Throwable {  
    　   　super.finalize();  
        　System.out.println("finalize mehtod executed!");  
        　FinalizeEscapeGC.SAVE_HOOK = this;  
    }  

    public static void main(String[] args) throws Throwable {  
        　SAVE_HOOK = new FinalizeEscapeGC();  

        　//对象第一次成功拯救自己  
        　SAVE_HOOK = null;  
        　System.gc();  
        　// 因为Finalizer方法优先级很低，暂停0.5秒，以等待它  
        　Thread.sleep(500);  
        　if (SAVE_HOOK != null) {  
            　SAVE_HOOK.isAlive();  
        　} else {  
            　System.out.println("no, i am dead :(");  
        　}  

        　// 下面这段代码与上面的完全相同，但是这次自救却失败了  
        　SAVE_HOOK = null;  
        　System.gc();  
        　// 因为Finalizer方法优先级很低，暂停0.5秒，以等待它  
        　Thread.sleep(500);  
        　if (SAVE_HOOK != null) {  
            　SAVE_HOOK.isAlive();  
        　} else {  
            　System.out.println("no, i am dead :(");  
        　}  
    }  
    } 

运行结果：

finalize mehtod executed!  
yes, i am still alive :)  
no, i am dead :( 

从代码清单3-2的运行结果可以看到，SAVE_HOOK对象的finalize()方法确实被GC收集器触发过，并且在被收集前成功逃脱了。

另外一个值得注意的地方就是，代码中有两段完全一样的代码片段，执行结果却是一次逃脱成功，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败了。

需要特别说明的是，上面关于对象死亡时finalize()方法的描述可能带有悲情的艺术色彩，笔者并不鼓励大家使用这种方法来拯救对象。相反，笔者建议大家尽量避免使用它，因为它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协。它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。有些教材中提到它适合做“关闭外部资源”之类的工作，这完全是对这种方法的用途的一种自我安慰。finalize()能做的所有工作，使用try-finally或其他方式都可以做得更好、更及时，大家完全可以忘掉Java语言中还有这个方法的存在。

3.2.5　回收方法区

很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：

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

虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、 -XX:+TraceClassUnLoading查看类的加载和卸载信息。

在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

3.3　垃圾收集算法

由于垃圾收集算法的实现涉及大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此本节不打算过多地讨论算法的实现，只是介绍几种算法的思想及其发展过程。

3.3.1　标记 -清除算法

最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程其实在前一节讲述对象标记判定时已经基本介绍过了。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它的主要缺点有两个：

• 效率问题，标记和清除过程的效率都不高；
• 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

标记-清除算法的执行过程如图3-2所示。

     图3-2　“标记-清除”算法示意图

3.3.2　复制算法

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。复制算法的执行过程如图3-3所示。

     图3-3　复制算法示意图

现在的商业虚拟机都采用这种收集算法来回收新生代，IBM的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1∶1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存是会被“浪费”的。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

内存的分配担保就好比我们去银行借款，如果我们信誉很好，在98%的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。内存的分配担保也一样，如果另外一块Survivor空间没有足够的空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。关于对新生代进行分配担保的内容，本章稍后在讲解垃圾收集器执行规则时还会再详细讲解。

3.3.3　标记-整理算法

复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如图3-4所示。

     图3-4　 “标记-整理”算法示意图

3.3.4　分代收集算法

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

3.5　内存分配与回收策略

Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存。关于回收内存这一点，我们已经使用了大量的篇幅去介绍虚拟机中的垃圾收集器体系及其运作原理，现在我们再一起来探讨一下给对象分配内存的那点事儿。

对象的内存分配，往大方向上讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

接下来我们将会讲解几条最普遍的内存分配规则，并通过代码去验证这些规则。本节中的代码在测试时使用Client模式虚拟机运行，没有手工指定收集器组合，换句话说，验证的是使用Serial / Serial Old收集器下（ParNew / Serial Old收集器组合的规则也基本一致）的内存分配和回收的策略。读者不妨根据自己项目中使用的收集器写一些程序去验证一下使用其他几种收集器的内存分配策略。

3.5.1　对象优先在Eden分配

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

虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前内存各区域的分配情况。在实际应用中，内存回收日志一般是打印到文件后通过日志工具进行分析，不过本实验的日志并不多，直接阅读就能看得很清楚。

代码清单3-3的testAllocation()方法中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过-Xms20M、 -Xmx20M和 -Xmn10M这3个参数限制Java堆大小为20MB，且不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8比1，从输出的结果也能清晰地看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。

执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变为148KB，而总内存占用量则几乎没有减少（因为allocation1、2、3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只好通过分配担保机制提前转移到老年代去。

这次GC结束后，4MB的allocation4对象被顺利分配在Eden中。因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、2、3占用）。通过GC日志可以证实这一点。

注意　作者多次提到的Minor GC和Full GC有什么不一样吗？

• 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。

• 老年代GC（Major GC / Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在ParallelScavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。MajorGC的速度一般会比Minor GC慢10倍以上。

代码清单3-3　新生代Minor GC

    private static final int _1MB = 1024 * 1024;  
    /**  
     * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 
     */  
    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  
    } 

运行结果：

[GC [DefNew: 6651K->148K(9216K), 0.0070106 secs] 
6651K->6292K(19456K), 0.0070426 secs] [Times: 
user=0.00 sys=0.00, real=0.00 secs]  
Heap  
def new generation   total 9216K, used 4326K 
[0x029d0000, 0x033d0000, 0x033d0000)  
 eden space 8192K,  51% used [0x029d0000, 
0x02de4828, 0x031d0000)  
 from space 1024K,  14% used [0x032d0000, 
0x032f5370, 0x033d0000)  
 to   space 1024K,   0% used [0x031d0000, 
0x031d0000, 0x032d0000)  
tenured generation   total 10240K, used 6144K 
[0x033d0000, 0x03dd0000, 0x03dd0000)  
  the space 10240K,  60% used [0x033d0000, 
0x039d0030, 0x039d0200, 0x03dd0000)  
compacting perm gen  total 12288K, used 2114K 
[0x03dd0000, 0x049d0000, 0x07dd0000)  
  the space 12288K,  17% used [0x03dd0000, 
0x03fe0998, 0x03fe0a00, 0x049d0000)  
No shared spaces configured. 

3.5.2　大对象直接进入老年代

所谓大对象就是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组（笔者例子中的byte[]数组就是典型的大对象。大对象对虚拟机的内存分配来说就是一个坏消息（替Java虚拟机抱怨一句，比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”，写程序的时候应当避免），经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。

虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代中分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝（复习一下：新生代采用复制算法收集内存）。

执行代码清单3-4中的testPretenureSizeThreshold()方法后，我们看到Eden空间几乎没有被使用，而老年代10MB的空间被使用了40%，也就是4MB的allocation对象直接就分配在老年代中，这是因为PretenureSizeThreshold被设置为3MB（就是3145728B，这个参数不能与-Xmx之类的参数一样直接写3MB），因此超过3MB的对象都会直接在老年代中进行分配。

注意　PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。如果遇到必须使用此参数的场合，可以考虑ParNew加CMS的收集器组合。

代码清单3-4　大对象直接进入老年代

    private static final int _1MB = 1024 * 1024;  

    /**  
    * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 
    * -XX:PretenureSizeThreshold=3145728 
    */  
    public static void testPretenureSizeThreshold() {  
    　byte[] allocation;  
    　allocation = new byte[4 * _1MB];  //直接分配在老年代中  
    } 

运行结果：

Heap  
def new generation   total 9216K, used 671K
[0x029d0000, 0x033d0000, 0x033d0000)  
 eden space 8192K,   8% used [0x029d0000, 
0x02a77e98, 0x031d0000)  
 from space 1024K,   0% used [0x031d0000, 0x031d0000, 0x032d0000)  
 to   space 1024K,   0% used [0x032d0000, 0x032d0000, 0x033d0000)  
tenured generation   total 10240K, used 4096K 
[0x033d0000, 0x03dd0000, 0x03dd0000)  
  the space 10240K,  40% used [0x033d0000, 
0x037d0010, 0x037d0200, 0x03dd0000)  
compacting perm gen  total 12288K, used 2107K 
[0x03dd0000, 0x049d0000, 0x07dd0000)  
  the space 12288K,  17% used [0x03dd0000, 
0x03fdefd0, 0x03fdf000, 0x049d0000)  
No shared spaces configured. 

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

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

读者可以试试分别以-XX:MaxTenuringThreshold=1和-XX:MaxTenuringThreshold=15两种设置来执行代码清单3-5中的testTenuringThreshold()方法，此方法中allocation1对象需要256KB的内存空间，Survivor空间可以容纳。当MaxTenuringThreshold=1时，allocation1对象在第二次GC发生时进入老年代，新生代已使用的内存GC后会非常干净地变成0KB。而MaxTenuringThreshold=15时，第二次GC发生后，allocation1对象则还留在新生代Survivor空间，这时候新生代仍然有404KB的空间被占用。

代码清单3-5　长期存活的对象进入老年代

    private static final int _1MB = 1024 * 1024;  

    /**  
    * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M 
    -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 
    * -XX:+PrintTenuringDistribution  
    */  
    @SuppressWarnings("unused")  
    public static void testTenuringThreshold() {  
     byte[] allocation1, allocation2, allocation3;  
     allocation1 = new byte[_1MB / 4];  
      // 什么时候进入老年代取决于XX:MaxTenuringThreshold设置  
     allocation2 = new byte[4 * _1MB];  
     allocation3 = new byte[4 * _1MB];  
     allocation3 = null;  
     allocation3 = new byte[4 * _1MB];  
    } 

以MaxTenuringThreshold=1的参数设置来运行的结果：

[GC [DefNew  
Desired Survivor size 524288 bytes, new threshold 1 (max 1)  
- age   1:     414664 bytes,     414664 total  
: 4859K->404K(9216K), 0.0065012 secs] 4859K->4500K
(19456K), 0.0065283 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]  
[GC [DefNew  
Desired Survivor size 524288 bytes, new threshold 1 (max 1)  
: 4500K->0K(9216K), 0.0009253 secs] 8596K->4500K
(19456K), 0.0009458 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]  
Heap  

def new generation   total 9216K, used 4178K 
[0x029d0000, 0x033d0000, 0x033d0000)  
 eden space 8192K,  51% used [0x029d0000, 
0x02de4828, 0x031d0000)  
 from space 1024K,   0% used [0x031d0000,
0x031d0000, 0x032d0000)  
 to   space 1024K,   0% used [0x032d0000, 
0x032d0000, 0x033d0000)  
tenured generation   total 10240K, used 
4500K [0x033d0000, 0x03dd0000, 0x03dd0000)  
  the space 10240K,  43% used [0x033d0000, 
0x03835348, 0x03835400, 0x03dd0000)  
compacting perm gen  total 12288K, used 2114K
[0x03dd0000, 0x049d0000, 0x07dd0000)  
  the space 12288K,  17% used [0x03dd0000, 
0x03fe0998, 0x03fe0a00, 0x049d0000)  
No shared spaces configured. 

以MaxTenuringThreshold=15的参数设置来运行的结果：

[GC [DefNew  
Desired Survivor size 524288 bytes, new threshold 15 (max 15)  
- age   1:     414664 bytes,     414664 total  
: 4859K->404K(9216K), 0.0049637 secs] 4859K->
4500K(19456K), 0.0049932 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:     414520 bytes,     414520 total  
: 4500K->404K(9216K), 0.0008091 secs] 8596K->
4500K(19456K), 0.0008305 secs] [Times: user=
0.00 sys=0.00, real=0.00 secs]  
Heap  
def new generation   total 9216K, used 4582K 
[0x029d0000, 0x033d0000, 0x033d0000)  
 eden space 8192K,  51% used [0x029d0000, 0x02de4828, 0x031d0000)  
 from space 1024K,  39% used [0x031d0000, 0x03235338, 0x032d0000)  
 to   space 1024K,   0% used [0x032d0000, 0x032d0000, 0x033d0000)  
tenured generation   total 10240K, used 4096K 
[0x033d0000, 0x03dd0000, 0x03dd0000)  
  the space 10240K,  40% used [0x033d0000, 
0x037d0010, 0x037d0200, 0x03dd0000)  
compacting perm gen  total 12288K, used 2114K 
[0x03dd0000, 0x049d0000, 0x07dd0000)  
  the space 12288K,  17% used [0x03dd0000,
0x03fe0998, 0x03fe0a00, 0x049d0000)  
No shared spaces configured. 

3.5.4　动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

执行代码清单3-6中的testTenuringThreshold2()方法，并设置参数-XX: MaxTenuringThreshold=15，会发现运行结果中Survivor的空间占用仍然为0%，而老年代比预期增加了6%，也就是说allocation1、allocation2对象都直接进入了老年代，而没有等到15岁的临界年龄。因为这两个对象加起来已经达到了512KB，并且它们是同年的，满足同年对象达到Survivor空间的一半规则。我们只要注释掉其中一个对象的new操作，就会发现另外一个不会晋升到老年代中去了。

代码清单3-6　动态对象年龄判定

    private static final int _1MB = 1024 * 1024;  

    /**  
    * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M 
    -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 
    * -XX:+PrintTenuringDistribution  
    */  
    @SuppressWarnings("unused")  
    public static void testTenuringThreshold2() {  
     byte[] allocation1, allocation2, allocation3, allocation4;  
     allocation1 = new byte[_1MB / 4];  
      // allocation1+allocation2大于survivor空间的一半  
     allocation2 = new byte[_1MB / 4];  
     allocation3 = new byte[4 * _1MB];  
     allocation4 = new byte[4 * _1MB];  
     allocation4 = null;  
     allocation4 = new byte[4 * _1MB];  
    } 

运行结果：

[GC [DefNew  
Desired Survivor size 524288 bytes, new threshold 1 (max 15)  
- age   1:     676824 bytes,     676824 total  
: 5115K->660K(9216K), 0.0050136 secs] 5115K->
4756K(19456K), 0.0050443 secs] [Times: user=0.00
sys=0.01, real=0.01 secs]  
[GC [DefNew  
Desired Survivor size 524288 bytes, new threshold 15 (max 15)  
: 4756K->0K(9216K), 0.0010571 secs] 8852K->4756K
(19456K), 0.0011009 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]  
Heap  
def new generation   total 9216K, used 4178K 
[0x029d0000, 0x033d0000, 0x033d0000)  
 eden space 8192K,  51% used [0x029d0000, 0x02de4828, 0x031d0000)  
 from space 1024K,   0% used [0x031d0000, 0x031d0000, 0x032d0000)  
 to   space 1024K,   0% used [0x032d0000, 0x032d0000, 0x033d0000)  
tenured generation   total 10240K, used 4756K 
[0x033d0000, 0x03dd0000, 0x03dd0000)  
  the space 10240K,  46% used [0x033d0000, 
0x038753e8, 0x03875400, 0x03dd0000)  
compacting perm gen  total 12288K, used 2114K 
[0x03dd0000, 0x049d0000, 0x07dd0000)  
  the space 12288K,  17% used [0x03dd0000, 
0x03fe09a0, 0x03fe0a00, 0x049d0000)  
No shared spaces configured. 

3.5.5　空间分配担保

在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行Minor GC；如果不允许，则也要改为进行一次Full GC。

前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况时（最极端就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁，参见代码清单3-7。

代码清单3-7　空间分配担保

    private static final int _1MB = 1024 * 1024;  

    /**  
    * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M
    -XX:SurvivorRatio=8 -XX:-  
    HandlePromotionFailure  

    */  
    @SuppressWarnings("unused")  
    public static void testHandlePromotion() {  
     byte[] allocation1, allocation2, allocation3,
    allocation4, allocation5, allocation6, allocation7;  
     allocation1 = new byte[2 * _1MB];  
     allocation2 = new byte[2 * _1MB];  
     allocation3 = new byte[2 * _1MB];  
     allocation1 = null;  
     allocation4 = new byte[2 * _1MB];  
     allocation5 = new byte[2 * _1MB];  
     allocation6 = new byte[2 * _1MB];  
     allocation4 = null;  
     allocation5 = null;  
     allocation6 = null;  
     allocation7 = new byte[2 * _1MB];  
    } 

以HandlePromotionFailure = false的参数设置来运行的结果：

[GC [DefNew: 6651K->148K(9216K), 0.0078936 secs] 
6651K->4244K(19456K), 0.0079192 secs] [Times: 
user=0.00 sys=0.02, real=0.02 secs]  
[GC [DefNew: 6378K->6378K(9216K), 0.0000206 secs]
[Tenured: 4096K->4244K(10240K), 0.0042901 secs] 
10474K->4244K(19456K), [Perm : 2104K->2104K(12288K)], 
0.0043613 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]  
以MaxTenuringThreshold= true的参数设置来运行的结果：  
[GC [DefNew: 6651K->148K(9216K), 0.0054913 secs] 
6651K->4244K(19456K), 0.0055327 secs] [Times:
user=0.00 sys=0.00, real=0.00 secs]  
[GC [DefNew: 6378K->148K(9216K), 0.0006584 secs] 
10474K->4244K(19456K), 0.0006857 secs] [Times: 
user=0.00 sys=0.00, real=0.00 secs]