深入了解Java虚拟机笔记（三）：垃圾回收机制、算法和收集器
一、垃圾回收算法
1.1 引用计数算法（Reference Counting）
给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加一，当引用失效时，计数器值就减一。任何时刻计数器都为0的对象就是不可能再被使用的。但是由于该算法很难解决对象之间的相互循环引用的问题，所以Java没有选用引用计数算法来管理内存。
1.2 根搜索算法（GC Roots Tracing）
通过一系列名为“GC Roots”的对象作为起始点，从这些结点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（对象不可达）时，则此对象不可用。
在Java里，可作为GC Roots的对象包括以下几种：
（1）虚拟机栈（栈帧中的本地变量表）中引用的对象；
（2）方法区中的类静态属性引用的对象；
（3）方法区中常量引用的对象；
（4）本地方法栈中JNI（即Native方法）的引用对象。
在根搜索算法中不可达的对象，在真正被回收之前至少经历两次标记过程。对象没有与GC Roots相关联的引用链，会被第一次标记并进行一次筛选，筛选条件是此对象是否有必要执行finalize()方法（最多只会执行一次），如果有则该对象会被放置在一个F-Queue的队列中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。所谓执行指虚拟机会触发这个方法，但并不承诺等待它运行结束。finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行二次小规模标记，如果该对象没有和引用链上的对象重新建立关联，就会在第二次标记时移出“即将回收”的集合。
由于finalize()方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，它能做的try-finally或其他方法都能做的更好。
二、引用分类
2.1 强引用（Strong Reference）
类似Object obj=new Object();这类的引用，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象。
2.2 软引用（Soft Reference）
用来描述一些还有用，但是非必需的对象，软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围中并进行第二次回收。如果回收后还是没有足够内存，才会OOM。JDK1.2后提供SoftReference类来实现软引用。
2.3 弱引用（Weak Reference）
也是用来描述非必需对象，但是强度比软引用更弱，被弱引用关联的对象只能生存到下一次垃圾回收发生之前，无论如何垃圾回收都会回收弱引用关联对象，JDK1.2后提供WeakReference类实现弱引用。
2.4 虚引用（Phantom Reference）
也称幽灵引用或幻影引用，是最弱的引用关系。一个对象是否有虚引用存在，完全不会对其生存时间造成影响，也无法通过虚引用来取得一个对象实例。设置虚引用的唯一目的就是希望在这个对象被回收时收到一个系统通知。JDK1.2后提供PhantomReference类来实现虚引用。
三、方法区的回收
虚拟机可以不要求在方法区实现垃圾收集，而且方法区回收垃圾性价比很低。永久代的垃圾收集主要回收两个部分：废弃常量和无用的类。常量池中的字符串，类，接口，方法，字段的符号引用如果没有被引用则判定为无用常量。
常量是否无用判定比较简单，类的判定就相对苛刻的多。类需要同时满足三个条件才算是无用的类：
（1）该类所有实例都已经被回收，也就是堆中不存在该类任何实例。
（2）加载该类的ClassLoader已经被回收。
（3）该类对应的java.lang.Class对象没有在任何地方被引用。
虚拟机可以对满足上述条件的无用类进行回收，在大量使用反射、动态代理、CGLib等Bytecode框架的场景，以及动态生成JSP（jsp第一次会被编译成Java类）这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
四、垃圾收集算法
4.1 标记-清除算法（Mark-Sweep）
最基础的收集算法，分为标记和清除两个阶段。首先标记处所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另一个是空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致大对象无法分配到足够的内存而不得不提前触发另一次垃圾收集动作。
4.2 复制算法（Copying）
解决效率问题，将可用内存按容量划分为大小相等的两块，每次只使用其中一块，当这块的内存用完了，就将还存活着的对象复制到另一块上面，然后把已使用过的内存空间一次清理掉。这样内存分配时就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。代价是将内存缩小为原来的一半。
现在的商业虚拟机都采用这种收集算法来回收新生代，且新生代的对象大多是朝生夕死的，所以不需要1:1划分内存空间，而是将内存分为一块较大的Eden空间和两个较小的Survivor空间。HotSpot默认Eden和Survivor的大小比例是8:1，就是说新生代可用内存空间为整个新生代容量的90%，浪费10%的内存。当Survivor空间不够用时需要依赖其他内存（指老年代）进行分配担保（Handle Promotion）。
4.3 标记-整理算法（Mark-Compact）
复制算法在对象存活率较高的时候效率将会变低，不适用于老年代。使用标记-整理算法，标记过程相同，但后续不是清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界外的内存。
4.4 分代收集算法（Generational Collection）
根据对象的存活周期不同将内存划分为几块，一般是把java堆分为新生代和老年代，这样就可以根据各年代特点采用最合适的收集算法。新生代存活对象少，就用复制算法，收集复制成本小；老年代对象存活率高，没有额外空间对它进行分配担保，就使用标记-清除或者标记-整理算法。
五、垃圾收集器
以下是7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。
（1）Serial收集器
最基本、历史最悠久的收集器，JDK1.3.1之前是虚拟机新生代收集的唯一选择。是一个单线程的收集器，它工作时不仅只会使用一个CPU或一条收集线程去完成垃圾收集工作，并且它工作时必须暂停其他所有的工作线程（Stop the World），直到它完成收集。
到现在为止，它依然是虚拟机运行在Client模式下的默认新生代收集器。它的优点是：简单而高效（与其他收集器的单线程比），Client模式下新生代首选。
（2）ParNew收集器
就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余相同。Server模式下的新生代收集器首选。因为除了Serial之外，目前只有它能与CMS收集器（第一款并发收集器，用来收集老年代）配合工作。CMS没办法和新生代Parallel Scavenge收集器配合工作，所以老年代选CMS时新生代只能选择Serial或ParNew之一。
（3）Parallel Scavenge收集器
使用复制算法，并行多线程的新生代收集器。CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput），吞吐量=业务运行时间/（业务运行时间+垃圾收集时间）。
停顿的时间越短用户体验就越好；而高吞吐量则可以最高效率地利用CPU时间，主要适合在后台运算而不需要太多交互的任务。
和ParNew的主要区别：可控制吞吐量（吞吐量优先），也可以让虚拟机根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大吞吐量，这种方式被称为GC自适应的调节策略（GC Ergonomics）。
（4）Serial Old收集器
Serial的老年代版本，单线程收集器，使用标记-整理算法。主要也是被Client模式下的虚拟机使用，如果是Server模式，它还有两大用途：一是在JDK1.5前与parallel Scavenge搭配使用，另一个就是作为CMS的后备预案，在并发收集发生Concurrent Mode Failure时使用。
（5）Parallel Old收集器
Parallel Scavenge的老年代版本，使用标记-整理算法。JDK1.6后提供，在此之前如果新生代选了parallel Scavenge，老年代除了Serial Old外别无选择，而单线程的Serial Old在服务端性能上不佳（无法利用服务器多CPU的处理能力）。在注重吞吐量及CPU资源敏感的场合，可以优先考虑Parallel Scavenge加Parallel Old组合。
（6）CMS收集器（Concurrent Mark Sweep）
基于标记—清除算法，是一种以获取最短回收停顿时间为目标的收集器，适用于B/S系统等重视服务的响应速度的场景下。运作过程相对前几种更复杂，四个步骤：
（1）初始标记（CMS initial mark）
（2）并发标记（CMS concurrent mark）
（3）重新标记（CMS remark）
（4）并发清除（CMS concurrent sweep）
初始标记、并发标记仍需要Stop the World，初始标记只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段是进行GC Roots Tracing的过程，重新标记是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段耗时比初始标记稍长，但远比并发标记时间短。
总的来说，CMS收集器的内存回收过程是和用户线程一起并发地执行，所以优点就是：并发收集、低停顿。缺点：
1）CMS对CPU资源非常敏感，并发阶段虽然不会导致用户线程停顿，但会因为占用一部分线程而导致应用程序变慢，总吞吐量降低。
2）无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另一次Full GC的发生。
由于在CMS清理阶段用户线程还在运行，新的垃圾不断产生，但是新垃圾在标记之后，只能下一次再处理，这些垃圾就是浮动垃圾。所以还需要留出足够的内存空间给用户线程使用（老年代使用68%空间就会触发），如果应用中老年代增长不快，可以调高触发百分比，以降低回收次数获取更好的性能。预留的内存不够就会产生Concurrent mode failure失败，此时虚拟机启动预案：临时启用Serial Old来重新进行老年代垃圾回收，停顿时间就长了。所以触发百分比太高容易导致大量失败，性能反而降低。
3）收集结束时会产生大量空间碎片。CMS提供开关用来整理碎片，但是这样停顿时间会变长，虚拟机设计者提供另一个参数用于设置在执行多少次不压缩的Full GC后，跟着来一次压缩的。
（7）G1收集器（Garbage First）
收集器技术发展的最前沿成果，JDK1.7正式发布。
与CMS相比的改进：
1）基于标记-整理算法实现，不会产生空间碎片，这对长时间运行的应用系统非常重要。
2）可以非常精确的控制停顿，既能让使用者明确指定在一个长度M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎是实时Java（RTSJ）的垃圾收集器的特征了。
由于极力避免全区域的垃圾收集，G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，之前的收集器收集范围都是整个新生代或老年代，而G1将整个堆划分为多个大小固定的独立区域（Region），并跟踪这些区域里的垃圾堆积程度，在后台维护一个优先列表。每次根据允许的收集时间，优先回收垃圾最多的区域，这保证了G1在有限的时间里可以获得最高的收集效率。