本文主要参考《深入理解java虚拟机》进行简化总结，希望能够让读者快速入门jvm垃圾回收相关机制。
1.为什么了解GC
需要排查内存泄露、内存溢出问题，当垃圾收集成为系统达到高并发的瓶颈时。
2.GC需要完成3件事
- 哪些内存需要回收
- 什么时候回收
- 如何回收
3.哪些内存需要回收
程序计数器、虚拟机栈和本地方法栈三个方法区域随线程而生，随线程而灭，这部分不需要关心。java堆和方法区，只有在程序处于运行期间才能知道创建哪些对象，这部分内存和回收都是动态的，是需要关心的。
4.什么时候回收
垃圾收集器对堆进行回收前，需要确定这些对象有哪些存活，哪些死去。常用的判断对象是否存活的方法：
4.1引用计数法
对象添加一个引用计数器，每个地方引用+1，失效-1。主要问题，对象相互循环引用，所以不被采用。
4.2根搜索算法
通过一系列名为“GCRoots”的对象为起点，从起点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到GC Roots没有任何引用链，证明该对象已经死亡。以下可以作为GC Roots
- 虚拟机栈中的引用对象
- 方法区中的类静态属性引用对象
- 方法区中常量引用对象
- 本地方法中引用对象
4.3两次标记
在经历第一次跟搜索标记以后，将进行一次筛选，条件是对象是否覆盖finalize()方法（并且从未被调用过），这些需要被执行finalize方法的对象，会被放置到一个名为F-Queue的队列中，并在稍后由一条虚拟机自动建立的低优先级线程执行，该执行只是触发，并不承诺等待运行结束，finalize方法是对象逃脱死亡最后机会，可以在该方法中重新引用。这种自救只能使用一次，因为finalize方法只会被虚拟机执行一次。建议不要使用finalize方法，运行代价高昂，不确定性很大，finally可以代替。
4.4方法区回收判断
HotSpot虚拟机中的永久代，按照jvm规范方法区是可以不回收的，通常回收效率很低。主要收集两部分内容：废弃常量和无用类。判断废弃常量和堆中对象类似，但是无用类就非常严格了：
- 该类所有实例都已经被回收
- 加载该类的ClassLoader已经被回收
- 该类对应的Class对象没有任何地方在引用，无法用其进行反射方位该类。
满足上述所有条件，同时HotSpot中配置了相关参数才会回收。在大量使用反射、动态代理以及CGLIb等bytecode框架的场景，以及动态生成JSP和自定义ClassLodaer场景需要卸载功能，来保证永久代不会溢出。
5.如何回收
垃圾收集在不同平台的虚拟机操作内存的方法各不相同，简单介绍几种回收思想：
5.1标记-清除算法
分为标记和清除两个过程，标记利用前面叙述的根搜索算法标记出所有需要清除的对象。作为基础算法该算法有以下几个缺点：
- 效率不高
- 清除之后会产生大量不连续的内存碎片，可能导致后续分配大内存的对象找不到合适空间。
5.2复制算法
将可用容量等分成两块，每次只使用其中一块，当一块内存用完了。计算该内存中存活对象并将其复制到另一块内存，将该内存全部清空。商业虚拟机采用该算法回收新生代，新生代中的对象98%朝生夕死（所以不需要分配1：1），将内存分为一块比较大的Eden空间和两块较小的Survivor空间。
每次使用Eden和一块Survivor空间，回收的时候，将存活的对象一次性复制到另一块Survivor空间。默认情况下，Eden和Survivor大小是8：1，当然我们没法保证每次回收只有10%的对象存活，当Survivor空间不够用时，需要分配担保机制直接进入老年代。
5.3标记整理算法
复制算法在对象存活率较高的时候执行较多的复制，效率会变得很低，这时提出了标记整理算法。主要针对老年代，整理过程将所有存活对象都向一端移动，然后直接清理掉边界以外所有内存。
5.4分代收集
实际商业虚拟机会根据对象存活周期不同将内存划分为几块，一般是分为新生代和老年代，根据不同代特性选择不同的算法进行垃圾收集。
6.垃圾回收器
上述算法只是内存回收的方法论，而垃圾收集器则是具体实现。一般厂商会提供参数供用户根据自己应用特点和要求组合出各个年代要使用的收集器。首先是3款常见新生代收集器：
6.1Serial收集器
jdk1.3之前新生代收集唯一选择，单线程收集器在进行垃圾收集的时候需要暂停所有其他工作。（Client模式下默认新生代收集器）
6.2ParNew收集器
Serial收集器的多线程版本，参数配置、收集算法以及策略等都和Serial完全相同。Server模式下选择它的重要理由是他是除了Serial以外唯一和CMS（老年代收集器）可以配合的收集器。在多核情况下，ParNew才会显得比Serial高效。特别指出这里的并行是指多条垃圾收集线程并行工作，用户线程还是要处于等待的。
6.3Parallel Scavenge收集器
作为新生代收集器，使用复制算法的收集器，其关注点是达到一个可控制吞吐量，所谓吞吐量=运行代码时间/（运行用户代码时间+垃圾收集时间），假设虚拟机总共运行100分钟，垃圾回收用掉1分钟，则吞吐量就是99%。
一般收集器设计会关注两个点：停顿时间（如CMS）和吞吐量（如Parallel Scavenge）。前者常用于用户交互频繁的程序，较短的停顿带来良好的用户体验；后者则适合后台运算不需要太多的交互行为，高效利用cpu。Parallel Scavenge收集器也被经常称为“吞吐量优先”收集器。接下来介绍3款老生代垃圾回收器：
6.4Serial Old收集器
与Serial收集器类似，单线程收集器，使用“标记—整理算法”，Client模式下默认老生代收集器。
6.5Parallel Old收集器
Parallel Scavenge收集器的老年代版本，使用多线程和”标记—整理算法“，jdk1.6开始提供用来配合Parallel Scavenge收集器。在此之前，Parallel Scavenge收集器只能和Serial Old收集器配合使用，性能被后者拖累。
6.6CMS收集器
以获取最短时间停顿为目标的收集器，目前web服务端大部分都在使用为了给用户较好的体验，其是基于“标记——整理”算法实现。目前，很大一部分java应用集中在web的服务端，该类服务重视响应速度，希望停顿时间越短越好，而CMS非常符合该类需求。CMS收集器运作过程分为以下4个步骤：
- 初始化标记（标记GC Roots直接关联的对象）
- 并发标记（GC Roots的Tracing过程）
- 重新标记（修正并发标记期间，用户运行程序导致标记的改动）
- 并发清除
其优点主要表现为并发收集和低停顿，当然它自身也有明显缺点：
- 并发阶段会占用CPU资源导致应用程序变慢，特别是负载高的情况下会导致用户的执行速度突然降低
- 无法处理浮动垃圾，清理阶段用户程序还在运行产生新的垃圾，因此CMS通常不能再老年代几乎填满的时候再收集。默认情况下，CMS在老年代使用68%的情况就会被激活，可以通过参数设置。如果在CMS运行期间预留内存不足，就会出现”Concurrent Mode Failure“失败。
- 使用标记—整理算法，在收集结束会产生大量空间碎片，为了解决该问题，CMS提供了”+XX:UseCMSCompactAtFullCollection“开关参数用于，在完成垃圾回收后进行一次碎片整理过程，同时还提供参数”-XX:CMSFullGCsBeforeCompaction“用来控制多少次FullGC以后启动该次碎片整理，毕竟碎片整理会延长停顿时间。
6.7G1收集器
Jdk7+版本都可以自主配置G1作为JVM GC选项，作为垃圾收集器理论进一步发展的结果，不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。G1将整个java堆包括新生代和老生代划分为多个固定大小独立区域，并且跟踪这些区域里面垃圾堆积程度，在后台维护一个优先级列表，在规定的允许的时间内，优先收集垃圾最多的区域。与CMS相比其优势在于：
- 空间划分为多个区域避免了空间碎片化
- 精确控制停顿时间到毫秒级
参考文档
《深入理解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/
