垃圾收集器与内存分配策略
when ? what ? why ? how ?
为什么要进行垃圾回收？
当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们需要对内存动态分配和内存回收技术实施必要的监控和调节。
垃圾回收的区域是哪块？
JVM 内存结构分成程序计数器、虚拟机栈、本地方法栈、堆、方法区。程序计数器、虚拟机栈和本地方法栈都是线程私有的。堆和方法区是线程共享的。
当线程结束时，那些内存（程序计数器、本地方法栈、虚拟机栈）自然就跟随着回收了。 只有在程序处于运行期间时才能知道会创建那些对象，所以堆和方法区的分配和回收是动态的。
垃圾收集器的区域指的是堆和方法区。
怎样判断对象是否已经死了？
1.引用计数算法
给一个对象添加引用计数器，有一个地方引用它，计数器加 1 ，引用失效时，计数器减 1 。
引用计数算法的判定效率很高，但是 Java 虚拟机里面没有选用引用计数算法来管理内存，主要因为它很难解决对象之间相互引用的问题。
2.可达性分析算法
通过一系列的称为 “GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时（从 GC Roots 到这个对象不可达），证明此对象是不可用的。将会判定次对象是可回收对象。
可做为GC Roots的对象
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
JDK1.2 之前只有被引用或没有被引用两种状态。JDK1.2 之后将引用分为4类。
引用：
- 强引用——垃圾收集器永远不会回收掉被引用的对象
- 软引用——在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收
- 弱引用——只能生存到下一次垃圾收集发生之间
- 虚引用——能在这个对象被收集器回收时收到一个系统通知
要真正宣告一个对象死亡，至少要经历两次标记过程，如果对象在进行可达性分析后发现没有与GC Roots 相连接的引用链，那么它将会被第一次标记并且进行一次筛选，筛选条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 finalize（）方法或 finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。 任何一个对象的finalize（）方法都只会被系统自动调用一次。
对象可以在调用 finalize（）中拯救自己———只要重新与引用链上的任何一个对象建立关系即可。
方法区回收
方法区（HotSpot虚拟机中的永久代）的垃圾回收效率比较低。新生代中常规应用进行一次垃圾收集一般可回收 70% ~ 95% 的空间。
永久代的垃圾回收集主要回收两部分内容：废弃常量和无用的类。
废弃常量与回收堆中的对象非常类似。
无用的类回收需要满足3个条件虚拟机才可以进行回收
- 该类所有实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
- 加载该类的 ClassLoader 已经被回收。
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
有哪些垃圾收集算法？
标记-清理算法
标记-清理算法（Mark-Sweep）：分为“标记”和“清除”两个阶段，首先标记出需要回收的对象（可达性分析算法），然后是清理掉需要回收的对象。
不足处：一个是效率——标记和清理这两个过程效率都不高，第二个是空间问题如上图有很多不连续的内存碎片，如果程序运行中需要分配较大对象时，无法找到足够的连续内存而不提前触发另一次垃圾收集动作。因为这个算法的这两个不足处才会有后面几个算法进行优化改进。
复制算法
为了解决效率问题， “复制”算法出现了，它将容量划分为大小相等的两块，每次只使用其中一块。当这一块内存用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样每次只对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，简单、高效。 缺点：内存需要牺牲一半。
有研究因为新生代中的对象 98% 都是“朝生夕死”，所以不需要按照 1：1比例来划分内存空间，而是将内存划分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和一块 Survivor。回收时，将Eden 和 Survivor 上存活的对象放到另一个 Survivor 空间上。 HotSpot虚拟机默认 Eden 和 Survivor 空间大小 8：1，也就是新生代中可用内存空间为整个新生代容量的 90%，只有 10% 会被“浪费”。
如果 Eden 和 Survivor 存活的对象比另一个 Survivor空间要大呢？
会依赖其它内存（老年代）进行分配担保（Handle Promotion）。会将这些对象直接通过分配担保机制进入老年代。
标记-整理算法
标记-整理算法（Mark-Compact）和标记-清理算法（Mark-Sweep）很像，但是标记-整理算法标记可回收的对象后不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。
分代收集算法
根据对象存活周期的不同将内存划分为几块，一般吧 Java 堆划分为新生代和老年代。
在新生代中，每次垃圾回收时都发现有大批对象死去，只有少量存活，选用复制算法。
在老年代中，因为对象存活率高、没有额外空间对它进行进行分配担保，选用标记-清理算法或标记-删除算法来进行回收。
有哪些垃圾收集器？
垃圾收集器是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。
如上图如果两个收集器之间存在连线则说明它们可以搭配使用。每个收集器都有自己的特点，我们需要根据具体的应用场景选择需要的收集器。
Serial 收集器
serial 收集器是最基本、发展历史最悠久的收集器。这个收集器是单线程的收集器，当它进行垃圾收集时，必须暂停其它所有的工作线程，直到它收集结果 “Stop The World”。
在用户不可见的情况下把用户正常工作的线程全部停掉，对很多应用来说都是难以接受的。从 Serial 收集器到 Parallel 收集器再到 CMS 到 G1 收集器，用户线程停顿时间在不断缩短，但是仍然没有完全消除。
Serial 收集器优点：由于没有线程交互的开销，专心做垃圾收集可以获得最高的单线程收集效率。简单高效。 适用于 Client 模式下的虚拟机（桌面应用场景中，分配给虚拟机管理的内存一般来说不是很大，收集几十兆甚至一两百兆的新生代，停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不频繁发生这个停顿就可以接受）。
ParNew 收集器
ParNew 收集器是 Serial 收集器的多线程版本。
ParNew 收集器除了是并行的多线程线程收集器（多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态）之外，其他与 Serial 收集器相比并没有太多创新之处。 适用于 Server 模式下的虚拟机中首选新生代收集器。
Parallel Scavenge 收集器
Parallel Scavenge 收集器也是一个在新生代，使用复制算法，并行的多线程收集器。但是它的关注的是一个可控制的吞吐量（Throughput）。
吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率的利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Serial Old 收集器
Serial Old 是 Serial 收集器的老年代版本，也是个单线程收集器，使用“标记-整理”算法。适用于Client模式下的虚拟机使用。
用途：
- 与Parallel Scavenge 收集器搭配使用
- 作为 CMS 收集器的后备预言，在并发收集发生 Concurrent Mode Failure 时使用。
Parallel Old 收集器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和“标记-整理”算法。适用于注重吞吐量以及 CPU 资源敏感的场合。
CMS 收集器
CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网网站或 B/S系统的服务端上（这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验）。
CMS收集器是基于“标记——清楚”算法实现，整个过程分为 4 个步骤：
- 初始化标记（CMS initial mark）
- 并发标记（CMS concurrent mark）
- 重新标记 （CMS remark）
- 并发清除 （CMS concurrent sweep）
初始标记和重新标记需要“Stop The World”。
初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行 GC Roots Tracing 的过程。而重新标记则是为了修改并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记长，但远比并发标记的时间短。
并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以从总体上来说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。
CMS 收集器优点：并发收集、低停顿。
并发：用户线程与垃圾线程收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序继续运行，而垃圾收集程序运行于另一个 CPU 上。
缺点：
- CMS 收集器会占用一部分 CPU 资源而导致应用程序变慢，总吞吐量会降低。
- 无法处理浮动垃圾——由于 CMS 并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集处理掉他们，只能留待下一次 GC 时再清理掉。由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此 CMS 收集器不能像其他收集器那样等到老年代几乎完全填满后再进行收集，需要预留一部分空间提供并发收集的程序运行使用。
- CMS 采用的是“标记-清除”算法，会产生大量碎片。如果碎片过多，当有大对象要分配时，无法找到足够大的连续空间来分配，会提前触发一次 Full GC。
G1 收集器
G1（Garbage-First）是一款面向服务器端应用的垃圾收集器。
G1特点：
- 并行与并发
- 分代收集： G1 可以独立管理整个 GC 堆
- 空间整合：总体上看用“标记-整理”算法，局部（两个Region）用“复制”算法
- 可预测的停顿
G1 将整个 Java 堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的，它们都是一部分Region（不需要连续）的集合。
G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小，后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。
在 G1 收集器中，虚拟器都使用 Remembered Set 来避免全栈扫描。
G1 收集器的运作大致可划分为以下几个步骤：
- 初始化标记 （Intial Marking）
- 并发标记 （Concurrent Marking）
- 最终标记 （Final Marking）
- 筛选标记 （Live Data Counting and Evacuation）
初始标记阶段仅仅只是标记一下GC Roots 能直接关联到的对象，并修改TAMS(Next Top at Mark Start) 的值，让下一阶段用户程序并发运行时，能在正确可用的 Region 中创建新对象，这阶段需要停顿线程，但耗时很短。并发标记是从 GC Root 开始对堆中对象进行可达性分析，找出存活的对象，这个阶段耗时较长，但可与用户程序并发执行。最终标记则是为了修改并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，虚拟机将这段时间对象变化记录在线程 Remenbered Set Logs 里面，最终标记阶段需要把 Remenbered Set Logs 的数据合并到 Remenbered Set 中，这阶段需要停顿，但可并行执行。最后筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。
Minor GC 和 Full GC 有什么区别？
新生代 GC （Minor GC） ：发生在新生代的垃圾收集动作。Minor GC 非常频繁，回收速度比较快。
老年代 GC （Major GC/Full GC）：发生在老年代的 GC， Major GC 一般比 Minor GC 慢 10 倍以上。
内存分配规则
对象优先在 Eden 分配
大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起 Minor GC。
大对象直接进入老年代
长期存活的对象将进入老年代
虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在 Eden 出生在 Survivor 区中每熬过一次 Minor GC，年龄加 1 岁，当年龄到一定程度（默认15岁），就会晋升到老年代中。
动态对象年龄判定
在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代。
空间分配担保
在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么 Minor GC 可以确保是安全的。如果不成立，则虚拟机会查看 HandlePromotionFailure 设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可能连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC，尽管这个 Minor GC 是有风险的；如果小于，或 HandlePromotionFailure 设置不允许冒险，那这次也要改为进行一次 Full GC。
总结
参考
深入理解Java虚拟机
深入理解Java虚拟机这本书很好，上面总结基本都是对书上的知识点进行摘取，不过我发现自己总结了一遍后对于 GC 理解更加深刻了，感觉很有用！
有什么问题欢迎指出，十分感谢！
