Memory Allocation

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

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

1. 新的对象和数组被创建并放入老年代。
2. Minor垃圾回收将发生在新生代。依旧存活的对象将从eden区移到survivor区。
3. Major垃圾回收一般会导致应用进程暂停，它将在三个区内移动对象。仍然存活的对象将被从新生代移动到老年代。
4. 每次进行老年代回收时也会进行永久代回收。它们之中任何一个变满时，都会进行回收。

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

虚拟地址

在OS层面一般是由逻辑地址映射到线性地址，如果线性地址管理，如果启动了分页，那么线性地址就会转换到相应的物理地址上，否则就直接认为是物理地址；程序设计中所用到的地址单元就是逻辑单元，如在C语言中的&表示指定的地址就是逻辑地址；而物理地址也并非我们所认为的RAM，还应该包括网卡、显存、SWAP等相关内容，也就是由OS所管理所有可以通过顶层逻辑单元映射到的目标地点，不过绝大部分情况下只需要考虑RAM即可，尤其是在服务器上；JVM的虚拟内存地址和操作系统的虚拟内存地址不是一个概念，操作系统的虚拟内存地址相当于在磁盘上划分的一个SWAP交换区，用于内存，内存与之做page out和page in的操作，这种用于物理内存本身不够，而地址空间够用的情况，一旦程序出现page out这些情况的时候，程序将会变得非常缓慢，而JVM的虚拟内存是在有效的空间内分配一个连续的线性地址空间，因为JVM想要自己管理内存，分配的堆内存都是在自己的heapSize内部，因为它要实现一些脱离于存储器本身对非连续堆处理的管理而导致的复杂性，也就是JVM去初始化的时候就会加载一块很大的内存单元，然后内部的操作都是内部自己完成的。

内存分配

一般C语言分配内存是初始化将相应的基本内容和代码段进行加载，但是不会加载运行时候的堆栈内存分配，也就是在运行到某个具体的函数时通过malloc、callloc、realloc等方方申请的区域，这些区域必须从操作系统中重新来分配，使用完成后必须进行free，C++中必须使用delete方法来释放，大家发现没有，OS的堆在内存不断申请和释放的过程中，必然会产生许多的内存碎片，从而导致你在申请一块大内存的时候，需要进行 逻辑连接，导致在申请的速度减小，当然LINUX采用了将内存块划分为多个不同大小的板块，来较好的处理这个问题，不过片段还是存在的，不过这种思想的确 是很好的，而JVM是如何完成碎片的处理的呢，后面章节会说到；JVM在初始化的时候就会向OS申请一块大内存，JVM要求这块内存在地址空间上是连续的(物理上未必连续)，让所有的程序在这个内部区分配，由自己来管理，所以它内部相当于做了一个小的OS对内存的管理，所以JVM是想让java程序员不用 关心在哪一个平台上写代码，但是你一定要关心java怎么管理内存的； 线性地址随着实际物理内存的增加，将会导致页表非常大，甚至于导致多层页表，如内存达到96G这一类，那么这样管理起来将会非常麻烦(正常情况下一 个页只有4K，可以自己算一下需要多少个管理地址来指向这个4K，这个管理地址太大的时候，又需要其他的管理地址来管理这个地址，就会导致多层地址，可能 到最后，一个大内存有40%都是用于管理内存的，真正使用的可想而知)，所以在LINUX高版本中对于内存寻址方面做了改进，就是支持大页面来支持(其实 是通过一个套件完成的，并非OS本身)，如一个页的大小为1M这样的，但是有一些风险在里面，它要求大页面内存要么放得下你的内存，但是你不能将你的进程 一部分放在大页面内存中，一部分放在OS管理的小页面内存中，也就是说要么这块放得下，要么就放在其他地方，可能会导致两边正好都差那么一点点的问题，在OS这边可以使用SWAP，但是系统会很慢，而且SWAP很多的情况下肯定会宕机掉。

内存分配状态

一个大的进程如果初始化需要分配一块大的内存空间，内存空间一般会经历两个状态的转换过程，首先内存必须是free状态才可以被分配，如果的确是该状态并 且空间是够用的，那么它首先会占用那么大一个坑，在java的heapSize中，就是-Xmx参数指定的，也就是JVM虚拟机最大的内存空间(注意这里-Xmx并没有包含PermSize的空间)，这个坑是不允许其它进程所占用的，内存的状态为：reserved的状态，当需要使用的空间时，内存将会被commited状态，在JVM初始化时也就是-Xms状态的内存空间，处于这个状态的内存如果发现不够使用(物理内存)，此时就会发生swap区域，程 序将会变得非常缓慢，但是不会造成宕机，而很多时候在这个时候定位不出原因，所以我们为了让物理内存不够用的现象暴露出来可以被发现，至于可以定位不是程 序代码的问题，我们就直接将swap内存禁用掉；有个问题就是既然被reserved的内存就不能被其他进程所占用，为什么要在这两个状态之间来回倒腾 呢？这不是多一个开销吗？JVM在来回倒腾的过程中会导致每个区域的容量发生相应的变化，必然导致的是FullGC的过程，那么JVM一般在服务器端如何 设置呢？文章后面逐步细化说明。

