概述
程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中每个栈帧分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法或线程结束时，内存自然就跟随者回收了。
Java堆和方法区则不一样，一个接口的多个实现类需要的内存可能不一样，一个方法的多个分支需要的内存也可能不一样，只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，所以垃圾收集器主要关注的也是这部分内存区域。
判断对象是否存活
判断对象是否存活的两种方法：
- 引用计数法
- 可达性分析
引用计数法
给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一，任何时刻计数器为0的对象就是不可能再被使用的。在主流的Java虚拟机里没有选用引用计数法来管理内存，其中最主要的原因是它无法解决对象之间相互引用的问题。
public class ReferenceCountingGC{
public Object instance = null;
private static final int _1MB = 1024 * 1024;
private byte[] bigSize = new byte[2 * _1MB];
public static void main(String[] args){
ReferenceCountingGC objA = new ReferenceCountingGC(); // 对象①
ReferenceCountingGC objB = new ReferenceCountingGC(); // 对象②
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
System.gc();
}
}
如果Java虚拟机使用的是引用计数法，那么对象①和对象②各被引用了两次（例如对象
①被objA和objB.instance引用），即使之后使用objA = null，计数器减一，现在对象①引
用计数器的值让然不为0，，所以调用System.gc()之后，对象①和对象②不会被回收。但实
际上，在启动GC之后，对象①和对象②均被回收了，这也从侧面反映出虚拟机并不没有采用
引用计数法来判断对象是否存活的。
可达性分析
在主流的商用虚拟机中，都是使用称为可达性分析的算法来判断对象是否存活的，该算法的基本思想是：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个节点到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
在Java语言中，可作为GC Roots的对象包括以下几种：
- 虚拟机栈的栈帧中本地变量表中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI引用的对象
再谈引用
无论是引用计数法还是可达性分析，判断对象是否存活都与“引用”有关。在JDK1.2之后，Java对引用的概念进行了扩展，将引用分为强引用<==软引用<==弱引用<==虚引用。
- 强引用：是Java默认的引用类型，指代码中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象
- 软引用：需要使用java.lang.ref.SoftReference构建，用来描述一些有用但并非必须的对象。对于软引用关联着的对象，在系统内存不足将要发生内存溢出时，才会回收这部分对象。如果回收之后还没有足够的内存，才会发生内存溢出异常。软引用被广泛应用于缓存。
- 弱引用：需要使用java.lang.ref.WeakReference构建，被软引用关联着的对象只能生存到下一次垃圾收集之前。当垃圾收集器开始工作时，无论当前内存是否充足，都会回收掉被弱引用关联的对象。不要在代码中使用弱引用，因为在使用弱引用时，垃圾收集器启动后，关联的对象将不再存在。
- 虚引用：虚引用也被称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知。
生存还是死亡
即使在可达性分析中不可达的对象，也并非是注定要被回收。要真正判断一个对象死亡，至少要经历一次标记和一次筛选。如果对象在可达性分析中没有与GC Roots相连的引用链，那么它将会被标记，并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，如果一个对象被标记了，并且没有必要执行，那么垃圾收集器将会回收该对象的内存。
如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置到一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的，低优先级的Finalizer线程去进行第二次标记。finalize()方法时对象逃脱死亡命运的最后一次机会，如果要在finalize()方法中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，那在第二次标记时它将被移除“即将回收”的集合，如果对象这时候还没有逃脱，那该对象基本上就要被真正的回收了。需要说明的是，finalize方法只会被虚拟机执行一次，所以即使对象在上一次通过finalize方法成功逃脱被回收的命运，那在这一次也将被回收，因为该对象的finalize方法已经被调用过了。
垃圾收集算法
标记-清除算法
标记-清除算法分为“标记”和“清除”两个阶段：首先标记出所有需要被回收的对象，在标记完成后统一回收所有被标记的对象。
标记-清除算法
标记-清除算法存在两个问题：
- 标记、清除两个过程的效率不高；
- 内存碎片问题。
标记-清除之后，会产生大量的不连续的内存碎片，可能会导致后续程序运行过程中需要为大对象分配内存时，无法找到足够的连续内存而不得不提前触发一次垃圾收集动作。
复制算法
复制算法的基本思想是：将可能内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块用完时，就将存活的对象复制到另一块上，再把已使用过的内存一次性清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也不用考虑内存碎片。
复制算法
复制算法的问题是：将整个可用内存划分为大小相等的两块，每次只能使用其中的一 块，降低了内存使用率，使用率只有50%。
新生代中的对象98%都是“朝生夕死”，也就是复制到另一块内存中的存活对象数量在 2%左右。所以也就没有必要按照1:1的比例来划分内存空间，而是将内存划分为一块较大的 Eden空间和两块较小的Survivor空间，每次只使用Eden和其中的一块Survivor。当回收时， 将Eden和Survivor中还存活的对象一次性的复制到另一块Survivor上，最后清理掉Eden和刚 才用过的Survivor空间。在HotSpot虚拟机上Eden与Survivor的比例是8:1，这样空间利用率 就达到了90%。当Survivor空间不足时，需要依赖其他内存进行分配担保。
该算法的缺点是：在对象存活率较高时就需要进行较多的复制操作，效率变低，并且需 要其他内存空间进行分配担保。
标记-整理算法
标记-整理算法分为标记和整理两个过程，其基本思想是：首先，标记出所有需要被回 收的对象。在标记完成之后，将所有存活的对象都向一段移动，然后直接清理掉端边界以外 的内存。
标记-整理算法
分代收集算法
分代收集算法的基本思想是：根据对象存活周期的不同将内存划分为不同的区域，一般 是划分为年轻代和年老代，这样就可以根据各个年代的特点采用最适当的收集算法。在年轻 代中，每次垃圾收集都会有大量的对象死亡，只有少量对象存活，适合采用复制算法，只需 要付出少量对象复制的成本就可完成垃圾收集。在年老代中，因为对象的存活率较高，并且 没有内存空间对它进行分配担保，所以适合采用“标记-清除”或“标记-整理”算法来进行 回收。
垃圾收集器
如果说垃圾收集算法是内存回收的方法论，那垃圾收集器就是内存回收的具体实现。 Java虚拟机规范对于垃圾收集器应该如何实现并没有做具体的规定，因此不同的厂商、不同 版本的虚拟机所提供的垃圾收集可能会有很大的差异，并且一般都会提供参数供用户根据自 己的应用特点和要求组合出各个年代所使用的收集器。下图是JDK 1.7 update 14之后的 HotSpot虚拟机包含的所有收集器。该图展示了7种作用于不同年龄代的收集器，如果两个收 集器之间存在连线，就说明它们之间可以搭配使用。收集器所处的区域，则表示它是年轻代 收集器还是老年代收集器。
垃圾收集器
并行：指多条垃圾收集线程可以同时执行，但此时用户线程仍处于等待状态
并发：指用户线程与垃圾收集线程可以同时执行
Serial 收集器
Serial 是年轻代的收集器，使用单线程和复制算法。Serial 收集器只会使用一个CPU 或一条收集线程去完成垃圾收集工作。在进行垃圾收集时，必须暂停其他所有的工作线程， 直到收集结束。这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的 情况下把用户正常工作的线程全部停掉。
Serial 收集器的工作过程如下图所示：
Serial 收集器
虽然Serial 收集器存在一些问题，但它仍然是虚拟机运行在Client模式下默认的新生 代垃圾收集器。简单高效：对于限定在单个CPU的环境来说，Serial 收集器由于没有线程切 换的开销，专心做垃圾收集自然可以获得最高的单线程收集效率；在用户的桌面应用场景 中，分配给虚拟机管理的内存一般不大，停顿时间不会太长，只要不是频繁的发生，这点停 顿是可以接受的。
ParNew 收集器
ParNew 收集器其实就是Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之 外，其余行为包括Serial 收集器可用的所有控制参数、收集算法、Stop The Word、对象分 配规则、回收策略等都与Serial 收集器完全一样，在实现上，这两种收集器也共用了相当 多的代码。
ParNew 收集器的工作过程如下图所示：
ParNew 收集器
ParNew 收集器是许多运行在Server模式下的虚拟机中首选的年轻代收集器，其中很重 要的原因是，除了Serial 收集器外，目前只有ParNew收集器能够与CMS收集器配合工作。
ParNew收集器在单CPU的环境中绝对不会有比Serial 收集器更好的效果，甚至存在线程 交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分百地保证可以 超越Serial 收集器。在多CPU的环境下，它默认开启的收集线程数与CPU的数量相同，在CPU 非常多的环境下，可以使用-XX:ParallelGCThreads参数来设置垃圾收集的线程数。
Parallel Scavenge 收集器
Parallel Scavenge 是新生代收集器，使用多线程和复制算法，其目标是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码与CPU总消耗时间的比值，即吞吐量=运行用户代码的时间 / (运行用户代码的时间 + 垃圾收集时间)，例如虚拟机总共运行了100分钟，其中垃圾收集的时间为1分钟，则吞吐量就是99%。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能够提升用户体验，而高吞吐量则可以高效率的利用CPU时间，尽快完成计算任务，主要适合在后台运算而不需要太多交互的程序。
为了精确控制吞吐量，Parallel Scavenge 收集器提供了两个主要参数，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及设置吞吐量大小的-XX:GCTimeRatio参数。
MaxGCPauseMillis参数允许的值是一个大于零的毫秒数，收集器将尽可能保证内存回收花费的时间不超过设定的值。该参数不一定设置的越小越好，如果设置的过小，那么垃圾收集的频率就会增加，反而可能会导致吞吐量的下降。
GCTimeRatio参数的值应当是一个介于0和100之间的整数，代表垃圾收集时间占总时间的比率。假设该值为x，则允许最大的垃圾收集时间为 1/(1 + x)。
Parallel Scavenge 收集器还提供了-XX:+UseAdaptivePolicy参数，当打开这个参数之后，就不需要手动指定年轻代大小、Eden与Survivor的比例、晋升老年代对象大小的细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式成为GC自适应的调节策略。GC自适应的调节策略是Parallel Scavenge 收集器与ParNew 收集器的一个重要区别。
Parallel Scavenge 收集器的工作流程如下所示：
Parallel Scavenge 收集器
Serial Old 收集器
Serial Old 是Serial 收集器的老年代版本，使用单线程和“标记-整理”算法。在Server模式下，主要有两大用途：配合年轻代的Parallel Scavenge 收集器使用；作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure 时使用。在Client 模式下，是老年代的默认收集器。
Serial Old 收集器的工作流程如图所示：
Serial Old 收集器
Parallel Old 收集器
Parallel Old 是Parallel Scavenge 收集器的老年代版本，使用多线程和“标记-整理”算法。在Parallel Old 收集器出现之前，如果年轻代使用了Parallel Scavenge 收集器，那么老年代除了Serial Old 收集器之外别无选择。由于老年代的Serial Old 收集器在服务器性能上的拖累（Stop The World），即使在年轻代使用Parallel Scavenge 收集器也未必能在整体应用上获得吞吐量最大化的效果。由于Serial Old 收集器无法利用多CPU的处理能力，在老年代比较大并且硬件比较集中的环境下，这种组合也未必能够有ParNew + CMS的组合“给力”。在Parallel Old 收集器出现之后，Parallel Scavenge 能够与Parallel Old 收集器搭配使用。在注重吞吐量及CPU资源敏感的场合，可以优先考虑使用该组合。
Parallel Old 收集器的工作过程如下所示：
Parallel Old 收集器
CMS 收集器
CMS收集器是一种以获得最短停顿时间为目标的收集器。目前很大一部分Java应用集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户较好的体验。CMS收集器就非常符合这类应用的需求。
CMS（Concurrent Mark Sweep）是基于“标记-清除”算法实现的，整个过程分为4个步骤：
- 初始标记（CMS initial mark）：单线程、Stop The World
- 并发标记（CMS concurrent mark）：单线程，可以与用户线程并发执行
- 重新标记（CMS remark）：多线程、Stop The World
- 并发清除（CMS concurrent sweep）：单线程，可以与用户线程并发执行
其中初始标记、重新标记两个步骤仍然需要“Stop The World”。初始标记阶段仅仅只是标记一下GC Roots能够直接关联到的对象，速度很快；并发标记阶段就是进行GC RootsTracing的过程；重新标记阶段则是为了修正并发标记期间因用户程序继续执行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长，但远比并发标记阶段的时间短；并发清除则是使用多线程并发清除不需要的对象并回收这些对象所占用的空间。由于耗时最长的并发标记和并发清除过程收集线程都可以与用户线程并发执行，所以从整体上看，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的工作流程如下所示：
CMS收集器
CMS收集器的缺点
CMS收集器主要存在以下3个主要问题：
- 内存碎片
- Concurrent Mode Failure
- 浮动垃圾
- 降低应用程序性能
内存碎片
由于CMS收集器是基于“标记-清除”算法实现的，在收集结束时会有大量的内存碎片产生。内存碎片过多时，在为大对象分配内存时，如果不能找到一块足够大的连续的内存空间，那么将不得不提前启动一次垃圾收集操作。如果收集之后仍然没有足够的内存空间，那么将会产生OOM异常。为了解决这个问题，CMS收集器提供了-XX:+UseCMSCompactAtFullCollection参数（默认开启），用于在进行Full GC时开启内存碎片的合并整理过程，合并整理过程是无法并发的，也就是说在进行合并整理时，用户线程将被停止。这种解决办法导致的后果是：虽然内存碎片没有 了，但是停顿时间变长了。如果每次进行Full GC时都进行内存的合并整理，因为要暂停用户线程，显然会降低CMS收集器的性能。所以，CMS收集器还提供了一个参数：-XX:+CMSFullGCsBeforeCompaction，该参数的作用是进行多少次不带压缩的Full GC之后，跟着来一次带压缩的，该参数的默认值为0，表示每次进行Full GC时都进行碎片整理。
Concurrent Mode Failure
由于在垃圾收集阶段用户线程还在运行，那就需要预留足够的空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间用户线程使用。要是CMS运行期间预留的内存无法满足程序的需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。在HotSpot虚拟机中提供参数-XX:+CMSInitiatingOccupancyFraction，用来控制预留空间的阈值。在JDK 1.5中，该参数的默认值为68%，也就是说，当预留空间不足32%时，将启动一次内存回收。在JDK 1.6中，该参数的默认值已经提高到了92%。该参数的值不能设置的太高，否则预留的空间将会变小，容易导致大量的“Concurrent Mode Failure”失败，性能反而降低。
浮动垃圾
由于CMS并发清除阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC 时再清理掉，这一部分垃圾称为“浮动垃圾”。浮动垃圾会占用预留空间，因此也会产生“Concurrent Mode Failure”失败。
降低应用程序性能
CMS收集器在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部CPU资源而导致应用程序变慢，总吞吐量降低。CMS收集器默认启动的回收线程数是（CPU数量 + 3）/4，也就是当CPU数量在4个以上时，并发回收时垃圾收集线程占用的CPU资源不少于25%，并且随着CPU 数量的增加而下降。但是当CPU 数量不足4个时，CMS对用户程序的影响就会很大，如果本来CPU负载就比较大，还分出一半的运算能力去执行垃圾收集线程，就可能导致用户程序的执行速度忽然降低了50%。垃圾收集线程占用的CPU资源等于 1 / 4 + 3 / (4 * CPU 数量) ，因此，当CPU数量越多时，CMS对程序的影响越小，反之影响越大。
内存分配策略
Java 技术体系中所提倡的自动内存管理最终可以归结为自动化解决两个问题：给对象分配内存以及回收分配给对象的内存。关于回收内存，已经在之前的虚拟机中的垃圾收集器收集器体系以及运作原理中介绍了。现在所讲的内容都是关于如何为对象分配内存的。对象的内存分配，往大方向讲，就是在堆上分配，对象主要分配在年轻代的Eden 区上，如果启动了本地线程分配缓冲，将按线程有限在TLAB 上分配。分配的规则并不是百分百确定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。
对象优先在Eden 分配
大多数情况下，对象在年轻代的Eden 区中分配内存。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。执行垃圾收集之后，如果Eden中的空间仍然不足，虚拟机就会采用分配担保的方式将Eden 区中的对象复制到老年代，为新对象腾出空间。
示例代码：
private static final int _1MB = 1024 * 1024;
/*
* VM 参数 ：-verbose:gc -XX:+PrintGCDetails -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC
*/
@Test
public 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 (Allocation Failure) [DefNew: 6743K->1024K(9216K), 0.0048408 secs] 6743K->1087K(19456K), 0.0048719 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [DefNew: 7323K->0K(9216K), 0.0117389 secs] 7387K->6987K(19456K), 0.0117843 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
Heap
def new generation total 9216K, used 4235K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K, 51% used [0x00000007bec00000, 0x00000007bf022f18, 0x00000007bf400000)
from space 1024K, 0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
to space 1024K, 0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
tenured generation total 10240K, used 6987K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
the space 10240K, 68% used [0x00000007bf600000, 0x00000007bfcd2d38, 0x00000007bfcd2e00, 0x00000007c0000000)
Metaspace used 4680K, capacity 5130K, committed 5248K, reserved 1056768K
class space used 548K, capacity 562K, committed 640K, reserved 1048576K
解释说明
-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 参数将堆空间设置为20MB，不可扩展，其中年轻代占用10M，老年代占用10M，Eden与Survivor的比例是8:1:1，所以Eden 区占用8MB，Survivor 区占用1MB。allocation1, allocation2, allocation3三个对象共占用6MB，通过[DefNew: 6743K->1024K(9216K), 0.0048408 secs]可知分析正确（两个Survivor一次只能使用一个，所以年轻代的大小为9MB）。由于Eden 区为8MB，当为allocation4 对象分配内存时，年轻代空间不足，将会启动Minor GC，由于 allocation1, allocation2, allocation3无法被会回收，又不能被移动到Survivor（因为Survivor只有1MB），所以虚拟机将allocation1, allocation2, allocation3 移动到了老年代，通过 tenured generation total 10240K, used 6987K 、from space 1024K, 0%、to space 1024K, 0% 可知分析正确。这时 年轻代就有了足够的空间存放 allocation4 对象，通过 eden space 8192K, 51% used 可知，分析正确。
大对象直接进入老年代
所谓的大对象是指，需要大量连续内存空间的Java 对象，最典型的大对象就是那种很长的字符串以及数组。经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来存放它们（比遇见大对象更坏的就是遇到一群“朝生夕灭”的“大对象”）。
虚拟机提供了-XX:PretenureSizeThreshold 参数，令大于这个设置值得对象直接在老年代分配。这样做的目的是避免在Eden 区以及两个Survivor 区之间发生大量的复制（年轻代中的复制算法）。之所以要避免“朝生夕灭”的“大对象”，就是因为这些会被直接分配到老年代，而Full GC 的速度要比Minor GC 慢十倍以上，而且还会出现 Stop The World 问题。
代码清单：
private static final int _1MB = 1024 * 1024;
/**
* VM 参数 ：-ea -XX:PretenureSizeThreshold=3145728 -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC
*/
@Test
public void testPretenureSizeThreshold(){
byte[] allocation = new byte[5 * _1MB];
}
执行结果：
Heap
def new generation total 9216K, used 6918K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K, 84% used [0x00000007bec00000, 0x00000007bf2c1a80, 0x00000007bf400000)
from space 1024K, 0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
to space 1024K, 0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
tenured generation total 10240K, used 5120K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
the space 10240K, 50% used [0x00000007bf600000, 0x00000007bfb00010, 0x00000007bfb00200, 0x00000007c0000000)
Metaspace used 4671K, capacity 5130K, committed 5248K, reserved 1056768K
class space used 548K, capacity 562K, committed 640K, reserved 1048576K
解释说明：
通过 tenured generation total 10240K, used 5120K 可以得知，虽然 Eden 区有8MB 足够容纳allocation 对象，但是该对象还是在老年代中分配了内存。
长期存活的对象将进入老年代
虚拟机给每个对象定义了一个对象年龄计数器，如果独享在Eden 出生并经过第一次Minor GC 后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor 中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增到一定程度（默认15岁），就将会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold 设置。
动态对象年龄判断
为了能更好地使用不同程序的内存情况，虚拟机并不是永远地要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代，如果Survivor 空间中相同年龄的所有对象大小总和大于Survivor 空间的一半，那么年龄大于或等于该年龄的对象就可以直接进入老年代，无须等待MaxTenuringThreshold中要求的年龄
空间分配担保
在发生Minor GC 之前，虚拟机会先检查老年代最大可用的连续内存空间是否大于等于年轻代中所有对象总空间，如果这个条件成立，那么就会执行Minor GC，并且本次Minor GC 可以确保是安全的；如果条件不成立，那么虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，并且老年代最大可用的连续内存空间大于历次晋升到老年代对象的平均大小，如果大于，那么虚拟机将尝试执行本次的Minor GC，尽管这次Minor GC 是不安全的；如果小于，或者HandlePromotionFailure设置值为false（即不允许冒险），那么这时需要将Minor GC改为Full GC。
垃圾收集器参数总结
| 参数 | 含义 |
|---|---|
| UseSerialGC | 虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old 的收集器组合进行内存回收 |
| UseParNewGC | 打开此开关后，使用ParNew + Serial Old 的收集器组合记性内存回收 |
| UseConcMarkSweepGC | 打开此开关后，使用ParNew + CMS + Serial Old 的收集器组合进行内存回收 |
| UseParallelGC | 虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old 的收集器组合进行内存回收 |
| UseParallelOldGC | 打开此开关后，使用Parallel Scavenge + Parallel Old 的收集器组合进行内存回收 |
| UseAdapterSizePolicy | 使用GC 的自适应动态调整，尽在Parallel Scavenge 收集器中生效 |
| HandlePromotionFailure | 是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden 和Survivor 区的所有对象都存活的极端情况 |
| ParallelGCThreads | 设置并行GC时进行内存回收的线程数 |
| GCTimeRatio | GC时间占总时间的比例，默认值为99，即允许不超过1%的GC时间。仅在使用Parallel Scavenge 收集器时生效 |
| MaxGCParallelMillis | 设置GC的最大停顿时间。仅在使用Parallel Scavenge 收集器时生效 |
| CMSInitiatingOccupancyFraction | 设置在老年代空间被使用多少后触发垃圾收集，JDK 1.5 的默认值为68%，JDK 1.6之后默认值为92%。仅在使用CMS 收集器时生效 |
| UseCMSCompactAtFullCollection | 设置收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅在使用CMS 收集器时生效 |
| CMSFullGCsBeforeCompaction | 设置收集器在进行若干次收集后再启动一次内存碎片整理。仅在使用CMS 收集器时生效 |
| 参数 | 含义 |
|---|---|
| SurvivorRadio | 设置Eden区与Survivor区的内存比例，默认为8:1:1 |
| PretenureSizeThreahold | 直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接进入老年代 |
| MaxTenuringThreshold | 设置晋升到老年代对象的年龄，每个对象在坚持过一次Minor GC 之后，年龄就加1，当超过这个参数值时就进入老年代 |
网友评论