今天我们将一起学习Java虚拟机使用垃圾收集算法和常见的垃圾收集器。Java虚拟机内存区域的程序计数器、虚拟机栈和本地方法栈3个区域是随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出出栈和入栈。每一个栈帧中分配多少内存基本上是在类结构确定下来的时候就已知的，因此这个几个区域的内存分配和回收都具备确定性，在这几个区域就不需要过多考虑回收问题，因为方法结束或者线程结束时，内存自然就跟着回收了。而Java堆和方法区就不一样，一个接口中的多个类实现需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间是才能知道会创建哪些对象，这部分内存和回收是动态的，垃圾收集器所关注的是这部分内存。
一、判断对象是否存活
在垃圾收集器对对象进行回收前，首先需要判断哪些对象是存活的。
1、引用计数算法
给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器值就减1；任何时候计数器为0的对象就是不可能在被使用的。但是这样算法的存在的问题是很难解决对象之间相互循环引用的问题。当前主流的Java虚拟机都没有采用这样的算法。我们看如下列子：testGC()方法执行后，objA和objB会不会被GC呢？
package gc;
public class ReferenceCountingGC
{
public Object instance =null;
private static final int _1MB=1024*1024;
private byte[] bigSize=new byte[2*_1MB];
public static void testGC()
{
ReferenceCountingGC objA=new ReferenceCountingGC();
ReferenceCountingGC objB=new ReferenceCountingGC();
objA.instance=objB;
objB.instance=objA;
objA=null;
objB=null;
System.gc();
}
public static void main(String[] args)
{
testGC();
}
}
GC日志输出结果：
[GC (System.gc()) [PSYoungGen: <strong>5735K->584K</strong>(18944K)] 5735K->592K(62976K), 0.0008309 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen:<strong> 584K->0K</strong>(18944K)] [ParOldGen: 8K->514K(44032K)] 592K->514K(62976K), [Metaspace: 2502K->2502K(1056768K)], 0.0058089 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] Heap PSYoungGen total 18944K, used 491K [0x00000000eb400000, 0x00000000ec900000, 0x0000000100000000) eden space 16384K, 3% used [0x00000000eb400000,0x00000000eb47aff0,0x00000000ec400000) from space 2560K, 0% used [0x00000000ec400000,0x00000000ec400000,0x00000000ec680000) to space 2560K, 0% used [0x00000000ec680000,0x00000000ec680000,0x00000000ec900000) ParOldGen total 44032K, used 514K [0x00000000c1c00000, 0x00000000c4700000, 0x00000000eb400000) object space 44032K, 1% used [0x00000000c1c00000,0x00000000c1c808e8,0x00000000c4700000) Metaspace used 2511K, capacity 4486K, committed 4864K, reserved 1056768K class space used 273K, capacity 386K, committed 512K, reserved 1048576K
对象objA和对象objB都有字段instance，进行objA.instance=objB及objB.instance=objA赋值操作，实际上着两个对象再无任何引用，他们互相引用对方，导致引用计数都不为0，于是引用计数算法无法通知GC收集器回收他们。但是结果是被收回了（5735K->584K），所以我们的虚拟机采用的不是引用计数算法。
2、 可达性分析算法
在主流的商用程序语言的主流实现中，都是通过可达分析算法来判断对象是否存活的。这个算法的基本思想就是通过一系列成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链是，则证明对象是不可用的，将会被判定为可回收的对象，但是不会被立即回收，需要被标记两次之后才会被回收。
2.1 Java语言中，可作为GC Roots的对象有：
1） 虚拟机栈（栈帧中本地变量表）中引用的对象。
2）方法区中类静态属性引用的对象。
3）方法区中常量引用的对象。
4） 本地方法栈中JNI（一般说的Native方法）引用的对象。
二、引用
无论是引用计数法判断对象的引用数量，还是可达性分析算法判断对象的引用链是否可达，判断对象是否存活都与“引用”有关。Java中的引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这种引用强度一次逐渐减弱。
1） 强引用就是指在程序代码之中普遍存在的，类似"Object obj=new Object()"这类的引用，只要强引用存在，垃圾收集器永远不会回收掉被引用的对象。
2） 软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
3） 弱引用也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象，在JDK1.2之后，提供了WeakReference类来实现弱引用。
4） 虚引用是最弱的一种引用关系。一个对象是否所有虚引用存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联唯一目的就是能在这个对象呗收集器回收时得到一个系统通知。在JDK1.2后，提供了PhantomReference类来实现虚引用。
三、对象的自我拯救
即使在可达分析算法中不可达的对象，也并非立即就被回收，需要经过两次标记。如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者finalize()方法被虚拟机已经调用过，虚拟机将这两种都视为没有必须要执行。
如果这个对象被判定为由必要执行finalize()方法，那么这个对象将会放置在一个F-Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行。如果对象在finalize()方法中重新与引用链上的任何对象建立关联即可，比如把自己（this关键字）赋值给某个类的变量或者对象的成员变量，那在第二次标记是它将被移除即将回收的集合；如果对象这个时候还没有逃脱，那基本上他就被回收了。来看如下代码：
package gc;
/**
* 此代码演示了两点
* 1、对象可以在被GC时自我拯救
* 2、这种自救机会只有一次
* @author Administrator
*
*/
public class FinalizeEscapeGC
{
public static FinalizeEscapeGC SAVE_HOOK=null;
public void isAlive()
{
System.out.println("yes,i am still alive");
}
@Override
protected void finalize() throws Throwable
{
super.finalize();
System.out.println("finalize method executed");
FinalizeEscapeGC.SAVE_HOOK=this;
}
public static void main(String[] args) throws Throwable
{
SAVE_HOOK=new FinalizeEscapeGC();
//对象第一次拯救自己
SAVE_HOOK=null;
System.gc();
//因为finalize方法优先级很低，暂停0.5秒等待它
Thread.sleep(500);
if(SAVE_HOOK!=null)
{
SAVE_HOOK.isAlive();
}else
{
System.out.println("no, i am dead");
}
//再次拯救，失败
SAVE_HOOK=null;
System.gc();
Thread.sleep(5000);
if(SAVE_HOOK!=null)
{
SAVE_HOOK.isAlive();
}else
{
System.out.println("no, i am dead");
}
}
}
输出结果：
finalize method executed yes,i am still alive no, i am dead
第一次拯救成功，第二次却失败。任何一个对象的finalize()方法都只会被对象自动调用一次，如果对象面临下一次回收，它的finalize()方法会被再次执行。需要注意的时，最好不要使用该方法来拯救对象。
四、回收方法区
在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而在方法区的垃圾收集效率远低于此。方法区的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，例如一个字符串“abc"已经进入了常量池中，但是当前系统没有任何一个String对象是叫做”abc“的，换句话说，就是没有任何String对象引用常量池中的”abc"常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc"常量就会被系统清理出常量池。常量池中其他类、方法、字段的符号引用也与此类似。
判定一个类为无用类的3个条件：
1） 该类所有实力都已经被回收，也就是Java堆中不存在该类的任何实例。
2）加载该类的ClassLoader已经被回收。
3） 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
五、垃圾收集算法
1、标记-清除算法
算法分为标记清除两个阶段：首先标记出所需要回收的对象，在标记完成后统一回收所有标记的对象，它的标记过程就是上面提到的。这种算法主要有两个不足：一是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配打对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。
2、复制算法
它将可能内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。这种算法效率高，代价是将内存压缩为原来的一半。现在的商业虚拟机都采用这种手机算法来回收新生代。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，当然这样没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用的时候，需要依赖其他内存（老年代）进行分配担保。
3、标记-整理算法
复制收集算法在对象存活率较高是就要进行较多的复制操作，效率将会变低。根据老年代的特点，提出了标记-整理算法，标记过程任然与“标记-清除算法”一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4、 分代收集算法
当代商业虚拟机的垃圾收集算法都采用“分代收集算法”，根据对象存活周期的不同将内存划分为几块。一般是Java堆中分为新生代和老年代，这样就可以根据各个年代的特点采用岁适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象的存活率高，没有额外空间对它进行担保，就必须采用“标记-清理算法”或者“标记-整理算法”来实现回收。
六、垃圾收集器（针对HotSpot虚拟机而言）
1、Serial收集器
这个收集器时一个单线程的收集器，进行垃圾收集时，必须暂停其他所有工作线程，直到垃圾收集结束。目前用于Client模式下的默认新生代收集器。其优点是，简单而高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，垃圾收集效率十分高。
2、ParNew收集器
ParNew收集器时Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则等与Serial收集器一样。目前是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中一个与性能无关的但很重要的原因是，除了Serial收集器外，目前只有他能与CMS（Concurrent
Mark Sweep）收集器配个工作。
3、Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。该收集器的目标是达到一个可控 的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的壁纸，即吞吐量=运行用户代码时间/(用户代码运行时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那吞吐量就是99%。
高吞吐量可以高效率得利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
4、 Serial Old收集器
Serial Old收集器时Serial收集器的老年代版本，同样也是一个单线程收集器，使用“标记-整理算法”。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent
Mode Failure时使用。
5、 Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源铭感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
6、 CMS收集器
CMS(Concurrent Mark Sweep）收集器是一种以获得最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间短暂，以给用户带来良好的体验。CMS是一种基于“标记-清除”算法实现的 ，运作过程分为四个步骤：
1）初始标记
2）并发标记
3）重新标记
4）并发清除
其中，初始标记、重新标记这两个步骤仍然需要“stop the world"。初始标记仅仅实在是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修改并发标记期间因为用户程序持续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍微长一些，但远比并发标记时间短。
由于整个过程耗时最长的并发标记和并发清除过程收集线程都可以与用户线程一起工作，所以，总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
缺点如下：
1）CMS收集器对CPU资源非常敏感，在并发的时候占用CPU资源会导致应用程序变慢，总吞吐量会降低，在CPU数量少的情况下会很明显。
2）CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure"失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然还会有新的垃圾产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉他们，这一部分叫做”浮动垃圾“。
3） 由于CMS是基于“标记-清除”算法实现的收集器，这必然会产生很多空间碎片，将会给大对象分配带来很大的麻烦，往往老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不再次出发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认开启），用于CMS收集器顶不住要进行Full GC是开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。
7、G1收集器
G1(Garbage-First）收集器时当今收集器技术发展的最前沿成果之一。G1是一款面向服务端应用的垃圾收集器，与其他GC收集器相比，G1具备如下特点：
1） 并行与并发：G1能允许利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
2）分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配个就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获得更好的收集效果。
3）空间整合：与CMS的标记-清除算法不同，G1从整体来看是采用基于标记-整理算法实现的收集器，从局部上来看是基于复制算法实现的。这两种算法都不会在G1运行期间产生内存空间碎片，收集后能够提供规整的可用内存。
4）可预测的停顿：这是G1相对于CMS的另一优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
在G1之前的其他收集器进行收集的范围是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他手机器有很大差别，他将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不在是物理隔离的了，他们都是一部分Region的集合。
G1收集器值所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值大的Region。
关于垃圾收集器就到这里，细节的地方就不在这里多说了。
参考：
《深入java虚拟机》