本篇文章承接上文《深入理解对象在JVM上的创建和内存分配》,如果想了解更多JVM运行时数据区相关或者内存管理相关，请查看JVM虚拟机（一）-内存管理与运行时数据区剖析，如果想了解对象的创建和内存分配，请查看JVM虚拟机（二）-深入理解对象在JVM上的创建和内存分配。
建议阅读本篇之前，先阅读前两篇文章。
在JVM虚拟机（一）-内存管理与运行时数据区剖析中，我们聊了下JVM中的虚拟机栈（程序计数器，局部变量表，操作数栈等），堆等运行时数据区结构，在JVM虚拟机（二）-深入理解对象在JVM上的创建和内存分配中我们分析了对象的创建过程和对象的内存分配流程，接下来我们来聊聊对象的回收（死）。我们先从垃圾回收的算法开始
垃圾回收算法
垃圾回收算法的实现设计到大量的程序细节，并且每一个平台的虚拟机操作内存的方式都有不同，所以不需要去了解算法的实现，我们重点聊聊分代收集理论和3种算法的思想。
分代收集理论
当前商业虚拟机的垃圾收集器，大多遵循“分代收集”的理论来进行设计，这个理论大体上是这么描述的：
1、 绝大部分的对象都是朝生夕死
2、 熬过多次垃圾回收的对象就越难回收。
根据以上两个理论，朝生夕死的对象放一个区域，难回收的对象放另外一个区域，这个就构成了新生代和老年代。
GC种类
市面上发生垃圾回收的叫法很多，我大体整理了一下：
1、 新生代回收（Minor GC/Young GC）:指只是进行新生代的回收。
2、 老年代回收（Major GC/Old GC）:指只是进行老年代的回收。目前只有CMS垃圾回收器会有这个单独的收集老年代的行为。（Major GC定义是比较混乱，有说指是老年代，有的说是做整个堆的收集，这个需要你根据别人的场景来定，没有固定的说法）
3、 整堆收集（Full GC）:收集整个Java堆和方法区(注意包含方法区)
回收算法
复制算法（Copying）
将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。需要注意的是：
内存移动是必须实打实的移动（复制），不能使用指针玩。
复制回收算法适合于新生代，因为大部分对象朝生夕死，那么复制过去的对象比较少，效率自然就高，另外一半的一次性清理是很快的。
特点：
1 实现简单、 运行高效
2.内存复制、 没有内存碎片
3.利用率只有一半
在JVM刚开始诞生的时候，JVM中只有Serial和Serial Old两个垃圾回收器，随着技术的发展和回收器的演进，开始出现ParNew和Parllel Old多线程并行的垃圾回收器。再然后出现了第一个并发垃圾回收器CMS,直到现在的JVM虚拟有了G1可以跨新生代和老年代的更高级垃圾回收器。
Appel式回收
一种更加优化的复制回收分代策略：具体做法是分配一块较大的Eden区和两块较小的Survivor空间（你可以叫做From或者To，也可以叫做Survivor1和Survivor2）
专门研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor[1]。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）
标记-清除算法（Mark-Sweep）
算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。回收效率不稳定，如果大部分对象是朝生夕死，那么回收效率降低，因为需要大量标记对象和回收对象，对比复制回收效率很低。它的主要不足空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。回收的时候如果需要回收的对象越多，需要做的标记和清除的工作越多，所以标记清除算法适用于老年代。复制回收算法适用于新生代。
特点：
1.执行效率不稳定
2.内存碎片导致提前GC
标记-整理算法（Mark-Compact）
首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记整理算法虽然没有内存碎片，但是效率偏低。
我们看到标记整理与标记清除算法的区别主要在于对象的移动。对象移动不单单会加重系统负担，同时需要全程暂停用户线程才能进行，同时所有引用对象的地方都需要更新。
特点：
1.对象移动
2.引用更新
3.用户线程暂停
4.没有内存碎片
所以看到，老年代采用的标记整理算法与标记清除算法，各有优点，各有缺点。
各算法使用场景
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。
JVM中常见的垃圾收集器
JVM中的垃圾回收器主要采用上面的三种算法进行垃圾回收，一个垃圾回收器采用一种算法，再结合实际中，单线程与多线程和多线程并发的应用场景，随着历史的发展，衍生出很多种垃圾回收器。可以大致的分为以下三类：
单线程垃圾收集器，多线程垃圾收集器，多线程并发垃圾收集器。下图是三种收集器的分工区域：
上图中，一个模块表示一个垃圾回收器，每个垃圾回收器的忒单如下图所示：
简单的垃圾回收器工作示意
1.单线程收集
2.多线程收集
3.CMS垃圾回收器工作示意图
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
1.初始标记-短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
2.并发标记-和用户的应用程序同时进行，进行GC Roots追踪的过程，标记从GCRoots开始关联的所有对象开始遍历整个可达分析路径的对象。这个时间比较长，所以采用并发处理（垃圾回收器线程和用户线程同时工作）
3.重新标记-短暂，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
4.并发清除
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS特点：
CPU敏感：
CMS对处理器资源敏感，毕竟采用了并发的收集、当处理核心数不足4个时，CMS对用户的影响较大。
浮动垃圾：
由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。
总体来说，CMS是JVM推出了第一款并发垃圾收集器，所以还是非常有代表性。
但是最大的问题是CMS采用了标记清除算法，所以会有内存碎片，当碎片较多时，给大对象的分配带来很大的麻烦。
4.G1收集器工作流程
在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
Stop The World现象
应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互
这个就是STW，Stop The World。任何的GC收集器都会进行业务线程的暂停，导致Stop The World。所以我们GC调优的目标就是尽可能的减少STW的时间和次数