JVM垃圾回收
1.简介
jvm要进行垃圾回收粗略分为两个步骤：找出需要清理的内存(无效的内存区域) ， 清理无效的内存区域
程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或线程结束时，内存自然就跟随着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾回收所关注的是这部分内存。
2. 无效内存区域的查找
2.1 概要
Java堆中几乎存放着Java世界中所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象有哪些还“存活”着，哪些已经“死去”。判断方法有引用计数器法和根搜索算法等。2.1.1 引用计数算法
简单解释为给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当该引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。客观地说，引用计数算法（ReferenceCounting）的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如微软的COM（ComponentObjectModel）技术、使用ActionScript3的FlashPlayer、Python语言以及在游戏脚本领域中被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但Java语言中没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间的相互循环引用的问题。如下：/**
*testGC()方法执行后，objA和objB会不会被GC呢？
*@authorzzm
*/
public class ReferenceCountingGC{
public Object instance=null;
private static final int _1MB=1024*1024;
/**
*这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
*/
private byte[] bigSize=new byte[2*_1MB];
public static void testGC(){
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = newReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
//假设在这行发生GC，那么objA和objB是否能被回收？
System.gc();
}
}
运行结果：
[FullGC(System)
[Tenured:0K->210K(10240K),0.0149142secs]
4603K->210K(19456K),
[Perm:2999K->2999K(21248K)],0.0150007secs][Times:user=0.01sys=0.00,real=0.02secs]
Heapdefnewgenerationtotal9216K,used82K
[0x00000000055e0000,0x0000000005fe0000,0x0000000005fe0000)Edenspace8192K,1%used[0x00000000055e0000,0x00000000055f4850,0x0000000005de0000)
fromspace1024K,0%used[0x0000000005de0000,0x0000000005de0000,0x0000000005ee0000)
tospace1024K,0%used[0x0000000005ee0000,0x0000000005ee0000,0x0000000005fe0000)
tenuredgenerationtotal10240K,used210K[0x0000000005fe0000,0x00000000069e0000,0x00000000069e0000)
thespace10240K,2%used[0x0000000005fe0000,0x0000000006014a18,0x0000000006014c00,0x00000000069e0000)
compactingpermgentotal21248K,
used3016K[0x00000000069e0000,0x0000000007ea0000,0x000000000bde0000)
thespace21248K,14%used[0x00000000069e0000,0x0000000006cd2398,0x0000000006cd2400,0x0000000007ea0000)
Nosharedspacesconfigured.代码中testGC()方法：对象objA和objB都有字段instance，赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们，为引用计数器的缺陷。但从运行结果中可以清楚地看到GC日志中包含“4603K->210K”，意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。
2.1.2 根搜索算法
在主流的商用程序语言中（Java和C#，甚至包括前面提到的古老的Lisp），都是使用根搜索算法（GCRootsTracing）判定对象是否存活的。这个算法的基本思路就是通过一系列的名为“GCRoots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（ReferenceChain），当一个对象到GCRoots没有任何引用链相连（用图论的话来说就是从GCRoots到这个对象不可达）时，则证明此对象是不可用的。如下： 
对象object5、object6、object7虽然互相有关联，但是它们到GCRoots是不可达的，所以它们将会被判定为是可回收的对象。
在Java语言里，可作为GCRoots的对象包括下面几种：
·虚拟机栈（栈帧中的本地变量表）中的引用的对象。
·方法区中的类静态属性引用的对象。
·方法区中的常量引用的对象。
·本地方法栈中JNI（即一般说的Native方法）的引用的对象。
2.2 java的引用类型
无论是通过引用计数算法判断对象的引用数量，还是通过根搜索算法判断对象的引用链是否可达，判定对象是否存活都与“引用”有关。在JDK1.2之前，Java中的引用的定义很传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。这种定义很纯粹，但是太过狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态，对于如何描述一些“食之无味，弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存之中；如果内存在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。
JDK1.2之后，Java对引用的概念进行了扩充，并且引用强度不同。如下
| 引用类型 | 概述 |
|---|---|
| 强引用（StrongReference） | 强引用就是指在程序代码之中普遍存在的，类似“Objectobj=newObject()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象 |
| 软引用（SoftReference） | 软引用用来描述一些还有用，但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用 |
| 弱引用（WeakReference） | 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用 |
| 虚引用（PhantomReference） | 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用 |
2.3 对象自救
在根搜索算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经经历两次标记过程：如果对象在进行根搜索后发现没有与GCRoots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那它就真的离死不远了。
/***此代码演示了两点：
*1.对象可以在被GC时自我拯救。
*2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
*@authorzzm
* */
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public static void main(String[] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC(); //对象 第一次 成功 拯救 自己
SAVE_HOOK = null;
System.gc(); // 因为 Finalizer 方法 优先级 很低， 暂停 0. 5 秒， 以 等待 它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println(" no, i am dead :(");
} // 下面 这段 代码 与 上面 的 完全 相同， 但是 这次 自救 却 失败 了
SAVE_HOOK = null;
System.gc(); // 因为 Finalizer 方法 优先级 很低， 暂停 0. 5 秒， 以 等待 它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println(" no, i am dead :(");
}
}
public void isAlive() {
System.out.println(" yes, i am still alive :)");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println(" finalize mehtod executed!");
FinalizeEscapeGC.SAVE_HOOK = this;
}
}
运行结果：
finalize mehtod executed!
yes, i am still alive :)
no, i am dead :(从代码中我们可以看到一个对象的finalize()被执行，但是它仍然可以存活。代码中一次对象自我拯救的演示，在运行结果可以看到，SAVE_HOOK对象的finalize()方法确实被GC收集器触发过，并且在被收集前成功逃脱了。另外一个值得注意的地方就是，代码中有两段完全一样的代码片段，执行结果却是一次逃脱成功，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败了。需要特别说明的是，上面关于对象死亡时finalize()方法的描述可能带有悲情的艺术色彩，笔者并不鼓励大家使用这种方法来拯救对象。相反，笔者建议大家尽量避免使用它，因为它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协。它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。有些教材中提到它适合做“关闭外部资源”之类的工作，这完全是对这种方法的用途的一种自我安慰。finalize()能做的所有工作，使用try-finally或其他方式都可以做得更好、更及时，大家完全可以忘掉Java语言中还有这个方法的存在。
2.4 回收方法区
很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。
java中同时满足下面3个条件才能算是“无用的类”：
·该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
·加载该类的ClassLoader已经被回收。
·该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收。
是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制。可以使用-verbose：class及-XX：+TraceClassLoading、-XX：+TraceClassUnLoading查看类的加载和卸载信息，其中-verbose：class和-XX：+TraceClassLoading可以在Product版的虚拟机中使用，但-XX：+TraceClassLoading参数需要fastdebug版的虚拟机支持。在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
3. 清理无效内存
3.1 垃圾收集算法
由于垃圾收集算法的实现涉及大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此本节不打算过多地讨论算法的实现，只是介绍几种算法的思想及其发展过程。
3.1.1 标记-清除算法
最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程其实在前一节讲述对象标记判定时已经基本介绍过了。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。
它的主要缺点有两个：
一个是效率问题，标记和清除过程的效率都不高；
一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
如下图为执行标记清除算法后的内存区域：
3.1.2 标记-整理算法
标记操作和“标记-清除”算法一致，后续操作不只是直接清理对象，而是在清理无用对象完成后让所有存活的对象都向一端移动，并更新引用其对象的指针。
主要缺点：在标记-清除的基础上还需进行对象的移动，成本相对较高，好处则是不会产生内存碎片。
如下图为执行标记清除算法后的内存区域：
3.1.3 复制算法
为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。
复制算法执行后的内存区域：
3.1.4 分代收集算法
分代收集算法当前商业虚拟机的垃圾收集都采用“分代收集”（GenerationalCollection）算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。
3.2 垃圾收集器
垃圾收集器对比
| 垃圾收集器 | 解释 | 对比 |
|---|---|---|
| Serial收集器 | 新生代复制算法，老年代采用标记整理算法，Serial收集器到JDK1.7为止，它依然是JAVA虚拟机运行在Client模式下的默认新生代收集器。 | 它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率 |
| ParNew收集器 | 新生代复制算法，老年代采用标记整理算法，ParNew收集器其实就是Serial收集器的多线程版本 | ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证能超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。 |
| ParallelScavenge收集器 | 新生代收集器采用复制算法 | Parallel Scavenge 收集 器 的 特点 是它 的 关注 点 与其 他 收集 器 不同， CMS 等 收集 器 的 关注 点 尽可能 地 缩短 垃圾 收集 时 用户 线程 的 停顿 时间， 而 Parallel Scavenge 收集 器 的 目标 则是 达到 一个 可 控制 的 吞吐量（ Throughput）。 |
| Serial Old 收集 器 | Serial Old 是 Serial 收集 器 的 老年 代 版本 标记-整理算法 | 这个 收集 器 的 主要 意义 也是 被 Client 模式 下 的 虚拟 机 使用 |
| Parallel Old 收集 器 | Parallel Scavenge 收集 器 的 老年 代 版本 标记-整理算法 | 注重 吞吐量 及 CPU 资源 敏感 的 场合， 都可以 优先 考虑 Parallel Scavenge 加 Parallel Old 收集 器。 |
| CMS收集器 | CMS（ConcurrentMarkSweep）针对老年代进行回收的GC，标记-清除算法 | 收集器是一种以获取最短回收停顿时间为目标的收集器 |
| G1收集器 | 内存结构变更，相对于CMS的“标记——清理”算法，G1会使用压缩算法，保证不产生多余的碎片。收集阶段，G1会将某个区域存活的对象拷贝的其他区域，然后将整个区域整个回收。 | 服务类型的收集器，目标是多处理器机器、大内存机器。它高度符合垃圾收集暂停时间的目标，同时实现高吞吐量。Oracle JDK 7 update 4 以及更新发布版完全支持G1垃圾收集器。 |
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序继续运行，而垃圾收集程序运行于另一个CPU上。
如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。这里讨论的收集器基于SunHotSpot虚拟机1.6版Update22，这个虚拟机包含的所有收集器如图所示。
HotSpotJVM1.6的垃圾收集器展示了7种作用于不同分代的收集器（包括JDK1.6_Update14后引入的EarlyAccess版G1收集器），如果两个收集器之间存在连线，就说明它们可以搭配使用。在介绍这些收集器各自的特性之前，我们先来明确一个观点：虽然我们是在对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。因为直到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。这点不需要多加解释就能证明：如果有一种放之四海皆准、任何场景下都适用的完美收集器存在，那HotSpot虚拟机就没必要实现那么多不同的收集器了。
3.2.1 Serial收集器
Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。大家看名字就会知道，这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。“Stop The World”这个名字也许听起来很酷，但这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说都是难以接受的。读者不妨试想一下，要是你的计算机每运行一个小时就会暂停响应5分钟，你会有什么样的心情？Serial / Serial Old收集器的运行过程如下：
从JDK 1.3开始，一直到现在最新的JDK 1.7，HotSpot虚拟机开发团队为消除或者减少工作线程因内存回收而导致停顿的努力一直在进行着，从Serial收集器到Parallel收集器，再到Concurrent Mark Sweep（CMS）乃至GC收集器的最前沿成果Garbage First（G1）收集器，我们看到了一个个越来越优秀（也越来越复杂）的收集器的出现，用户线程的停顿时间在不断缩短，但是仍然没有办法完全消除（这里暂不包括RTSJ中的收集器）。寻找更优秀的垃圾收集器的工作仍在继续！
写到这里，笔者似乎已经把Serial收集器描述成一个“老而无用、食之无味弃之可惜”的鸡肋了，但实际上到现在为止，它依然是虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
3.2.2 ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、 -XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，实现上这两种收集器也共用了相当多的代码。ParNew收集器的工作过程如下
ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可称为有划时代意义的垃圾收集器—CMS收集器（Concurrent Mark Sweep，本节稍后将详细介绍这款收集器），这款收集器是HotSpot虚拟机中第一款真正意义上的并发（Concurrent）收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作，用前面那个例子的话来说，就是做到了在你妈妈打扫房间的时候你还能同时往地上扔纸屑。
不幸的是，它作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或Serial收集器中的一个。ParNew收集器也是使用 -XX: +UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用 -XX:+UseParNewGC选项来强制指定它。
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证能超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄就4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
注意 从ParNew收集器开始，后面还将会接触到几款并发和并行的收集器。在大家可能产生疑惑之前，有必要先解释两个名词：并发和并行。这两个名词都是并发编程中的概念，在谈论垃圾收集器的上下文语境中，他们可以解释为： 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序继续运行，而垃圾收集程序运行于另一个CPU上。
3.2.3 ParallelScavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器……看上去和ParNew都一样，那它有什么特别之处呢？
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是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收集器也经常称为“吞吐量优先”收集器。除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。如果读者对于收集器运作原来不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。
3.2.4 Serial Old 收集 器
Serial Old 是 Serial 收集 器 的 老年 代 版本， 它 同样是 一个 单线 程 收集 器， 使用“ 标记- 整理” 算法。 这个 收集 器 的 主要 意义 也是 被 Client 模式 下 的 虚拟 机 使用。 如果 在 Server 模式 下， 它 主要 还有 两大 用途： 一个 是在 JDK 1. 5 及 之前 的 版本 中 与 Parallel Scavenge 收集 器 搭配 使用[ 4]， 另外 一个 就是 作为 CMS 收集 器 的 后备 预 案， 在 并发 收集 发生 Concurrent Mode Failure 的 时候 使用。 这 两点 都将 在后 面的 内容 中 详细 讲解。 Serial Old 收集 器 的 工作 过程 如图 所示。
3.2.5 Parallel Old 收集 器
Parallel Old 是 Parallel Scavenge 收集 器 的 老年 代 版本， 使用 多 线程 和“ 标记－整理” 算法。 这个 收集 器 是在 JDK 1. 6 中 才 开始 提供 的， 在此之前， 新生代 的 Parallel Scavenge 收集 器 一直 处于 比较 尴尬 的 状态。 原因 是， 如果 新生代 选择 了 Parallel Scavenge 收集 器， 老年 代 除了 Serial Old（ PS MarkSweep） 收集 器 外 别无选择（ 还 记得 上面 说过 Parallel Scavenge 收集 器 无法 与 CMS 收集 器 配合 工作 吗？）。 由于 单 线程 的 老 年代 Serial Old 收集 器 在 服务 端 应用 性 能上 的“ 拖累”， 即便 使用 了 Parallel Scavenge 收集 器 也 未必 能在 整体 应用 上 获得 吞吐量 最大化 的 效果， 又因 为 老年 代收 集中 无法 充分 利用 服务器 多 CPU 的 处理 能力， 在 老年 代 很大 而且 硬件 比较 高级的 环境 中， 这种 组合 的 吞吐量 甚至 还不 一 定有 ParNew 加 CMS 的 组合“ 给 力”。 直到 Parallel Old 收集 器 出现 后，“ 吞吐量 优先” 收集 器 终于 有了 比较 名副其实 的 应用 组合， 在 注重 吞吐量 及 CPU 资源 敏感 的 场合， 都可以 优先 考虑 Parallel Scavenge 加 Parallel Old 收集 器。 Parallel Old 收集 器 的 工作 过程 如图所示。
3.2.6 CMS收集器
CMS（ConcurrentMarkSweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。从名字（包含“MarkSweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分如下步骤，
包括：
| 阶段 | 说明 |
|---|---|
| (1) 初始标记 (Initial Mark) | (Stop the World Event,所有应用线程暂停) 在老年代(old generation)中的对象, 如果从年轻代(young generation)中能访问到, 则被 “标记,marked” 为可达的(reachable).对象在旧一代“标志”可以包括这些对象可能可以从年轻一代。暂停时间一般持续时间较短,相对小的收集暂停时间. |
| (2) 并发标记 (Concurrent Marking) | 在Java应用程序线程运行的同时遍历老年代(tenured generation)的可达对象图。扫描从被标记的对象开始,直到遍历完从root可达的所有对象. 调整器(mutators)在并发阶段的2、3、5阶段执行,在这些阶段中新分配的所有对象(包括被提升的对象)都立刻标记为存活状态. |
| (3) 再次标记(Remark) | (Stop the World Event, 所有应用线程暂停) 查找在并发标记阶段漏过的对象，这些对象是在并发收集器完成对象跟踪之后由应用线程更新的. |
| (4) 并发清理(Concurrent Sweep) | 回收在标记阶段(marking phases)确定为不可及的对象. 死对象的回收将此对象占用的空间增加到一个空闲列表(free list),供以后的分配使用。死对象的合并可能在此时发生. 请注意,存活的对象并没有被移动. |
| (5) 重置(Resetting) | 清理数据结构,为下一个并发收集做准备. |
其中初始标记、重新标记这两个步骤仍然需要“StopTheWorld”。初始标记仅仅只是标记一下GCRoots能直接关联到的对象，速度很快，并发标记阶段就是进行GCRootsTracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。ConcurrentMarkSweep收集器运行示意图： 
CMS是一款优秀的收集器，它的最主要优点在名字上已经体现出来了：并发收集、低停顿，Sun的一些官方文档里面也称之为并发低停顿收集器（ConcurrentLowPauseCollector）。但是CMS还远达不到完美的程度，它有以下三个显著的缺点：
·CMS收集器对CPU资源非常敏感。其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程最多占用不超过25%的CPU资源。但是当CPU不足4个时（譬如2个），那么CMS对用户程序的影响就可能变得很大，如果CPU负载本来就比较大的时候，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，这也很让人受不了。为了解决这种情况，虚拟机提供了一种称为“增量式并发收集器”（IncrementalConcurrentMarkSweep/i-CMS）的CMS收集器变种，所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想一样，就是在并发标记和并发清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得少一些，速度下降也就没有那么明显，但是目前版本中，i-CMS已经被声明为“deprecated”，即不再提倡用户使用。
·CMS收集器无法处理浮动垃圾（FloatingGarbage），可能出现“ConcurrentModeFailure”失败而导致另一次FullGC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数以获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“ConcurrentModeFailure”失败，这时候虚拟机将启动后备预案：临时启用SerialOld收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX：CMSInitiatingOccupancyFraction设置得太高将会很容易导致大量“ConcurrentModeFailure”失败，性能反而降低。
·还有最后一个缺点，在本节在开头说过，CMS是一款基于“标记-清除”算法实现的收集器，如果读者对前面这种算法介绍还有印象的话，就可能想到这意味着收集结束时会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次FullGC。为了解决这个问题，CMS收集器提供了一个-XX：+UseCMSCompactAtFullCollection开关参数，用于在“享受”完FullGC服务之后额外免费附送一个碎片整理过程，内存整理的过程是无法并发的。空间碎片问题没有了，但停顿时间不得不变长了。虚拟机设计者们还提供了另外一个参数-XX：CMSFullGCsBeforeCompaction，这个参数用于设置在执行多少次不压缩的FullGC后，跟着来一次带压缩的。
后续分开介绍：
3.2.7 G1收集器G1（GarbageFirst）收集器
G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项；作为JVM GC算法的一次重大升级、DK7u后G1已相对稳定、且未来计划替代CMS、所以有必要深入了解下：
不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必须是连续的）。这种将O区划分成多块的理念源于：当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。如下：
这也是为什么G1命名为Garbage First的原因：第一时间处理垃圾最多的区块。
平时工作中大多数系统都使用CMS、即使静默升级到JDK7默认仍然采用CMS、那么G1相对于CMS的区别在：
G1在压缩空间方面有优势
G1通过将内存空间分成区域（Region）的方式避免内存碎片问题
Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活
G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象
G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做
G1会在Young GC中使用、而CMS只能在O区使用
就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：
服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
应用在运行过程中会产生大量内存碎片、需要经常压缩空间
想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象
一次完整G1GC的详细过程：
G1在运行过程中主要包含如下4种操作方式：
YGC（不同于CMS）
并发阶段
混合模式
full GC （一般是G1出现问题时发生）
YGC：
下面是一次YGC前后内存区域是示意图：
图中每个小区块都代表G1的一个区域（Region），区块里面的字母代表不同的分代内存空间类型（如[E]Eden,[O]Old,[S]Survivor）空白的区块不属于任何一个分区；G1可以在需要的时候任意指定这个区域属于Eden或是O区之类的。
G1 YoungGC在Eden充满时触发，在回收之后所有之前属于Eden的区块全变成空白。然后至少有一个区块是属于S区的（如图半满的那个区域），同时可能有一些数据移到了O区。
目前淘系的应用大都使用PrintGCDetails参数打出GC日志、这个参数对G1同样有效、但日志内容颇为不同；下面是一个Young GC的例子：
23.430: [GC pause (young), 0.23094400 secs]
…
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]
上面日志的内容解析：Young GC实际占用230毫秒、其中GC线程占用850毫秒的CPU时间
E：内存占用从1286MB变成0、都被移出
S：从78M增长到了152M、说明从Eden移过来74M
Heap:占用从1454变成242M、说明这次Young GC一共释放了1212M内存空间
很多情况下，S区的对象会有部分晋升到Old区，另外如果S区已满、Eden存活的对象会直接晋升到Old区，这种情况下Old的空间就会涨
并发阶段：
一个并发G1回收周期前后内存占用情况如下图所示：
从上面的图表可以看出以下几点：
1、Young区发生了变化、这意味着在G1并发阶段内至少发生了一次YGC（这点和CMS就有区别），Eden在标记之前已经被完全清空，因为在并发阶段应用线程同时在工作、所以可以看到Eden又有新的占用
2、一些区域被X标记，这些区域属于O区，此时仍然有数据存放、不同之处在G1已标记出这些区域包含的垃圾最多、也就是回收收益最高的区域
3、在并发阶段完成之后实际上O区的容量变得更大了（O+X的方块）。这时因为这个过程中发生了YGC有新的对象进入所致。此外，这个阶段在O区没有回收任何对象：它的作用主要是标记出垃圾最多的区块出来。对象实际上是在后面的阶段真正开始被回收
G1并发标记周期可以分成几个阶段、其中有些需要暂停应用线程。第一个阶段是初始标记阶段。这个阶段会暂停所有应用线程-部分原因是这个过程会执行一次YGC、下面是一个日志示例：
50.541: [GC pause (young) (initial-mark), 0.27767100 secs] [Eden: 1220M(1220M)->0B(1220M) Survivors: 144M->144M Heap:
3242M(4096M)->2093M(4096M)] [Times: user=1.02 sys=0.04, real=0.28
secs]
上面的日志表明发生了YGC、应用线程为此暂停了280毫秒，Eden区被清空（71MB从Young区移到了O区）。
日志里面initial-mark的字样表明后台的并发GC阶段开始了。因为初始标记阶段本身也是要暂停应用线程的，
G1正好在YGC的过程中把这个事情也一起干了。为此带来的额外开销不是很大、增加了20%的CPU，暂停时间相应的略微变长了些。
接下来，G1开始扫描根区域、日志示例：
50.819: [GC concurrent-root-region-scan-start]
51.408: [GC concurrent-root-region-scan-end, 0.5890230]
一共花了580毫秒，这个过程没有暂停应用线程；是后台线程并行处理的。这个阶段不能被YGC所打断、因此后台线程有足够的CPU时间很关键。如果Young区空间恰好在Root扫描的时候
满了、YGC必须等待root扫描之后才能进行。带来的影响是YGC暂停时间会相应的增加。这时的GC日志是这样的：
350.994: [GC pause (young)
351.093: [GC concurrent-root-region-scan-end, 0.6100090]
351.093: [GC concurrent-mark-start],0.37559600 secs]
GC暂停这里可以看出在root扫描结束之前就发生了，表明YGC发生了等待，等待时间大概是100毫秒。
在root扫描完成后，G1进入了一个并发标记阶段。这个阶段也是完全后台进行的；GC日志里面下面的信息代表这个阶段的开始和结束：
111.382: [GC concurrent-mark-start] ….
120.905: [GC concurrent-mark-end, 9.5225160 sec]
并发标记阶段是可以被打断的，比如这个过程中发生了YGC就会。这个阶段之后会有一个二次标记阶段和清理阶段：
120.910: [GC remark 120.959: [GC ref-PRC, 0.0000890 secs], 0.0718990 secs] [Times: user=0.23 sys=0.01, real=0.08 secs]
120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]
这两个阶段同样会暂停应用线程，但时间很短。接下来还有额外的一次并发清理阶段：
120.996: [GC concurrent-cleanup-start]
120.996: [GC concurrent-cleanup-end, 0.0004520]
到此为止，正常的一个G1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多（标记为X），实际空间释放较少。
混合GC：
接下来G1执行一系列的混合GC。这个时期因为会同时进行YGC和清理上面已标记为X的区域，所以称之为混合阶段，下面是一个混合GC执行的前后示意图：
像普通的YGC那样、G1完全清空掉Eden同时调整survivor区。另外，两个标记也被回收了，他们有个共同的特点是包含最多可回收的对象，因此这两个区域绝对部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域（和YGC存活对象晋升到O区类似）。这就是为什么G1的堆比CMS内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。下面是一个混合GC的日志：
79.826: [GC pause (mixed), 0.26161600 secs] …. [Eden: 1222M(1222M)->0B(1220M) Survivors: 142M->144M Heap:
3200M(4096M)->1964M(4096M)] [Times: user=1.01 sys=0.00, real=0.26
secs]
上面的日志可以注意到Eden释放了1222MB、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有16MB，但是要考虑同时有survivor区的对象晋升到O区；另外，每次混合GC只是清理一部分的O区内存，整个GC会一直持续到几乎所有的标记区域垃圾对象都被回收，这个阶段完了之后G1会重新回到正常的YGC阶段。周期性的，当O区内存占用达到一定数量之后G1又会开启一次新的并行GC阶段.
后续分开介绍：。。
参考:
深入理解java虚拟机
http://ifeve.com/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3g1%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8/