说起垃圾回收，我估计很多初级java开发（包括之前的我）想到的是这个JVM会帮我管理的啊，我们不太需要去考虑这种事情。但是，当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈的时候，我们就有必要对垃圾回收GC进行了解了。思考GC需要完成的3件事情：
1.哪些内存需要回收
2.什么时候回收
3.如何回收

哪些内存需要回收

首先我们要考虑的是哪些内存需要回收，在介绍Java的内存区域的时候，我们知道栈中的栈帧所分配的内存基本上是在类结构确定下来是就已知的。所以程序计数器、虚拟机栈、本地方法栈这3个区域的内存分配和回收都具备确定性，它们随着线程而生，随着线程而灭。我们可以认为这一部分内存是静态的。而Java堆和方法区的内存分配，我们只有在程序运行时才知道要创建多少对象，从而分配多少内存。这一部分内存我们可以认为是动态的。垃圾收集器所关注的是这部分内存。 那回收什么样的内存？当然是回收那些创建出来的对象都没人用的对象所占用的内存空间，因此在对这部分内存回收之前，第一件事就是需要确认这些对象是死是活（不可能再被任何途径使用的对象即认为是死）

引用计数算法

引用计数法的基本思想是：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1,；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
客观地说，这个判断方法实现简单，判定效率也很高，也有些应用案例，但在主流的Java虚拟机里并没有选择此方法来管理内存，其中最主要的原因是它很难解决对象之间循环引用的问题。

可达性分析算法

目前主流的Java虚拟机都采用可达性分析来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。如图所示：

对象5.6.7虽然它们之间有关联，但是它们与GC Roots是不可达的，所以判定它们是可回收的对象。
在Java语言中，可作为GC Roots的对象包括下面几种：
1.虚拟机栈（栈帧中的本地变量表）中引用的对象。
2.方法区中类静态属性引用的对象。
3.方法区中常量引用的对象。
4.本地方法栈中JNI（即一般说的Native方法）引用的对象。
总结上面所说，都牵扯到一个词“引用”。在JDK1.2之前，对引用的定义就是说如果reference类型的数据总存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。但这样的定义使得我们的对象就只有被引用和没有被引用这两种状态。然而我们还是想要说想表示更多的状态，如当内存还够时我们还不想删除的那些对象。在JDK1.2之后。Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用4种，引用强度依次减弱。
1.强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只有强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2.软引用也是用来描述一些有用但并非必要的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
3.弱引用也是用来描述非必要对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。但垃圾收集工作时，无论当前内存是否足够，都会回收掉只内弱引用关联的对象。
4.虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

要不要马上“死”？

尽管通过以上的判定方法可以找到不可达的对象，但是要真正宣告一个对象死亡，至少要经历两次标记过程：第一次标记是在可达性分析后发现没有与GC Roots相连接的引用链并同时进行一次筛选，如果筛选出此对象没有必要执行finalize方法（当前对象没有覆盖finalize方法或此方法已经被执行过了，注意：finalize方法在整个对象生命周期只会被调用一次而已）。没有必要执行finalize方法的对象确认已经死亡。如果有必要执行finalize方法的对象则会将此对象放入一个叫做F-Queue的队列之中，并稍后有一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这也是对象最后的自救时刻，它可在finalize方法把自己（this）赋值给某个类变量或者对象的成员变量来自救不在这次垃圾回收掉，这是第二次标记。如果第二次标记不成功，那就真的回收了。

方法区回收

上面说的方法都是在堆内存中进行内存管理的。方法区的内存，即我们常说的永久代（在Java8里也已经没有永久代这个概念了）。虽然在Java虚拟机规范中并没有要求在方法区也要实现垃圾收集。的确，在这里收集内存的效率太低1了。在这部分内存要回收的主要是废弃常量和无用的类。常量是不是废弃的很好判断，但类要同时满足以下3个条件才能算是“无用的类”：
1.该类的所有实例都已经被回收，也就是Java堆里面不存在该类的任何实例。
2.加载该类的ClassLoader已经被回收。
3.该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
在这里，对类的回收不像对象一样，没用了就回收，类回不回收HotSpot虚拟机提供了-Xnoclassgc参数进行控制。

什么时候回收

我们之前说过，从内存回收的角度来看，由于现在的收集器基本都采用分代收集算法，所以Java堆中可以被细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。 年轻代是所有新对象产生的地方。当年轻代内存空间被用完时，这时就会触发垃圾回收。这个垃圾回收叫做Minor GC。
老年代内存里包含了长期存活的对象和经过多次Minor GC后依然存活下来的对象。通常会在老年代内存被占满时进行垃圾回收。老年代的垃圾收集叫做Major GC。这里注意，发生在老年代的垃圾收集也有人叫Full GC，这两个术语目前还没有正式的定义。但我更倾向于说永久代的垃圾收集是Full GC。

如何回收

垃圾收集算法帮我们更有效率地回收内存

标记-清除算法

最基础的收集算法是“标记-清除”算法，算法分为“标记”和“清除”两个阶段：首先标记出所需要回收的对象，在标记完成后统一回收所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思想并对其不足之处进行改进而已。它的主要不足之处有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除后悔产生大量的不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象是，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。“标记-清除”算法的执行过程如图所示

复制算法

为了解决效率问题，可以将内存按容量大小划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已经使用过的内存空间一次性清理掉，这就是“复制”算法。在这里还要说说新生代的内存空间比例，IBM的研究表明新生代中有98%的对象都是短命的，所以并不需要1:1来划分内存空间，而是将内存分为较大的一块Eden空间和两块较小的Survivor空间（HotSpot虚拟机比例是8:1），每次使用Eden和其中一块Survivor，留一块Survivor用来复制两个空间中还存活的对象，然后直接清空那两个空间。还有就是我们还不能保证每次那个剩下的那个Survivor空间都有足够的空间复制存活的对象，因此还需要依赖其他内存（这里指老年代）进行分配担保，如果空间不足，这些对象将通过分配担保机制进入老年代。“复制”算法的执行过程如图所示

标记-整理算法

复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。特别在老年代，老年代一般不能直接选用这种算法，因此有人提出了另外一种“标记-整理”算法，标记过程仍然和“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行整理，而是让所有存活的对象向一端移动，然后直接清理掉边界以外的内存。“标记-整理”算法的执行过程如图所示

分代收集除算法

当前商业虚拟机的垃圾收集都采用“分代收集”算法。一般将Java堆分成新生代和老年代，然后根绝各个年代的特点采用适当的手机算法。在新生代采用“复制”算法，在老年代采用“标记-清理”或“标记-整理”算法。
致谢：以上的配图都来自百度图片，感谢原作者。