一、概述
垃圾收集（Garbage Collection, GC）,历史比Java更久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的三件事情：
- 哪些内存需要回收
- 什么时候回收
- 如何回收
为什么了解GC和内存分配？
当需要排查各种内存溢出，内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，就需要对这些“自动化”的技术实施必要的监控和调节。
垃圾搜集器主要关注的内存范围
程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧（jvm为每个新创建的线程都分配一个堆栈。堆栈以帧为单位保存线程的状态。jvm对堆栈只进行两种操作：以帧为单位的压栈和出栈操作。）随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译器可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或县城结束时，内存就自然就跟随着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。
二、如何判断对象已死
1.引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。
优点：实现简单，判定效率高，大部分情况下它都是一个不错的算法。
缺点：很难解决对象之间的相互循环引用的问题。（所以Java并没有选用引用计数算法）
//示例代码
A a =new A();
B b =new B();
A.data=b;
B.data=a;
2.根搜索算法
通过一系统的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明对象是不可用的。
3.再谈引用
在JDK1.2之前，Java中的引用的定义很传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。
JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，这四种引用强度依次逐渐减弱。
- 强引用就是指在程序代码之中普遍存在的，类似“Object obj =new Object()” 这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
- 软引用用来描述一些还有用，但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类实现软引用。下面例子摘自其他文章，点击查看来源。
Browser prev = new Browser(); // 获取页面进行浏览 SoftReference sr = new SoftReference(prev); // 浏览完毕后置为软引用 if(sr.get()!=null){ rev = (Browser) sr.get(); // 还没有被回收器回收，直接获取 }else{ prev = new Browser(); // 由于内存吃紧，所以对软引用的对象回收了 sr = new SoftReference(prev); // 重新构建 } - 弱引用也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。简而言之，在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
String str=new String("abc"); WeakReference<String> abcWeakRef = new WeakReference<String>(str); str=null; - 虚引用也被称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。作用：为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
4.根搜索算法判定对象死亡的过程
在该算法中宣告一个对象死亡，至少要经历两次标记过程：
1.如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，进行第一次标记并筛选。筛选条件：此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，都是没有必要。会直接进行回收。
2.如果有必要执行finalize()方法，则该对象将会被放置在一个F-Queue的队列中，稍后虚拟机会自动建立一个低优先级的Finalizer线程去执行该对象的finalize()方法，执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，第二次标记，进行回收，否则，对象“复活”。
注：finalize()是Object的protected方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。
根搜索算法判定对象死亡的过程演示代码
/**
* 1.此代码演示对象在被GC时自我拯救
* 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
*
*/
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK=null;
public void isAlive(){
System.out.println("I am Alive");
}
protected void finalize()throws Throwable{
super.finalize();
System.out.println("finalize method executed!");
FinalizeEscapeGC.SAVE_HOOK=this; //引用自救
}
public static void main(String[] args) throws InterruptedException {
SAVE_HOOK=new FinalizeEscapeGC();
SAVE_HOOK=null;
System.gc();//该语句之后，GC将其第一次标记，但是由于自救，该对象没有被第二次标记，活了下来
Thread.sleep(500); //由于Finalizer方法优先级很低，暂停0.5s，以等待它
if(SAVE_HOOK!=null){ //验证结果
SAVE_HOOK.isAlive();
}else{
System.out.println("Dead");
}
//下面这段代码与上面的完全相同，但是这次自救却失败了。
SAVE_HOOK=null;
System.gc();//该语句之后，GC将其第一次标记，进行筛选，由于finalize()方法已经执行过一次，所以会直接被回收
Thread.sleep(500); //由于Finalizer方法优先级很低，暂停0.5s，以等待它
if(SAVE_HOOK!=null){ //验证结果
SAVE_HOOK.isAlive();
}else{
System.out.println("Dead");
}
}
}
5.回收方法区
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。
回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，例如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，欢呼华说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如何在这时候发售内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
判断常量是否废弃比较简单，而判定一个无用的类需要同时满足下面3个条件才能算是“无用的类”：
1.该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例
2.加载该类的ClassLoader已经被回收。
3.该类对应的Java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，这里说的仅仅是“可以”，而不是和对象一样，不适用了就会必然回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX：+TranceClassLoading、-XX:+TraceClassUnLoading查看类的加载和卸载信息。-verbose:class和-XX：+TraceClassLoading可以在Product版的虚拟机中使用，但是-XX：TraceClassUnLoading参数需要fastdebug版的虚拟机支持。
在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。
三、垃圾搜集算法
1.标记-清除算法
最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后同意回收掉所有被标记的对象，它的标记过程在正如前面说的那样相同。
缺点：1）效率问题，标记和清除过程的效率都不高；、
2）另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前出发另一次垃圾搜集动作。
2.复制算法为了解决效率问题，一种称为“复制”（Copying）的搜集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
优点：实现简单，运行高效。
缺点：内存缩小为原来的一半。
现在的商业虚拟机都采用这种搜集算法来回收新生代，IBM的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块比较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收事，将Eden和Survivor中还存活着的对象一次性拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代可用内存空间为整合新生代容量的90%，只有10%的内存是会被“浪费”得。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）
3.标记-整理算法
复制搜集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4.分代搜集算法
当前商业虚拟机的垃圾搜集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的搜集算法。
四、垃圾搜集器
如果说收集算法是对内存回收的方法论，垃圾收集器就是内存回收的具体实现。
1.Serial收集器
曾经是虚拟机新生代收集的唯一选择，是一个单线程的收集器。但它单线程的意义并不是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必修暂停其他所有的工作线程，直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法
优点：简单高效,运行在Client模式下的虚拟机是个很好的选择。
2.ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World 、对象分配规则、回收策略等都与Serial收集器完全一样。
3.Parallel Scavenge收集器
Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。它的目标是达到一个可控制的吞吐量（Throughput，吞吐量=运行用户代码时间/（运行代码时间+垃圾收集时间））
4.Serial Old收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。
5.Parallel Old 收集器
Parallel Old是Parallel Scavenge 收集器的老年代版本，使用多线程和“标记-整理”算法。
6.CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记-清除”算法实现的。收集过程分为四个步骤，包括：初始标记、并发标记、重新标记、并发清除。
优点：并发收集、低停顿。
缺点：对CPU资源非常敏感。无法处理浮动垃圾，收集结束时会产生大量空间碎片。
7. G1收集器
G1(Garbage First) 收集器是当前收集器技术发展的最前沿成果，它与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记-整理”算法实现的收集器。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度M毫秒的时间片内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。
G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的由来）
五、内存分配与回收策略
Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存。
1.对象优先在Eden分配
2.大对象直接进入老年代
所谓大对象就是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组。
3.长期存活的对象将进入老年代。虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍存活，并且能被Surivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1.对象在Survivor区中每熬过一次Minor GC,年龄就增加一岁，当它的年龄到一定程度（默认为15岁）时，就会被晋升到老年代中。对象晋升老年代的年龄，可以通过参数-XX：MaxTenuringThreshold设置。
4.动态对象年龄判定。为了更多地适应不同程度的内存状态，虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold。
5.空间分配担保。在发生Minor GC(指新生代GC动作)，虚拟机会检测之前每次晋升到老年代的平均水平是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果成功，那么只会进行进行Minor GC;如果不循序，则也要改为进行一次Full GC。
前面提高过，新生代使用收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况时，就需要老年代进行分配担保，让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来，在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。