JVM分代垃圾回收策略的基础概念

   由于不同对象的生命周期不一样，因此在JVM的垃圾回收策略中有分代这一策略。本文介绍了分代策略的目标，如何分代，以及垃圾回收的触发因素。
             

为什么要分代

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连 接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比 如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

试想，在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，花费时间相对会长，同时，因为每次回收都需要遍历所有存活对象， 但实际上，对于生命周期长的对象而言，这种遍历是没有效果的，因为可能进行了很多次遍历，但是他们依旧存在。因此，分代垃圾回收采用分治的思想，进行代的 划分，把不同生命周期的对象放在不同代上，不同代上采用最适合它的垃圾回收方式进行回收。

如何分代

如图所示：

 

虚拟机中的共划分为三个代：年轻代（Young Generation）、年老点（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比 较大的。

年轻代:

所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个 Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制 过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时 存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空 的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

年老代:

在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

持久代:

用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如 Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=& lt;N>进行设置。

什么情况下触发垃圾回收

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。

Scavenge GC

一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对 年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因 而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：

· 年老代（Tenured）被写满

· 持久代（Perm）被写满

· System.gc()被显示调用

·上一次GC之后Heap的各域分配策略动态变化

----------------------------------------分割线------------------------------------------

1）Young（年轻代） 
Young被划分为三个区间，Eden区和两个大 小严格相同的Survivor区，其中Survivor区，在某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用。在Young区间变满 的时候，Minor GC就会将存活的对象移到空闲的Survivor区中，根据JVM的策略，在经过几次Minor GC后，任然存活于Survivor区的对象将被移动到Tenured中。 

2）Tenured（年老代） 
Tenured主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured。一般如果系统中用了application级别的缓存，缓存中的对象往往会被转移到这一区间。 

3）Perm（持久代） 
Perm 主要保存class、method、filed等对象，这部分的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到应用服务器的热部署时，有时候 会遇到java.lang.OutOfMemoryError: PermGen space 的错误，造成这个错误的很大原因就有可能是每次热部署后，旧的class没有被卸载掉，这样就造成了大量的class对象保存在了Perm中，这种情况下 一般重新启动应用服务器可以解决问题，或者通过-XX:MaxPermSize=<N> 将持久代大小设大点。 

GC类型 
大略上分以下2种 
1）Minor GC 
一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Minor GC在Eden区清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后再整理Survivor的两个区。 

2）Full GC 
对整个堆进行整理，包括Young、Tenured以及Perm。Full GC比Minor GC要慢，因此应该尽可能减少Full GC。以下几种原因可能导致Full GC： 

• Tenured或Perm被写满
• System.gc被显示调用
• 上一次GC后堆空间分配策略动态调整 

JVM调优参数 
JVM提供了相应的参数来对内存大小、垃圾回收算法进行配置。 

Non-standard Java HotSpot VM Options 
我在32位Windows Server 2003系统8GB物理内存，JDK1.6下测试，最大可设置为1536M，再多JVM就跑不起来了。 

-Xms1536M 设置JVM启动后堆的初始内存（这里配置的JVM堆空间只是Young与Tenured） 
-Xmx1536M 设置JVM启动后堆的最大内存，一般在生产环境中把这两个参数设为相同值，避免在“上一次GC后堆空间分配策略动态调整”而引起Full GC 
-Xss1M 设置每个线程的Java栈大小 
-XX:NewRatio=2 设置Tenured和Young的比值为2:1，这样Eden+2*Survivor=1/3堆内存 
-XX:SurvivorRatio=8 设置Eden和一个Survivor的比值为8:1，这样一个Survivor就占Young区的1/10. 
-XX:PermSize=64M     设置持久代初始内存 
-XX:MaxPermSize=128M  设置持久代最大内存 

详细配置选项见：http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#PerformanceTuning 

垃圾收集器 
JVM给了三种选择：串行收集器、并行收集器、并发收集器。串行收集器对于处理大数据量的情况时性能太低，所以一般选择使用并行收集器和并发收集器。J2SE5.0以后JVM会根据当前系统配置进行判断（机器配置只要有2个CPU和至少2GB的物理内存JVM将自动以-server模式运行） 

1）吞吐量优先的并行收集器，通过 -XX:+UseParallelGC 指定 
2）响应时间优先的并发收集器，主要是保证系统的响应时间，减少垃圾收集时的停顿时间。通过 -XX:+UseConcMarkSweepGC 指定。由于CMS GC是和应用并发执行的，因此需要耗费更多的CPU资源。 

详细配置选项见：http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#BehavioralOptions