目录
前言
上一篇介绍了Java虚拟机的运行时内存区域，接下来将来学习下几种常见的垃圾收集算法，进入正题。
概述
在早期，人们就在思考GC（Garbage Collection，GC）需要完成的三件事：
哪些内存需要回收？
什么时候回收？
如何回收？
经过半个多世纪的发展，内存动态分配和内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，那我们为什么还要去了解GC和内存分配呢？答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。
之前了解到内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈三个区域随进程而生，随进程而灭。栈中的栈帧随着方法的进入和退出而执行着出栈和入栈的操作。每个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内不需要过多的考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。
Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有在程序处于运行时才能知道会创建哪些对象，这部分的内存分配和回收都是动态的，垃圾收集器所关注的这部分内存，及后面讨论的“内存”分配问题与回收也仅指这一部分内存。
判断对象是否已死
堆中几乎存放着Java中所有的对象实例，垃圾收集器对堆进行回收前，第一件事就是确定这些对象有哪些还“存活着”，哪些已经“死去”（即不可能再被任何途径使用的对象），下面将介绍下常用的判断对象是否存货的算法。
引用计数算法（Reference Counting）
定义是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1，任何时刻计数器都为0的对象就是不可能再被使用的。
客观的说，引用计数算法的实现简单，判断效率也很高，在大部分情况下它都是个不错的算法。但是Java语言中没有选择它来管理内存，主要原因是它很难解决对象之间的相互循环引用的问题。
例如：
class DemoApplicationTests {
Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
* 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
*/
private byte[] bigSize = new byte[2 * _1MB];
@Test
void test() {
ReferenceCountingGCTests objA = new ReferenceCountingGCTests();
ReferenceCountingGCTests objB = new ReferenceCountingGCTests();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
//假设在这行发生GC，那么objA和objB是否能被回收？
System.gc();
}
}
GC日志打印之后，显示如下：
[GC (System.gc()) [PSYoungGen: 21058K->1445K(134144K)] 29477K->9864K(184320K), 0.0016862 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 1445K->0K(134144K)] [ParOldGen: 8418K->8479K(50176K)] 9864K->8479K(184320K), [Metaspace: 20833K->20833K(1069056K)], 0.0285684 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
Heap
PSYoungGen total 134144K, used 5372K [0x00000000d5b00000, 0x00000000ded80000, 0x0000000100000000)
eden space 127488K, 4% used [0x00000000d5b00000,0x00000000d603f128,0x00000000dd780000)
from space 6656K, 0% used [0x00000000de700000,0x00000000de700000,0x00000000ded80000)
to space 11264K, 0% used [0x00000000dd780000,0x00000000dd780000,0x00000000de280000)
ParOldGen total 50176K, used 8479K [0x0000000081000000, 0x0000000084100000, 0x00000000d5b00000)
object space 50176K, 16% used [0x0000000081000000,0x0000000081847f88,0x0000000084100000)
Metaspace used 21019K, capacity 22682K, committed 22784K, reserved 1069056K
class space used 2926K, capacity 3249K, committed 3328K, reserved 1048576K
从运行结果可以清楚的看出GC日志中包含“29477K->9864K”，意味着虚拟机没有因为这两个对象互相引用就不回收它们，这也说明虚拟机不是通过引用计数算法来判断对象是否存活的。
在执行上一段代码时，需要设置一下打印GC日志详情。我是使用的idea，如图配置即可。
再说下打印的GC日志说明如下：
CPU时间与墙钟时间：墙钟时间包括各种非运算符的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多个CPU或者多核的话，多线程操作会叠加这些CPU时间，所以看到sys时间超过real时间是完全正常的。
JVM的GC日志的主要参数包括如下几个：
根搜索算法（GC Roots Tracing）
Java是使用根搜索算法来判断对象是否存活的，基本思路是：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连（就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如图：
对象object5、object6、object7虽然互有关联，但是他们到GC Roots是不可达的，so它们将会被判定为是可回收对象。在Java语言中，可作为GC Roots的对象包括下面几种：
1、虚拟机栈（栈帧中的本地变量表）中的引用对象。
2、方法区中的类静态属性引用对象。
3、方法区中的常量引用的对象。
4、本地方法栈中的JNI（即一般说的Native方法）的引用的对象。
引用
在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，这四种引用强度依次逐渐减弱。
强引用：指在程序代码中普遍存在，类似“Object obj = new Object()”这类引用，只要强引用还存在，垃圾收集器永远不会回收掉引用的对象。
软引用：用来描述一些还有用，但并非必须的对象。对于弱引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常，提供SoftReference类来实现引用类型。
弱引用：也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，被弱引用关联的对象都会被回收掉。提供WeekReference类来实现引用类型。
虚引用：也称幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。唯一目的是希望这个对象被收集器回收时收到一个系统通知。提供PhantomReference类来实现引用类型。
回收方法区
方法区（HotSpot虚拟机中的永久代）进行垃圾回收，性价比会比较低，在堆中，尤其是在新生代中，常规应用进行一次垃圾回收一般可回收70%-95%的空间，而永久代的垃圾收集效率远低于此。
永久代垃圾收集主要两个部分：废弃常量和无用的类。
回收废弃常量：回收废弃常量和回收堆中的对象相似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，没有其他地方引用了这个字面量，如果这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
无用的类：判断是否无用的类，需满足三个条件：
1、该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2、加载该类的ClassLoader已经被回收。
3、该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
垃圾收集算法
下面介绍几种算法的思想及其发展过程。
标记 - 清除算法（Mark-Sweep）
最基础的算法是“标记 - 清除”算法，分为“标记”和“清除”两个阶段：先标记出所有需要回收的对象，然后在标记完成后统一回收掉所有被标记的对象。
不过有两缺点：
1、效率问题，标记和清除过程的效率都不高；
2、空间问题，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多可能会导致，当程序在以后过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记 - 清除算法的执行过程如下：
复制算法（Copying）
为了解决效率问题，一种称为“复制”的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这块的内存用完了，就将存好的对象复制到另一块上面，然后再将已使用过的内存空间一次性清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了点。执行过程如下：
IBM的专门研究表明，新生代的对象98%是朝生夕死，所以并不需要1:1的比例来划分内存空间，而是将内存分为一块Eden（较大的）空间和两块Survivor空间（较小的）,每次使用Eden空间和其中的一块Survivor空间。当回收时，将Eden和Survivor中还存活的对象复制到另个Survivor上面，最后清理掉之前用过的Eden和Survivor空间。HotSpot虚拟机默认Eden和Survivor空间比例为8:1，也就是每次新生代中可用内存占整个新生代内存的90%，只有10%的被浪费掉。
当然，98%的对象回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不足时，需要依赖其他内存（这里只老年代）进行分配担保。
分配担保
内存的分配担保就好比我们去银行借贷，如果我们信誉很好，在98%的情况下都能按时偿还， 于是银行可能会默认我们下一次也能按时按量的偿还贷款，只需要有一个担保人保证如果我不能还款时，可以从他的账户扣钱，那银行就没风险了。内存的分配担保也一样，如果另外一块Survivor空间不足以放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。
标记-整理算法（Mark-Compact）
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，然后“标记-整理”算法就出世了：标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
“标记-整理”算法的示意图如下图所示：
分代收集算法（Generational Collection）
当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
老年代中，因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。
好了，今天先学习到这里，目前只是介绍了垃圾收集的几个算法，慢慢消化，贪多不厌。下篇将着重介绍垃圾收集器和内存分配与回收的策略。
尾声
看了一眼我的电脑桌上的茉莉，养了不到半个月就快凉了。毕竟绿色代表生气，不能就这样让它凉了。问了客服，说要每天把水浇透，我咋感觉不靠谱呢，附上一张图：
