可达性分析算法
当一个对象到GC Roots没有任何引用链(用图论的话说，就是从GC Roots节点触发到某个节点不可达)时，则证明此对象是不可用的。也就是说该对象是可回收的。
什么是GC Roots?
在Java语言中，可作为GC Roots的对象包括下面几种。
- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI(即一般所说的Native方法)引用的对象
对象何时宣告死亡
要真正宣告一个对象死亡，至少需要经历两次标记过程：
如果对象在经历一次可达性分析之后发现没有与 GC Roots 相连接的引用链，那么他将会被第一次标记。
如果这个对象被判定有必要执行 finalize() 方法，那么这个方法将会被放置在一个叫做 F-Queue 的队列中，并在稍后由一个虚拟机建立的，低优先级的 Finalizer 线程去执行它。稍后GC将对 F-Queue 中的对象进行第二次小规模标记。
两次标记成功之后，GC便会将这个对象收回，对象宣告死亡。
那么第一次被标记之后有没有办法逃脱GC回收呢？
答案是有的，在进入 F-Queue 中时或者已经在队列中的这一段时间内，只要重新与引用链上的任何一个对象建立联系即可。
回收方法区(永久代)
在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%-90%的空间，但是在永久代垃圾回收率却远低于此。
永久代垃圾回收主要负责两部分内容：
废弃常量
没人用则进行回收-
回收无用类
判断一个常量是否需要回收比较简单，但是回收一个类需要满足下面三个条件。- 该类所有的实例已经被回收，也就是Java堆中不存在该类的任何实例
- 加载该类的类加载器已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被使用，无法在任何地方通过反射调用该类的方法。
回收永久代的常用场景：
在大量使用反射，动态代理，CGLib等框架，动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载功能，以保证永久代不会发生内存溢出。
垃圾收集算法
- 标记--清楚算法
标记过程前面已经介绍过，一个对象需要经历两次标记的过程才能被确定为可回收的对象，清除时直接释放原对象所占的内存空间即可。
这样做的问题也随之而来，会带来内存碎片，这将导致如果突然加载一个大的对象将会导致内存溢出的问题。
另外该算法还存在效率问题，标记和清除两个过程的效率都不够高。
- 复制算法
复制算法为解决效率问题而生，它将内存划分为两块相等的空间，每次只使用其中一块，当这一块内存用完之后，就将这块内存中还存活的对象复制到另外一块内存中，再把该内存块中的内存全部释放掉。
该算法顺手也把内存碎片的问题给解决了，但是该算法付出的代价也很大--将内存缩小了一半。
然而，很多商业虚拟机采用该算法回收新生代的对象，他们在使用该算法的时候，并不会按照一比一的比例去划分内存，而是按照8:1:1的比例将内存划分为3个部分，这三个部分分别对应新生代的Eden,From Survivor,To Survivor区。
每次使用时，只使用其中的Eden和From Survivor区，也就是说每次只使用内存的90%的容量。当GC时，将Eden和From Survivor中还存活的对象存放在To Survivor区中，当To Survivor区中内存不足以存放下所有新生代存活的对象时，需要依赖其他内存进行分配担保(这里指老年代)。
分配担保--即新生代发生GC时，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间。
- 标记--整理算法
该算法是标记过程与前两种无异，但是后续步骤是让所用存活对象都向一端移动，然后将存活的对象按地址大小进行排列，最后将大于队列末端的地址全部释放掉。
该算法很适合对老年代进行GC。
- 分代收集算法
对新生代采用复制算法，对老年代采用标记--整理算法。
HptSpot算法实现
- 枚举根节点
从可达性分析中从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要是全局性的引用(例如常量和静态属性)与执行上下文(例如栈帧中的变量表)，现在很多应用仅仅方法区就有数百兆，如果逐个检查这里面的引用，必然耗费很多时间。
枚举根节点就是解决如何找到GC Roots的问题。
使用一组称为OopMap的数据结构来达到这个目的。