Eden:优先分配新生成对象

新生成对象在HeapSize中变化

Java中常见的创建对象的方式有使用new关键字进行创建，也可以使用java.lang.Class.forName进行动态加载。JVM在向OS请求地址列表后，即需要进行初始化，启动进程或者其他子进程。譬如C或者C++中会将相应的全局变量以及代码段等内容在内存中进行编译为相应的指令集，而JVM中会将Main类以及通过import引入的关联项形成大的JVM网状结构，保证每个Class都有一份自己的私有池并且放在PermSize或者MetaSpace中。不过动态装在的Class不是在JVM初始化的时候存入PermSize或者MetaSpace，而是在运行时动态装载进去。动态装载负责的是运行时装载一些类的定义，而不是初始化，当然，当你通过全名去加载的时候，他们会从 符号向量中寻找这个类是否已经加载，如果已经加载则直接使用，否则从相应的包中获取这个Class定义，然后装载起来，装载的单位也是以Class为单位，并不是以jar包为单位，这里请大家如果不要滥用动态加载，一个是造成Perm的不稳定，另一个是它的效率肯定没有new高，因为它需要先去通过符号 向量寻找是否存在，不存在再加载，然后再通过newInstance实例化一个或多个实例，当然在某些特殊的时候，利用它可以为你的程序带来极高的灵活 性。 在JVM的初衷中，它希望新申请的内存是连续的，虽然堆的定义是让内存是随机分配的，但是对 于整个JVM来说，它希望分配的内存是较为连续的，也就是按照较为条带化的方式进行分配，好处有好几个，一个是这样非常的简单，经过精简后的情况目前一个new翻译为机器码只需要10条左右的指令码，近乎与C语言，所以在高版本的jdk中，new的开销不再是java虚拟机慢的一个原因，大家也没有必要去 尽量减少new，但是也不要滥用，业绩虽乱定义不必要的对象；其次，另一个好处，当内存较为连续后，内存在分配上就没有类似的大量碎片的问题，造成运行一 段时间后，大量碎片，当需要申请一个大内存的时候，需要寻找非常多的地方才能将其逻辑上组成，而导致分配空间上不必要的浪费；而一个简单内存分配String a = new String(“abc”);，这样一条代码，会做什么动作呢？a相当于是对象的一个指针一样的东西，这个空间的大小为一个long的长度，也就是可以支持到可以想象的任何内存大小，它 并不是存放在heapSize中的，而是放在stack中的，由OS来调度管理，也就是当a的作用区域完成，这个指针将会断开，java中的String不再是C或者C++中的一个指针指向的一个字符数组，而是一个被包装后的对象，也就是java为什么说自己都是对象，因为它把原生态的内容进行了包装，让 程序编写更加简单；这里顺便提及一下：在较早期的jdk中，jvm并不是由一个指针直接指向分配堆中的首地址，而是先有一个handle空间，这个空间存 放了开始说的一些对象的定义和结构信息，也就是找到该位置，然后由该位置转换到对应的对象上，但是那个时候的对象头部信息就没有现在的那么全，也就是以前 是将一部分handle内容放置在独立的空间上，现在的jdk已经没有那样的了。

Minor GC

大多数情况下，对象在新生代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倍以上。

    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.

大对象直接进入老年代

所谓大对象就是指，需要大量连续内存空间的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.

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

虚拟机既然采用了分代收集的思想来管理内存，那内存回收时就必须能识别哪些对象应当放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每 个对象定义了一个对象年龄(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的空间被占用。

    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.

动态对象年龄

 在说明下，以下三种情况对象会被晋升到old区域：
 1、在eden和survivor中可以来回被minor gc多次，这个次数超过了-XX:MaxTenuringThreshold
 2、在发生minor gc时，发现to survivor无法放下这些对象，就会进入old。
 3、在新申请对象，大于eden区域的一半大小时直接进入old，也可以专门设置参数-XX:PretenureSizeThreshold这个参数指定当超过这个值就直接进入old。


 当上面的对象被移动到了Tenured区域，这个区域一般非常大，占用了HeapSize的绝大部分空间，此时若它发生一次内存回收，就不能像刚才那样来 回拷贝了，那样代价太大，而且这个区域可以说是经得起考验的对象才会被移动过来，在概率上是不容易被销毁掉的对象才会被移动过来；那么，我们很此时想到的 就是反过来计算，也就是找到需要销毁的对象，将其销毁，关于算法也是下面第三章要说的内容，总之对象会在这里存放着。

为了能更好地适应不同程序的内存状况，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。 执行代码清单3-6中的testTenuringThreshold2()方法，并设置参数-XX: MaxTenuringThreshold=15，会发现运行结果中Survivor的空间占用仍然为0%，而老年代比预期增加了6%，也就是说allocation1、allocation2对象都直接进入了老年代，而没有等到15岁的临界年龄。因为这两个对象加起来已经达到了512KB，并且 它们是同年的，满足同年对象达到Survivor空间的一半规则。我们只要注释掉其中一个对象的new操作，就会发现另外一个不会晋升到老年代中去了。

    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.

空间分配担保

在发生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。

    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]

Links

• 垃圾收集器与内存分配策略——在线文字版