1. 概述
在Java内存区域里讲了Java的内存运行时数据区域分为如下5个部分
- 程序计数器(Program Counter)
- 虚拟机栈(Virtual Machine Stack)
- 本地方法栈(Native Method Stack)
- 堆(Heap)
- 方法区(Method Area)
其中前三个数据区域随着线程的启动而创建，终止而销毁，这三个区域的内存回收具有确定性，不需要过多考虑回收问题。所以JVM的垃圾回收机制的注意力就集中于堆和方法区，其中对堆的GC性价比是最高的，一般可以回收70%~95%的空间。
2. GC过程
首先讨论的是对堆的GC，在这之前我们应该知道要进行垃圾回收的步骤应该是
- 知道哪些对象需要回收？
- 用什么方式去回收？
判断对象的存活
针对第一个问题我们得确定堆中对象的“存活”，一个对象的“存活”其实就是能否通过任何途径使用该对象，下面通过一段Code看下就明白：
public class Main{
public static void main(String[] args){
A a = new A();
a = null;
}
}
在这段Code里面，一开始创建一个A类型的对象，变量a持有这个对象的引用，接着a被赋值为null后。从此就无法通过任何变量来使用这个对象了，那么这个对象也就是所谓的“死亡”了，而GC的 就是这些对象。接下来有两种方法可以找出堆中存活和死亡的对象。
引用计数法(Reference Counting)
给每一个对象添加一个引用计数器，每当对象被引用，就对该对象的引用计数器加一，当引用失效时引用计数器就减一。直到对象的引用计数器为0时该对象就是已死亡，可被GC。这种方法看起来简单高效，但JVM却没有使用它来判断对象的存活，原因是它很难解决对象之间相互引用的问题。还是来一段Code看下：
public class Main{
public static void main(String[] args){
A a = new A();
B b = new B();
a.ref = b;
b.ref = a;
a = null;
b = null;
}
}
在这段Code中，a和b两个引用最后都null，也就是无法通过它们来使用一开始创建的两个对象，虽然这样它们却无法回收，原因是创建的两个对象相互引用导致两个对象的引用计数器都不为0。所以也就有了第二种方法（可达性分析）来解决这个问题。
可达性分析算法(Reachability Analysis)
把堆中所有对象当成一幅有向图中的所有点，对象之间的引用构成了点与点的之间的路径。接着从一系列被称为GC Roots（一些被引用的对象）的点出发遍历整个图，图中所有可以到达的点都是存活的对象，而那些不可到达的点则为死亡对象，将被GC。
可充当GC Roots的对象有下面几种：
- 虚拟机栈中栈帧中本地变量表中变量引用的对象
- 本地方法栈中本地的方法引用的对象
- 方法区中类静态变量引用的对象
- 方法区中常量引用的对象
垃圾回收算法
解决完第一个问题（判断对象的存活）后，就可以去回收这些对象占用的内存了，至于怎么回收这些内存，有下面几种算法：
标记-清除算法(Mark-Sweep)
标记-清除算法如同它的名字一样，有标记和清除两个阶段。其中的标记阶段就是上面说到的确定对象的存活阶段，确定了要回收的对象后就回收死亡的对象，存活的对象留在原地。标记清除算法是最基础的回收算法，它有两个缺点：
- 标记和清除阶段效率都不高
-
清除之后内存会产生大量不连续的碎片，导致分配大内存对象困难
标记清除算法
复制算法(Copying)
复制算法将内存分为大小相等的两块，每次只使用一块，待这块内存用完，将这一块上存活的对象复制到另一块上，再把存在垃圾对象的那一块占用的内存一次清掉。这样做效率高的原因是存活的对象远远少于死亡的对象，从而只需复制少量的存活对象。
复制算法解决了标记-清除算法的清除阶段效率低的问题和碎片问题但却使可用内存减少一半。其实有个办法可以解决这个问题：
IBM公司的专业研究表明新生代中的对象98%是“朝生夕死”的，所以并不用按照1:1来划分空间，而是将内存分为3块。一块80%大小的Eden空间和两块10%大小的Survivor空间，每次使用一块Eden和一块Survivor，当需要回收时，将使用中的Eden和Survivor上的存活对象复制到另一块Survivor上，最后直接清理使用过的Eden和Survivor的内存空间。这样就使得空间的利用率达到90%。但如果存活的对象超过10%的话，Survivor的空间就不够用了，这时就需要依赖老年代进行分配担保。
标记整理算法(Mark-Compact)
相比于复制算法，标记整理算法使用与适用于老年代这种对象存活率高的区域。标记整理和标记清除很相似，前面的标记步骤都一样，不一样在标记整理在清除前多做了整理步骤让存活的对象向一端移动，最后在清除掉端边界以外的内存。
分代收集算法(Generational Collection)
因为现在的商用JVM的垃圾回收都采用分代收集算法，所以一般把堆内存划分为新生代和老年代。刚创建的对象存在于新生代中，当有一些对象经历垃圾回收达到一定次数还存活下来的话，这些对象将进入老年代，所以老年代里的对象每次GC存活率都很高。因此针对于新生代和老年代对象的不同存活率，可以分别采取不同的垃圾回收算法，对于对象存活率低的新生代采用复制算法，而对于对象存活率高的老年代采用标记清除或标记整理算法。
以上介绍的是关于堆中的GC，下面来说下方法区的GC。
方法区的GC
方法区在HotSpot虚拟机中是永久代，相比于堆中的新生代和老年代，永久代进行垃圾回收的性价比更低。
方法区的垃圾回收主要回收废弃常量和无用的类，其中常量来自于方法区的常量池，包括字面值常量和符号引用。回收常量跟回收堆中对象非常类似，以字面值常量为例，如果不存在其他对象引用该字面值常量，如果发生GC且有必要的话，该字面值常量会被回收。对于无用的类的判断比较苛刻，必须同时满足下列三个条件：
- 该类的所以实例都被回收
- 加载该类的类加载器已经被回收
- 该类对应的Class对象没有在任何地方被引用
不过也可以满足了上面的三个条件也不进行回收，可以通过设置虚拟机参数来控制回收。
3. 内存分配策略
对象优先在 Eden 分配
对象优先在新生代的 Eden 区分配，当 Eden 区空间不够时，执行Minor GC大对象直接进入老年代
设置 -XX:PretenureSizeThreshold 参数，大于该参数的值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制长期存活的对象进入老年代
对象头的Mark word拥有一个存储分代年龄字段，每经历一次 Minor GC 存活下来该年龄字段加1，直到该年龄超过 XX:MaxTenuringThreshold 设置的值（默认15），则移动到老年代。动态对象年龄判定
若 Survivor 区中同年龄所有对象大小总和大于 Survivor 空间一半，则年龄大于等于该年龄的对象可以直接进入老年代。空间分配担保
在发生 Minor GC 之前，JVM 先检查老年代最大可用连续空间是否大于新生代所有对象大小，成立的话 Minor GC 确认是安全的，则进行Minor GC；否则如果 HandlePromotionFailure 设置的值为true并且老年代最大可用连续空间大于历次晋升到老年代对象的平均大小，则进行 Minor GC，否则进行 Full GC。
4. Minor GC 与 Full GC
触发条件
- Minor GC：当 Eden 区空间满时，就将触发 Minor GC
- Full GC：
- 调用 System.gc() 大多情况下回触发Full GC，通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用System.gc()。
- 老年代空间不足
- 空间分配担保失败
- JDK 1.7 及以前的永久代空间不足
