JVM Heap主要存放应用实例化的对象，需要动态扩展的对象，不包括简单类型的常量、静态变量。Heap的组成和JDK的实现（主要是GC策略）相关，没有一个统一的结构。

 

基本回收算法

1. 引用计数（Reference Counting）
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。

2. 标记-清除（Mark-Sweep）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。

 

3. 复制（Copying）
此 算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理 正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍 内存空间。

 

4. 标记-整理（Mark-Compact）
此算法结合了 “标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象 “压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。

5. 增量收集（Incremental Collecting）
实施垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。

 

6. 分代（Generational Collecting）
基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。分代算法综合了多种算法的优点，可以根据应用的特点进行针对性的调整。SUN JDK（从J2SE1.2开始）都是使用此算法的。

 

收集方式

串行收集:串行收集使用单线程处理所有垃圾回收工作，因为无需多线程交互，实现容易，而且效率比较高。但是，其局限性也比较明显，即无法使用多处理器的优势，所以此收集适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。

 

 

 

 

并行收集:并行收集使用多线程处理垃圾回收工作，因而速度快，效率高。而且理论上CPU数目越多，越能体现出并行收集器的优势。

 

 

 

 

并发收集:相对于串行收集和并行收集而言，前面两个在进行垃圾回收工作时，需要暂停整个运行环境，而只有垃圾回收程序在运行，因此，系统在垃圾回收时会有明显的暂停，而且暂停时间会因为堆越大而越长。

 

    并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器 会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。

    并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。

    在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。

 

    浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。

 

    Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。

 

GC类型

GC有两种类型：Scavenge GC和Full GC。

1. Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。
2. Full GC
对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC：
* Tenured被写满
* Perm域被写满 (SUN JDK)
* System.gc()被显示调用
* 上一次GC之后Heap的各域分配策略动态变化

 

分代介绍

在GC的分代策略里面，主要分为：

1. Young（年轻代）
年 轻代分三个区。一个Eden区，两个 Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个 Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制 过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时 存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而 且，Survivor区总有一个是空的。
2. Tenured（年老代）
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。

 

在早期的SUN的JDK里面，将方法区（也叫持久代Perm）也放在heap里面，从sun jdk1.5.多少后就挪出来了，懒的去查了，反正用1.5的后期版本都是在heap之外的，有知道的童鞋可以补充下。

 

 

分代垃圾回收流程示意

 

 

根据应用特点选择GC策略

应用根据需求特征可以分为：

1、计算密集型，少交互，大部分时间花在计算上，如OLAP系统

2、交互型，高响应要求，如OLTP系统

 

针对计算密集型应用，他对响应时间要求不高，可以采用吞吐量优先的GC策略

针对交互型应用，他对用户体验要求高，需要采用响应时间优先的GC策略

 

应用还可以根据规模分为：

1、小型应用（单CPU，100M-200M内存）

2、中、大型应用

 

对于小型应用可以采用串行收集，因为没有多个CPU可以并行，本身堆大小也小，收集时间短，效率高。

 

对于SUN的JDK，默认采用的都是分代GC的方式，我们可以在不同的代根据应用特点采用不同的GC策略，一般对于中、大型、响应优先的系统，可以在年轻代采用平行收集策略，在老年代上采用并发收集策略，在最新的JDK中，推出了G1收集器，将代划分的更细，并且综合了并发收集和增量收集的优点。

 

 

 

 

对于IBM的JDK，提供了4种GC策略：

 

-Xgcpolicy:<gencon | optavgpause | optthruput | subpool (AIX®, Linux and IBM® i on IBM POWER® architecture, Linux and z/OS® on zSeries) >   The gencon option requests the combined use of concurrent and generational GC to help minimize the time that is spent in any garbage collection pause.   The optavgpause option reduces the time that is spent in these garbage collection pauses and limits the effect of increasing heap size on the length of the garbage collection pause. Use optavgpause if your configuration has a large heap. Enables concurrent mark.   The optthruput option is the default and delivers high throughput to applications, but at the cost of occasional pauses. Disables concurrent mark.   The subpool option (AIX, Linux and IBM i on IBM POWER architecture, and z/OS) uses an improved object allocation algorithm to achieve better performance when allocating objects on the heap. This option might improve performance on large SMP systems.