前言
在上一章《Java内存区域与内存溢出异常》中，我们了解了JVM将它所管理的空间区域划分为程序计数器、JVM栈、本地方法栈、堆、方法区这五块，如果只往这些区域存放数据，而对不再使用的数据不进行回收，那么很快就会造成内存溢出，JVM中负责数据回收的是垃圾收集器，垃圾回收又被称为GC。因为程序计数器、JVM栈、本地方法栈都是线程私有的，线程结束时，内存也就跟着回收了，所以这三块不需要我们考虑。本章就来讲一讲，垃圾收集器是如何对堆和方法区控制垃圾回收的。
本章知识点
- 如何判断对象是否死亡
- 引用的类型
- finalize()方法
- 垃圾收集算法
- 各类垃圾收集器与对比
- 内存分配的策略
判断对象是否已经死亡
众所周知，在JVM堆中，存放的大多都是对象实例，垃圾收集器在对该区域进行回收时，首先要知道，哪些对象已经死亡（不会再被使用的对象）。常见的判断方法有引用计数算法和可达性分析算法两种。
引用计数算法
给对象中添加一个引用计数器，当其被引用时，计数器值加1，引用失效时，计数器值减1,任何时刻，计数器为0的对象就是不可能被使用的。它的优点是实现简单、判定效率高，缺点则是难以解决对象之间相互循环引用的问题，如下代码所示：
/**
* @author ccoke
*/
public class A {
private Object instance;
public static void main(String[] args) {
A a = new A();
A b = new A();
// 互相调用
a.instance = b;
b.instance = a;
// 将a引用置为null，a实例对象内依然存在b实例对象
a = null;
// 将b引用置为null，b实例对象内依然存在a实例对象
b = null;
// 告诉JVM需要进行垃圾回收
System.gc();
}
}
上述代码中，如果使用引用计数法，因为a,b实例对象内都存在一个引用计数不为0的对象，所以无法通知垃圾收集器进行回收，所以JVM虚拟机使用的非该算法。
可达性分析算法 (Java虚拟机采用)
通过一系列的GC Roots对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。过程如下图所示：
可作为GC Roots的对象包括：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 方法区中静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法中的JNI引用的对象
什么是引用
Java对引用的概念进行了扩充，将引用分为以下四种：
- 强引用(Strong Reference)
强引用类似"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。 - 软引用(Soft Reference)
软引用用来描述一些存在但并非必需的对象。在系统将要发生内存溢出异常之前，会将被软引用关联的对象列入回收范围之中进行二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。 - 弱引用(Weak Reference)
弱引用也是用来描述非必需对象的，强度比软引用更弱一些，弱引用关联的对象只能生存到下一次垃圾收集发生之前。 - 虚引用 （幽灵引用、幻影引用、Phantom Reference)
虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的是为了在这个对象被垃圾回收时收到一个系统通知。
finalize()方法
对象：我觉得我还可以抢救一下 QAQ
在可达性分析算法中不可达的对象，并非一定会被销毁，可达性分析算法发现对象并没有与GC Roots相连接的引用链，则会对对象进行第一次标记与筛选，筛选的条件是对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或着已经被虚拟机调用过了，那么该对象可以宣布"凉凉"了。如果判定有必要执行finalize()方法，会将对象放置到F-Queue队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行该对象的finalize()方法，如果对象要拯救自己，只需要在该方法中，重新与引用链上的任何一个对象建立关联即可。这样，对象会在第二次标记时，被移除"即将回收"集合。
需要注意的是：
- finalize()方法只会被执行一次
- finalize()方法优先级很低，无法保证对象的调用顺序
- 不推荐使用
方法区（永久代）的垃圾回收
方法区的垃圾收集主要是两部分内容：废弃常量和无用的类。
- 判定废弃常量
在当前系统中，假设常量"abc"，没有被任何一个String对象引用，也没有其他地方引用这个字面量，则该常量会被系统清理出常量池。 - 判定无用的类，需要满足以下条件：
- 该类所有的实例都已经被回收
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用或者反射访问方法
垃圾收集算法
常见的垃圾收集算法有标记-清除算法、复制算法和标记-整理算法，他们存在效率与空间使用率的差异。
标记-清除算法
最基础的收集算法，它分为标记与清除两个阶段：首先将需要回收的对象进行标记，然后对标记的对象进行统一回收。该算法存在以下不足：
- 效率问题，标记和清除两个效率不高。
- 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集工作。
复制算法（适用于新生代）
复制算法解决的是"标记-清除算法"的效率问题，主要流程是： 将内存容量划分为大小相等的两块，每次只使用其中的一块。当这一块用完了，就将还存货着的对象复制到另一块上面，然后再把已经使用过的内存空间一次清理掉。这样使得每次都是对半区进行内存回收。它的优点是实现简单，运行高效，而缺点是内存缩小为原来的一半，造成了空间浪费。
目前大多数JVM在新生代中使用的是复制算法，因为新生代中的对象98%都是"朝生夕死"，所以它们将新生代空间的80%划分为Eden空间，另外20%划分为两块相同大小的Survivor空间，每次使用新生代时，都只用Eden空间和其中一块Survivor空间，进行垃圾回收时，将Eden和Survivor空间中存活的对象复制到另一块Survivor空间中，然后清理Eden空间和原本使用的Survivor空间，这种方法，每次只会有10%的空间会被浪费。如果遇到Survivor空间装不下垃圾回收后存活的对象，会使用分配担保机制，将无法存入Survivor空间的对象存入老年代中。
标记-整理算法（适用于老年代）
如果复制算法在对象存活率高的老年代中使用，需要进行较多的复制操作，效率会变的很低。所以，根据老年代的特点，我们可以使用标记-整理算法对老年代的垃圾对象进行回收。该算法的标记过程仍然与"标记-清除"算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
根据对象存活周期的不同划分内存，一般将堆分为新生代和老年代，然后根据各自的特点选择标记-清除算法、复制算法、标记-整理算法来进行回收。
HotSpot的垃圾收集器
JVM规范中对垃圾收集器应该如何实现并没有任何规定，所以不同版本的厂商、不同版本的JVM所提供的垃圾收集器可能会有很大差别，用户可以根据自己应用的特点自己组合各代使用的收集器。HopSpot虚拟机提供了如下几种收集器：
上图中，收集器之间存在连线代表可以搭配使用。下面对这几种收集器进行简单介绍，做一个大概了解，如需要更具体的，可以查阅《深入理解Java虚拟机》或者其他资料。
Serial收集器
单线程收集器，在它进行垃圾收集时，必须暂停其他所有的工作线程（Stop The World,目的是保持一致性），直到它收集结束。简单高效，适用于运行在Client模式下。
ParNew收集器
在Serial收集器的基础上实现了多线程，使用多条线程进行垃圾收集，减少停顿的时间，适用于Server模式下。
Parallel Scavenge收集器
Parallel Scavenge收集器与其他收集器不同的是，其他收集器的关注点是尽可能地缩短垃圾收集时用户线程停顿的时间，而Parallel Scavenge收集器的目标是让JVM运行用户代码达到一个可控制的吞吐量。
吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）
高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务。适用于在后台运算而不需要太多交互的任务。
Serial Old收集器
使用的是标记-整理算法，跟Serial收集器一样是一个单线程收集器。该收集器适用于Client模式。
Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
CMS收集器
CMS使用的是标记-清除算法，是一种以获取最短回收停顿时间为目标的收集器，它的运作过程分为4部分：
- 初始标记
- 并发标记
- 重新标记
- 并发清楚
其中，初始标记和重新标记仍然需要产生"Stop The World"。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快;并发标记是GC Roots链路追踪的过程。因为并发标记不产生"Stop The World"，所以重新标记是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。CMS存在对CPU资源非常敏感（面向并发），无法处理浮动垃圾（在并发标记阶段产生的），会产生大量的空间碎片（标记-清除算法带来的）等缺点。
G1收集器
G1收集器是当今收集器最牛的成果，有N多好处，简单列举一下：
- 能充分利用多CPU，多核来缩短"Stop The World"的时间
- 他将整个堆划分为多个大小相等的独立区域（Region），使得新生代和老年代不再是物理隔离的，新生代和老年代不再是物理隔离的了，不需要与其他收集器配合就可以独立管理整个GC堆
- 最底层采用的是复制算法，不会产生碎片
- 可以建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒
内存分配策略
JVM为对象在堆上分配空间，主要有如下几种策略：
- 对象优先在新生代Eden中分配
- 需要大量连续内存空间的对象直接进入老年代
- 长期存活的对象将进入老年代
总结
通过本章的学习，我们学习了JVM进行垃圾回收的算法与流程，比较了几种HotSpot常用的垃圾收集器，并且简单了解了内存分配的策略。
概括一下，判断对象是否死亡常见的方法是引用计数算法和可达性分析算法，在JVM中通常使用的是可达性分析算法。在Java中，引用可分为强、软、弱、虚四种，他们是根据在下一次GC是否存活来分的。Java提供了finalize()方法，类重载它可以让对象进行最后的救赎，它只会执行一次，不推荐使用。一般在老生代使用的是复制算法，而标记-清除和标记-整理算法在新生代中使用。HopSpot为新生代提供了Serial(单)、ParNew(多)、Parallel Scavenge（吞吐）收集器，为老年代提供了CMS(并发)、Serial Old(单)、Parallel Old(吞吐)收集器，G1收集器最牛P，可以管理整个堆(Region)。
...
// hey guy!
if( isValuable(this.article) && (like(this.article) || follow("ccoke"))) {
System.out.println("Thank you! XD");
} else {
System.out.println("I will continue to work hard！T.T");
}
...
