概述
我们都知道Java的内存管理机制非常的“自动化”，可以让我们Java工程师可以免去内存管理的苦恼，但我们学习GC和内存分配也是有意义的：当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，只有了解了其原理，我们才能更好的监控与调节这些问题。说起垃圾回收(Garbage Collection,GC)，大部分人都把这项技术当做Java语言的伴生产物。这其中GC真正需要解决的3个问题值得我们所有想要理解和学习GC的人去思考：
1.哪些内存需要回收？ 2.什么时候回收内存？ 3.如何回收内存？
带着这三个问题去思考和学习，我相信必然能够让我们更加的理解Java的垃圾回收机制。
首先我们看第一个问题，哪些内存需要回收？我们知道，在Java堆中存放着几乎所有的对象实例，垃圾回收器在对堆进行回收前，第一件事就是要确定这些对象哪些还“存活”着，哪些已经“死去”(即不可能再被任何途径引用的对象)。 那么“死去”的这些对象就是我们需要回收的对象了。下面就介绍判断对象是否存活所用到的算法。
一、判断对象是否存活的算法
1.引用计数算法(Reference Counting)
算法分析
引用计数是垃圾收集器中的早期策略，它的原理是给对象添加一个引用计数器，每当一个地方引用它时，计数器值就加1；让引用失效时，计数器值就减1；任何时刻计数器为0的对象是不可能再被使用的。
优缺点
优点：引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。
缺点：无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0。 引用计数算法无法解决循环引用问题，例如：
public class Main {
public static void main(String[] args) {
MyObject object1 = new MyObject();
MyObject object2 = new MyObject();
object1.object = object2;
object2.object = object1;
object1 = null;
object2 = null;
//假设在这行发生GC，object1和object2能否被回收？
System.gc();
}
}正是因为该方法存在这样的问题，所以目前主流的Java虚拟机里面已没有选用引用计数算法来判断对象是否存活(管理内存)。
2.可达性分析算法(Reachability Analysis)
2.1算法分析
在主流的商用程序语音（Java、C#）的主流实现中，都是通过可达性分析算法(也可称为根搜索算法)来判断对象是否存活的。该算法是从离散数学中的图论引入的，这个算法的基本思路是：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路称为引用链(Refence Chain)，当一个对象到GC Roots没有任何链表相连(用图论的话来说，就是GC Roots到这个对象不可达)时，则证明此对象不可用。下图所展示的，对象object5、object6、object7虽然互相有关联，但是他们到GC Roots是不可达的，所以他们将会被判定是可回收的对象。
Java中可作为GC Roots的对象有
1.虚拟机栈中引用的对象（本地变量表）
2.方法区中静态属性引用的对象
3. 方法区中常量引用的对象
4.本地方法栈中引用的对象（Native对象）
接下来是我们需要思考的第二个问题，什么时候回收内存？这个问题可以从HotSpot的算法实现中去找到答案
二、HotSpot算法实现
1.枚举根节点
以可达性分析中从GC Roots 节点找引用链这个操作为例，可作为GC Roots 的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在的很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。
另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行—这里的一致性的意思是指在整个分析期间整个执行系统看起来像被冻结在某个时间点上，不可以出现在分析过程中对象引用关系还在不断的变化，该点不满足的话分析结果的准确性就无法得到保证。这点导致GC进行时必须停顿所有Java执行线程（Sun称这件事情为“Stop The World”）的其中一个重要的原因，即使在号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。
目前主流的Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏的检查完所有的执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存在着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。
2.安全点
在OopMap的协助下，HotSpot可以快速且准确的完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那么将需要大量的额外空间，这样GC 的空间成本将会变得很高。
实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录这些信息，这些问题称为（Safepoint），即程序执行时并非所有地方都能停顿下来开始GC，只有到达安全点才能暂停。Safepoint的选定既不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时负荷。所以，安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的—因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用。例如：方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。
对于SafePoint，另外一个需要考虑的问题是如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都跑到最近的安全点再停顿下来，有两种方案：
1. 抢先式中断（Preemptive Suspension）：在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让其跑到安全点上；（几乎没有虚拟机使用这种方式）
2. 主动式中断（Voluntary Suspension）：当GC需要中断线程时，不直接对线程操作，仅仅简单设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。其中轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。
现在主流的虚拟机都是使用的主动式中断的方式想要GC事件。
3.安全区域
上面讲述的Safepoint似乎已经完美的解决了如何进入GC的问题，但实际情况却不一定。Safepoint机制保证了程序执行时，在不长的时间内就会遇到可进入GC的Safepoint。但是，程序不执行的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM显然也不太可能等待线程重新被分配CPU时间。这种情况，就需要安全区域来解决了。
安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。可以把安全区域看做是扩展了的安全点。
在线程执行到安全区域的代码时，首先标识自己进入到了安全区域，这样，当这段时间内JVM要发起GC时，就不用管标识自己为安全区域状态的线程了；在线程要离开安全区域时，它要检查是否系统已经完成了枚举根节点（或整个GC过程），如果完成了，那么线程就继续执行，否则就必须等待到直到收到可以安全离开安全区域的信号为止。
好了，到了最最精彩也最最核心的时刻，就是关于如何回收内存。这一块的知识点也是平时面试官会多次考到的地方，所以需要重点学习！
三、垃圾回收算法
1.标记-清除算法
最基础的垃圾收集算法，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成之后统一回收掉所有被标记的对象。
优点：原理简单
缺点有两个：1.效率问题，标记和清除效率都不高。2，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多会导致当程序需要为较大对象分配内存时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.复制算法
将可用内存按容量分成大小相等的两块，每次只使用其中一块，当这块内存使用完了，就将还存活的对象复制到另一块内存上去，然后把使用过的内存空间一次清理掉。
优点：能够解决内存碎片化的问题。
缺点：堆空间的使用效率极其低下（毕竟分成两半，一次只使用一半）
3.标记-整理算法
标记-整理算法在标记-清除算法基础上做了改进，标记阶段是相同的标记出所有需要回收的对象，在标记完成之后不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，在移动过程中清理掉可回收的对象，这个过程叫做整理。
优点：内存被整理以后不会产生大量不连续内存碎片问题。
缺点：复制算法在对象存活率高的情况下就要执行较多的复制操作，效率将会变低，而在对象存活率低的情况下使用标记-整理算法效率会大大提高。
4.分代收集算法：
根据内存中对象的存活周期不同，将内存划分为几块，java的虚拟机中一般把内存划分为新生代和年老代，当新创建对象时一般在新生代中分配内存空间，当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中，当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。
分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的回收算法，以便提高回收效率。
年轻代（Young Generation）
1.所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
2.新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。
3.当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收
4.新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)
年老代（Old Generation）
1.在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
2.内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。
持久代（Permanent Generation）
用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。
四、垃圾回收器
新生代收集器使用的收集器：Serial、PraNew、Parallel Scavenge
老年代收集器使用的收集器：Serial Old、Parallel Old、CMS
Serial收集器（复制算法)
新生代单线程收集器，标记和清理都是单线程，优点是简单高效。
ParNew收集器(停止-复制算法)
新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。
Parallel Scavenge收集器(停止-复制算法)
并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。
Serial Old收集器(标记-整理算法)
老年代单线程收集器，Serial收集器的老年代版本。
Parallel Old收集器(停止-复制算法)
Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先
CMS(Concurrent Mark Sweep)收集器（标记-清理算法）
高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择
G1(Garbage-First)收集器 (最前沿也是最复杂的收集器)
Region 区域化垃圾收集器：最大好处是化整为零，避免全内存扫描，只需要按照区域来进行扫描即可。
五、GC的执行机制
由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。
Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。
Full GC
对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：
1.年老代（Tenured）被写满
2.持久代（Perm）被写满
3.System.gc()被显示调用
4.上一次GC之后Heap的各域分配策略动态变化
六、Java有了GC同样会出现内存泄露问题
1.静态集合类像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，所有的对象Object也不能被释放，因为他们也将一直被Vector等应用着。
Static Vector v = new Vector();
for (int i = 1; i<100; i++) {
Object o = new Object();
v.add(o);
o = null;
}在这个例子中，代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环中，我们不断的生成新的对象，然后将其添加到 Vector 对象中，之后将 o 引用置空。问题是当 o 引用被置空后，如果发生 GC，我们创建的 Object 对象是否能够被 GC 回收呢？答案是否定的。因为， GC 在跟踪代码栈中的引用时，会发现 v 引用，而继续往下跟踪，就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管o 引用已经被置空，但是 Object 对象仍然存在其他的引用，是可以被访问到的，所以 GC 无法将其释放掉。如果在此循环之后， Object 对象对程序已经没有任何作用，那么我们就认为此 Java 程序发生了内存泄漏。
2.各种连接，数据库连接，网络连接，IO连接等没有显示调用close关闭，不被GC回收导致内存泄露。
3.监听器的使用，在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露。
参考资料：
书籍：周志明-《深入Java虚拟机》 第3章
博客： 1.深入理解 Java 垃圾回收机制
