JVM内存区域学习笔记

工作中时常需要根据Java虚拟机的知识来分析问题，不赖相关的知识总是学了忘，忘了学，为了加深和巩固这块知识，特意把周志明老师《深入理解Java虚拟机：JVM高级特性与最佳实践》书中的知识记录下来，以供参考。

1. JVM 运行时数据区

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域，这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有的区域依赖用户线程的启动的结束而建立和销毁。根据《Java虚拟机规范》的规定，JVM所管理的内存包括以下几个运行时数据区域：

• 程序计数器

  程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

  由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器，各个线程之间计数器互不影响。

• Java虚拟机栈

  与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：线程方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链表、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈和出栈的过程。

  在Java虚拟机规范中，对这个区域规定了两种异常情况：如果线程请求的栈的深度大于虚拟机所允许的深度，将抛出StackOverflowException异常；如果虚拟机栈可以动态扩展（当前大部分JVM都可以动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryException异常。

• 本地方法栈

  本地方法栈与Java虚拟机栈所发挥的作用类似，它们的区别不过是虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为虚拟机使用到的Native方法服务。与虚拟机栈一样，本地方法栈也会抛出StackOverflowException与OutOfMemoryException异常。

• Java堆

  Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的主要目的就是存在对象实例，几乎所有的对象实例都在这里分配内存。

  Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做GC堆。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为新生代（young区）和老年代（old区）；再细致一点新生代还可以分为Eden区与两个Survivor区。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。

  在创建对象时，如果堆中没有足够的内存完成实例分配，并且堆也无法扩展时，将会抛出OutOfMemoryException异常。

• 方法区

  方法区与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

  相对而言，垃圾收集行为在这个区域是不常见的，但并非数据进入方法区就如永久代的名字一样“永久”存在了。这个区域的回收目标主要针对常量池的回收和对类型的卸载，一般来说，这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是必要的。

  运行时常量池

  运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

  运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。

  既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常池量无法再申请到内存时会抛出OutOfMemoryException异常。

2. 对象的创建

虚拟机遇到一条new指令时，首先会去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，就先执行相应的类加载 过程。

接下来虚拟机将为新生对象分配内存，对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务相当于把一块确定大小的内存从Java堆中划分出来。假设Java堆中内存是绝对规整的，所有用过到内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那样分配内存就是仅仅把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为指针碰撞。如果Java堆中的内存并不是规整的，虚拟机就必须维护一个列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象，并更新列表上的记录，这种分配方式称为空闲列表。

选择哪些分配方式由Java堆是否规整决定，而Java堆是否规整取决于所采用的垃圾收集器是否带有整理（Compact）功能决定。因此，在使用Serial、ParNew等带有压缩过程的收集器时，系统采用的分配方式是指针碰撞，而使用像CMS这种基于Mark-Sweep算法的收集器时，通常采用的是空闲列表。

内存分配完成后，虚拟机需要将分配到内存空间初始化为0值（不包括对象头)。接下来，虚拟机还要对对象进行必要的设置，如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息，这些信息都存放在对象头中。

上面的工作完成后，从虚拟机的视角来看，一个新的对象产生了，但是从Java程序的视角来看，对象的创建才刚刚开始——<init>方法还没有执行，所有的字段都还为零。一般来说，执行new指令之后会接着执行<init>方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

3. 哪些对象可以回收

在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，首先要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。判断对象是否还“存活”着，有两种方法：引用计数算法与可达性分析算法。

引用计数算法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的、可以被安全回收的对象。

但是引用计数算法有个很明显的缺陷，它很难解决解决对象之间相互循环引用的问题，比如下面的例示中对象a与b都不能回收，但是他们其实已经不可能再被使用了。

SomeObject a = new SomeObject();
SomeObject b = new SomeObject();

a.pointTo = b;
b.pointTo = a;

a = null;
b = null;

可达性分析算法

这个算法的基本思路就是通过一系列的称为根节点（GC root）的对象作为起始点，从这些根节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC root没有任何的引用链相连（GC root到这个对象不可达）时，说明这个对象是不可用的、可以被安全回收的对象。

在Java语言中，可作为GC root的对象有： * 虚拟机栈中（栈帧中的本地变量表）中引用的对象。 * 方法区中类静态属性引用的对象。 * 方法区中常量引用的对象。 * 本地方法栈中JNI引用的对象。

引用类型

