一：技术背景
垃圾回收（GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史比Java久远，早在1960年Lisp这门语言中就使用了内存动态分配和垃圾回收技术。
二：内存回收区域
JVM的内存结构包括五大区域：程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆区和方法区则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。
三：GC策略
1. 引用计数算法： 引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象实例都有一个引用计数。当一个对象被创建时，就将该对象实例分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。
优缺点：优点是简单 效率高，缺点是无法解决循环引用的问题
循环依赖Demo：
public class test {
public static void main(String[] args) {
MyObject object1=new MyObject();
MyObject object2=new MyObject();
object1.object=object2;
object2.object=object1;
object1=null;
object2=null;
}
}
2.可达性分析算法(GC ROOT): 以GC Roots为起点向下搜索,当一个对象到GC Roots没有任何引用链相连,则是不可用的,可达性分析算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点，无用的节点将会被判定为是可回收的对象。
在Java语言中，可作为GC Roots的对象包括下面几种：
a) 虚拟机栈中引用的对象（栈帧中的本地变量表）；
b) 方法区中类静态属性引用的对象；
c) 方法区中常量引用的对象；
d) 本地方法栈中JNI（Native方法）引用的对象。
四：Java引用
1.强引用：在程序代码中普遍存在的，类似 Object obj = new Object() 这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
2.软引用：用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。
3.弱引用：也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
4.虚引用：也叫幽灵引用或幻影引用（名字真会取，很魔幻的样子），是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。它的作用是能在这个对象被收集器回收时收到一个系统通知。
总结：概念有点难理解，但是一般都是基于强引用而言的。
五：对象标记
判定一个对象死亡，至少经历两次标记过程：如果对象在进行根搜索后，发现没有与GC Roots相连接的引用链，那它将会被1次标记，并在稍后执行他的finalize()方法（如果它有的话）。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这点是必须的，否则一个对象在finalize()方法执行缓慢，甚至有死循环什么的将会很容易导致整个系统崩溃。finalize()方法是对象一次逃脱死亡命运的机会，稍后GC将进行第二次规模稍小的标记，如果在finalize()中对象成功拯救自己（只要重新建立到GC Roots的连接即可，譬如把自己赋值到某个引用上），那在第二次标记时它将被移除出“即将回收”的集合，如果对象这时候还没有逃脱，那基本上它就真的离死不远了。
需要特别说明的是，这里对finalize()方法的描述可能带点悲情的艺术加工，并不代表笔者鼓励大家去使用这个方法来拯救对象。相反，笔者建议大家尽量避免使用它，这个不是C/C++里面的析构函数，它运行代价高昂，不确定性大，无法保证各个对象的调用顺序。需要关闭外部资源之类的事情，基本上它能做的使用try-finally可以做的更好。
六：方法区垃圾回收
《Java虚拟机规范》中确实说过可以不要求虚拟机在这区实现GC，而且这区GC的“性价比”一般比较低：在堆中，尤其是在新生代，常规应用进行一次GC可以一般可以回收70%~95%的空间，而***代的GC效率远小于此。虽然VM Spec不要求，但当前生产中的商业JVM都有实现***代的GC，主要回收两部分内容：废弃常量与无用类。这两点回收思想与Java堆中的对象回收很类似，都是搜索是否存在引用，常量的相对很简单，与对象类似的判定即可。而类的回收则比较苛刻，需要满足下面3个条件：
1.该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例。
2.加载该类的ClassLoader已经被GC。
3.该类对应的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法。
是否对类进行回收可使用-XX:+ClassUnloading参数进行控制，还可以使用-verbose:class或者-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载、卸载信息。
在大量使用反射、动态代理、CGLib等bytecode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要JVM具备类卸载的支持以保证内存不会溢出。
七：垃圾回收算法
1.复制算法：把内存按容量划分为大小相等的两块区域，每次只使用其中的一块，当这一块的内存空间用完了，就把还存活的对象复制到另一块内存中去，然后把已经使用的过的内存空间一次性清理掉。这样每次都是对半个内存区域进行GC回收，并不会产生内存碎片，但是代价是把内存缩小了一半，效率比较低。
2.标记—清除算法： 标记出需要回收的对象，在标记完成后进行统一的回收（标记即二次标记的过程）。此算法有两个不足：一是效率问题，标记和清除两个过程效率都不高；二是空间问题，标记清除后会产生大量不连续的内存碎片，内存空间碎片太多的话会导致以后程序在运行中想要分配较大对象的时候，无法找到一块连续的内存空间而导致不得不进行又一次的GC回收（后续的垃圾回收算法都是基于此算法进行改进的）。
3.标记-整理算法： 标记算法一样，区别是清除的时候会把所有存活的对象向一端移动（向上和向左），然后清除掉端边界以外的内存。
八：分代垃圾回收
分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。
年轻代:所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
老年代：在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
元空间：从JDK 8开始，Java开始使用元空间取代永久代，元空间并不在虚拟机中，而是直接使用本地内存。那么，默认情况下，元空间的大小仅受本地内存限制。当然，也可以对元空间的大小手动的配置。
九：垃圾收集器
上图展示了作用于不同年代的收集器，两个收集器之间存在连线的话就说明它们可以搭配使用。在介绍着些收集器之前，我们先明确一个观点：没有好的收集器，也没有差的收集器，只有最合适的收集器。
1.Serial收集器
单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。
2.ParNew收集器
ParNew收集器就是Serial的多线程版本，除了使用多条收集线程外，其余行为包括算法、STW、对象分配规则、回收策略等都与Serial收集器一摸一样。对应的这种收集器是虚拟机运行在Server模式的默认新生代收集器，在单CPU的环境中，ParNew收集器并不会比Serial收集器有更好的效果。
3.Parallel Scavenge收集器
Parallel Scavenge收集器（下称PS收集器）也是一个多线程收集器，也是使用复制算法，但它的对象分配规则与回收策略都与ParNew收集器有所不同，它是以吞吐量优先（即GC时间占总运行时间最小）为目标的收集器实现，它允许较长时间的STW换取总吞吐量最大化。
4.Serial Old收集器
Serial Old是单线程收集器，使用标记－整理算法，是老年代的收集器，上面三种都是使用在新生代收集器。
5.Parallel Old收集器
老年代版本吞吐量优先收集器，使用多线程和标记－整理算法，JVM 1.6提供，在此之前，新生代使用了PS收集器的话，老年代除Serial Old外别无选择，因为PS无法与CMS收集器配合工作。
6.CMS（Concurrent Mark Sweep）收集器
CMS是一种以最短停顿时间为目标的收集器，能尽可能降低GC时服务的停顿时间，这一点对于实时或者高交互性应用（譬如证券交易）来说至关重要，这类应用对于长时间STW一般是不可容忍的。CMS收集器使用的是标记－清除算法，也就是说它在运行期间会产生空间碎片，所以虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。其回收过程主要分为四个步骤：
（2）并发标记：进行GC Roots Tracing的过程，也就是标记不可达的对象，相对耗时；
（3）重新标记：修正并发标记期间因用户程序继续运作导致的标记变动，速度比较快；
（4）并发清除：对标记的对象进行统一回收处理，比较耗时；
（1）对CPU资源非常敏感；也就是说当CMS开启垃圾收集线程进行垃圾回收时，会占用部分用户线程，如果在CPU资源紧张的情况下，会导致用户程序的工作效率下降。
（2）无法处理浮动垃圾导致又一次FULL GC的产生；由于CMS并发回收垃圾时用户线程同时也在运行，伴随用户线程的运行自然会有新的垃圾产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集过程中进行回收，只能在下一次GC时在进行清除。所以在CMS运行期间要确保内存中有足够的预留空间用来存放用户线程的产生的浮动垃圾，不允许像其它收集器一样等到老年代区完全填满了之后再进行收集；那么当内存预留的空间不足时就会产生又一次的FULL GC来释放内存空间，由于是通过Serial Old收集器进行老年代的垃圾收集，所以导致停顿的时间变长了（系统有一个阈值来触发CMS收集器的启动，这个阈值不允许太高，太高反而导致性能降低）。
（3）标记—清除算法会产生内存碎片；如果产生过多的内存碎片时，当系统虚拟机想要再分配大对象时，会找不到一块足够大的连续内存空间进行存储，不得不又一次触发FULL GC。
（1）初始标记：标记一下GC Roots能直接关联到的对象，速度很快；
（2）并发标记：进行GC Roots Tracing的过程，也就是标记不可达的对象，相对耗时 ；
（3）最终标记：修正并发标记期间因用户程序继续运作导致的标记变动，速度比较快；
（4）筛选回收：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划；
G1收集器的特点:
（1）并发与并行：机型垃圾收集时可以与用户线程并发运行；
（2）分代收集：能根据对象的存活时间采取不同的收集算法进行垃圾回收；
（3）不会产生内存碎片：基于标记——整理算法和复制算法保证不会产生内存空间碎片；
（4）可预测的停顿：G1除了追求低停顿时间外，还能建立可预测的停顿时间模型，便于用户的实时监控；