为什么要学习GC？
JVM有自动回收机制，但当需 要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我 们就需要对这些“自动化”的技术实施必要的监控和调节。
为什么要GC？
如果只消耗内存不进行垃圾回收，内存迟早会被消耗完，除非内存无限大，但这是不可能的。
什么时候GC?
涉及到两种算法，引用计数算法和可达性分析算法
先说引用计数算法
给对象中添加一个引用计数器，每当有 一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0 的对象就是不可能再被使用的。但是JVM并没有使用此算法进行内存管理，主要的原因是它很难解决对象 之间相互循环引用的问题。
比如对象objA和objB都有字段 instance，赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引 用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引 用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。
可达性分析算法
在主流的商用程序语言的主流实现中， 都是称通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思 路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所 走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连 （用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如 图所示，对象object 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达 的，所以它们将会被判定为是可回收的对象。
在Java语言中，可作为GC Roots的对象包括下面几种：
虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI（即一般说的Native方法）引用的对象。
谈谈引用
无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引 用链是否可达，判定对象是否存活都与“引用”有关。当内存空间还足够时，则能保留在内存之中；如果内存 空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这 样的应用场景。
Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。
强引用就是指在程序代码之中普遍存在的，类似“Object obj=new Object（）”这类的引 用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
软引用是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将 要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回 收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实 现软引用。
弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的 对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够， 都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引 用。
虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引 用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一 个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在 JDK 1.2之后，提供了PhantomReference类来实现虚引用。
回收之路
对于可达性分析算法而言，要想回收对象至少要经历两次标记阶段：
1)、如果对象在进行可达性分析后没有发现和GC Roots相连的引用链，则该对象被第一次标记并进行一次筛选，筛选条件为是否有必要执行该对象的finalize方法。如果该对象没有重写finalize方法或该对象已经执行过一次finalize方法则该对象会被回收，反之则不会被回收，这个对象会被放在F-Queue的队列中。
2)、对F-Queue对象进行第二次标记如果该对象在finalize方法中关联上GCRoots引用链（如把this关键字赋值给其他变量），则在第二次标记的时候对象将从"即将回收"的集合中移除。如果对象finalize方法并没有关联则就会被回收。
回收方法区
方法区的垃圾回收，主要指回收废弃常量和无用的类
废弃常量：如果一个常量已经进入了常量池，但是当前系统没有一个对象使用了该常量，那么发生垃圾回收并且有必要时该常量就会被移除常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
无用的类：(1) 该类的所有实例都已被回收，即java堆中不存在该类的任何实例。
(2) 加载该类的ClassLoader 方法已被回收。
(3) 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过放射访问该对象的方法。
新生代与老年代的划分
年轻代（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区满了才触发)
5.长期存活的对象，进入老年代，默认为15次，初始为0，每经过一次Minor GC+1，默认15晋升老年代，也可以调整阀值5
年老代（Old Generation）
1.在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
2.内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。
3.大于阀值 PretenureSizeTreshold的直接进入老年代，避免Eden与两个Survivor产生大量的内存复制。
持久代（Permanent Generation）
用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。
垃圾回收算法
a.标记-清除算法
最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如同它的名字一样，算法分 为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有 被标记的对象。之所以说它 是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到 的。它的主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程 序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾 收集动作。
b.复制算法
为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容 量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着 的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是 对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指 针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原 来的一半，未免太高了一点。
现在的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生 代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存 分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。 当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最 后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10% 的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每 次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里 指老年代）进行分配担保（Handle Promotion）。
内存的分配担保就好比我们去银行借款，如果我们信誉很好，在98%的情况下都能按时 偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保 证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。内存的分配担保也 一样，如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时， 这些对象将直接通过分配担保机制进入老年代。
c.标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的 是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中 所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程 仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存 活的对象都向一端移动，然后直接清理掉端边界以外的内存.
d.分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算 法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆 分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代 中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付 出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间 对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。
HotSpot的算法实现
- top The World：从GC Roots进行可达性分析是，为了保持一致性，停顿所有的Java执行线程。就像时间冻结
- 准确式GC：虚拟机可以知道内存中某个位置的数据具体是什么类型
- OopMaps：用来记录对象引用，HotSpot使用,类加载过程中，把对象内的偏移量上是什么数据计算出来。
- 安全点：SafePoint 既程序执行时并非在所有地方都能停顿下来，只有安全点才能停顿。程序长时间执行的特征，例如：方法调用、循环跳转、异常跳转等
- 抢先式中断和主动式中断：抢先式首先把所有的线程全部中断，如果发现有线程不在安全点上，则回复线程；主动式中断：通过设置标志，线程执行时轮询标志，发现标志则自己中断。
- 安全区域（Safe Region）：如果程序不执行的时候，就没法中断，所以需要安全区域，一段代码片段中，应用关系不发生变化，则为安全区域
垃圾收集器
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚 拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应 用特点和要求组合出各个年代所使用的收集器。这里讨论的收集器基于JDK 1.7 Update 14之 后的HotSpot虚拟机（在这个版本中正式提供了商用的G1收集器，之前G1仍处于实验状 态）
如果两个收集器之间存在连线，就说明它们 可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。接下 来将逐一介绍这些收集器的特性、基本原理和使用场景，并重点分析CMS和G1这两款 相对复杂的收集器，了解它们的部分运作细节。
在介绍这些收集器各自的特性之前，我们先来明确一个观点：虽然我们是在对各个收集 器进行比较，但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的收集器 出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。这点不需 要多加解释就能证明：如果有一种放之四海皆准、任何场景下都适用的完美收集器存在，那 HotSpot虚拟机就没必要实现那么多不同的收集器了。
Serial收集器（复制算法)
新生代单线程收集器，标记和清理都是单线程，优点是简单高效。
Serial Old收集器(标记-整理算法)
老年代单线程收集器，Serial收集器的老年代版本。
ParNew收集器(停止-复制算法)
新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。
Parallel Scavenge收集器(停止-复制算法)
并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。
Parallel Old收集器(停止-复制算法)
Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先
CMS(Concurrent Mark Sweep)收集器（标记-清理算法）
高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择
内存分配与回收策略
Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对 象分配内存以及回收分配给对象的内存。
对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标 量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分 配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的 规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟 机中与内存相关的参数的设置。