在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用与虚引用四类：

• 强引用(Strong Reference)

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

• 软引用（Soft Reference）

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

• 弱引用（Weak Reference）

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

• 虚引用（Phantom Reference）

  一个对象是否有虚引用的存在，完全不会对其生存时间造成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

4. 垃圾收集算法

标记－清除算法

“标记－清除”（Mark-Sweep）算法是最基础的算法，它分“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

“标记－清除”算法有两个不足：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片大多可能会导致分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制算法

为了解决“标记－清除”算法效率上的不足，一种称为“复制”的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当一块的内存用完了，就将还存活的对象复制到另一块，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，简单高效。

由于新生代中的对象都是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

如果在回收时，一块Survivor的空间不足于容纳Eden与另一块Survivor中存活的对象，那这些对象将通过分配担保机制进入老年代。

标记－整理

“标记－整理”（Mark-Compact）算法在标记过程与“标记－清除”一样，但后续步骤不是直接对可回收的对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

现代虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代与老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，所以“复制”算法就比较合适；而老年代中因为对象存活率高、没有额外的空间对它进行分配担保，就必须使用“标记－清理”或“标记－整理”算法进行回收。

5. 垃圾收集器

Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。JDK1.7 Update 14之后的虚拟机包含的收集器如下：

上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，说明它们可以搭配使用。虚拟机所处的区域，表示它是属于新生代收集器还是老年代收集器。不同的收集器有其不同的特点，我们只能根据具体应用的特点来选择最合适的收集器。没有最好的收集器，只有最合适的收集器。

Serial收集器

从名字就知道，这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

对于桌面应用场景中，分配给虚拟机管理的内存一般不会很大，几十兆的至一两百兆的新生代，停顿时间完全可以控制在几十毫秒，只要不是频繁发生，是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个不错的选择。

ParNew收集器

ParNew收集器其实就是Serial的多线程版本，除了使用多个线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（如：-XX:SurvivorRatio、-XX:PretunureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop the World、对象分配规则、回收策略等都与Serial收集器完全一样。在实现上，这两种收集器也共用了相当多的代码。

ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在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的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的线程数与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew都一样，那它有什么特别之处呢？

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。

所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 ＝ 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体检，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运行任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间为代价的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快，但也导致垃圾收集发生得更频繁了，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量下来了。

GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率。如果把此参数设置为19,那允许的最大GC时间就占总时间的 5%（即1 / (1 + 19)），默认值为99，就是允许最大1%（即1 / (1 + 99)）的垃圾收集时间。

Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集收能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应调节策略（GC Ergonomics）。自适诮调节策略也是Parallel Scavenge与ParNew的一个重要区别。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记－整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两在用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态，原因是如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。

直到Parallel Old收集器出现后，“吞吐量优先”收集器才终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如下所示：

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的要求。

从名字上就可以看出，CMS收集器是基于“标记－清除”算法实现的，它的动作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记与重新标记两个步骤仍然需要“Stop the World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续动作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比如始标记阶段稍长一些，但远比并发标记的时间短。

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

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

• CMS收集器对CPU资源非常敏感。

  其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。

  CMS默认启动的回收线程数是(CPU数量 + 3) / 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数据量的增加而下降。但是当CPU不足4个时，CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的资源去执行垃圾收集，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

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

  由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。

  也是由于垃圾收集阶段用户线程还需要运行，那也就还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能。在JDK1.6k ,CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”，性能反而降低。

• CMS是基于“标记－清理”算法实现的，垃圾收集结束时会有大量空间碎片。

  空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有 很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

  为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认开启），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片的问题没有了，但停顿时间变长了。

  虚拟机还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的。（默认值为0，表示每次进入Full GC时都进行碎片整理）。

6. 内存分配与回收策略

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

对象优先在Eden分配

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

虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出当前的时候输出当前的内存各区域分配情况。

大对象直接进入老年代

大对象对虚拟机的内存分配来说就是一个坏消息（替Java虚拟机抱怨一句，比遇到一个大对象更加坏的消息是遇到一群“朝生夕灭”的“短命大对象”，写程序的时候应当避免），经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。

虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。

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

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

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

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

空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时将进行一次Full GC。

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

注意 JDK 6 Update 24之后，只要老年代的连续空间大于新生代对象总大小或者历次亚升的平均大小就会进行Minor GC，否则将进行Full GC。HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略。