GC的收集器&回收算法
收集器
- Serial收集器
单线程的收集器（只会使用一个CPU或一条收集线程去完成垃圾收集工作，进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。）
虚拟机运行在<code>Client</code>模式下的默认新生代收集器。与其他收集器的单线程比更加简单高效。
Serial收集器工作过程
- ParNew收集器
Serial收集器的多线程版本
运行在<code>Server</code>模式下的虚拟机中首选的新生代收集器。其中一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。
ParNew收集器工作过程
- Parallel Scavenge收集器
它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。
吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
-
Serial Old收集器
Serial收集器的老年代版本，单线程收集器，使用“标记-整理”算法。
-
Parallel Old收集器
Parallel Scavenge收集器的老年代版本，使用多线程，基于“标记-整理”算法。（JDK1.6中才开始提供）
- CMS收集器（Concurrent Mark Sweep）
以获取最短回收停顿时间为目的的收集器，基于“标记-清除”算法。
CMS运作步骤
耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以，CMS收集器的内存回收过程是与用户线程一起并发执行的。
** 优点：**
- 并发收集
- 低停顿
缺点：
- CMS收集器对CPU资源非常敏感。 在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
- CMS收集器无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，治好留待下一次GC时再清理掉。这部分垃圾就称为“浮动垃圾”。因此，CMS不能像其他收集器那样等到老年代几乎完全被填满再进行手机，CMS需要预留一部分空间。
- 由于CMS基于“标记-清除”算法，意味着收集结束时会有大量空间碎片产生。
- G1 收集器
当今收集器技术发展的最前沿成果之一，G1是面向服务端应用的垃圾收集器。
特点
- 并行与并发：充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器需要停顿Java线程执行的GC动作，G1仍然能通过并发方式让Java程序继续执行。
- 分代收集：与其他收集器一样，分代概念在G1中依然得以保存。
- 空间整合：与CMS的“标记-清理”算法不同，G1从整体上看是基于<code>“标记-整理”算法</code>实现的收集器，从局部上看是基于<code>“复制”算法</code>实现的，这两种算法意味着G1运作期间不会产生内存空间碎片。
- 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得从超出N毫秒，这几乎已经是实时Java的垃圾收集器的特征了。
回收算法
-
标记 - 清除
分为“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
缺点：
- 标记和清除两个过程效率不高
- 标记清除后产生大量不连续的内存碎片。
-
标记 - 整理
让所有存活对象向一端移动。
- 复制算法
将内存分为两部分，每次使用其中一块，当这块内存用完，就将还存活的对象复制到另一块上面。
缺点：
- 浪费一半内存（改进的方法是将新生代分为Eden、From Survivor、To Survivor。)
-
分代收集算法
把对象按照寿命长短进行分组，分为新生代和老年代，然后根据各个年代的特点采用最适当的收集算法，在新生代采用复制算法，在老年代采用“标记－清除”或者“标记－整理”算法。
搜索算法
-
引用计数算法（已废弃）
给对象添加一个引用计数器，每当有一个地方引用它时，计数器+1，引用失效计数器-1；任何时候计数器为0的对象就是不可能再被使用。这有个问题是，两个对象相互引用导致两个对象都无法被回收。 -
可达性分析算法
通过一系列的GC Roots对象作为起点，从这些节点开始向下搜索。搜索所走过的路称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用。
可作为GC Root的对象有：
- 虚拟机栈（栈帧的本地变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI引用对象
即使在可达性分析中不可达的对象，也并非是“非死不可”，这时候他们暂时处于“缓刑”阶段。要真正宣告一个对象死亡，需要经历两个阶段：
1）如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。
2）如果这个对象呗判断为有必要执行finalize()方法。那么这个对象会被放到一个F-Queue队列中，并在稍后由一个虚拟机自动建立的、优先级低的Finalizer线程去执行它，这里的“执行”是指虚拟机会触发这个方法，但并不承诺等待它运行结束。这是为了防止finalize()方法执行缓慢使得F-Queue队列其他对象永久等待。
因此，对象可以在finalize()方法里把自己赋值给一个变量，以达到“自救”的目的，但是这样的“自救”只能用一次（虚拟机只会调用一次finalize()方法）。
