概述

• GC(Garbage Collection),需要完成的3件事
  • 哪些内存需要回收？
  • 什么时候回收？
  • 如何回收？
• 为什么需要了解GC和内存分配？更好的监控和调节
  • 排查各种内存溢出，内存泄漏
  • 避免GC成为系统达到更高并发的瓶颈
• 关注哪部分的内存
  • PC，虚拟机栈，本地方法栈，随线程而生，随线程而灭
  • 栈帧随着方法的进入和退出，执行入栈出栈操作，每个栈帧分配多少内存基本上是类结构下来时就确定的（运行期由JIT做优化，可认为在编译器可知）
  • 方法结束或者线程结束时内存就回收了。不需要GC
  • GC作用在Java堆上。运行期创建对象，内存分配和回收是动态的。（后续说的内存特指JAVA堆）

对象已死吗

• 引用计数法

  • 概念：给对象添加一个引用计数器，有一个地方引用值就+1，当引用失效值就-1。当计数器值=0，就不可能再被使用。
  • 优点：实现简单，判定效率高
  • 缺点：无法解决相互引用问题。
  • 结论：不用

• 可达性分析算法

  • 概念： 主流实现的都是通过可达性分析来判断对象是否存活，基本思路就是通过一系列称为 "GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用。
  • 可作为GC Roots的对象：
    • 虚拟机栈（栈帧中的本地变量表）中应用的对象
    • 方法区中类静态属性引用的对象
    • 方法区中常量引用的对象
    • 本地方法栈中JNI（即一般说的Native方法）引用的对象

• 引用分类

  • 强引用（Strong Ref)，普遍存在，类似 T t = new T()。只要强引用还在，永远不回GC被引用的对象
  • 软引用（Soft Ref)，还有用但是并非必需的引用，在系统将要发生内存溢出异常之前会把这些对象列进回收范围中进行二次回收，若还是没有足够的内存，才会抛出内存溢出异常。
  • 弱引用（Weak Ref），非必需的对象，只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论内存是否够用都将回收这些对象。
  • 虚引用（Phantom Ref），一个对象是否有虚引用的存在完全不会对他的生存时间构成影响，也无法通过虚引用来取得一个对象实例。

• 两次标记过程：

  • 若对象在进行可达性分析后发现没有与GC Roots相连接的引用链，会被 第一次标记 并且进行一次筛选。筛选的条件是此对象是否有必要执行finalize()方法（如当对象没有重写finalize()方法或者finalize()方法已经被虚拟机调用过则认为没有必要执行）。
  • 如果有必要执行则将该对象放置在F-Queue队列中，并在稍后由一个由虚拟机自己建立的、低优先级的Finalizer线程去执行它；稍后GC将对F-Queue中的对象进行第二次标记，如果对象还是没有被引用，则会被回收。

• 回收方法区

  • 很多人认为方法区（HotSopt中的永久代）是没有垃圾收集的，java虚拟机规范中也没有要求需要对方法区实现垃圾收集
  • 永久代（方法区）的垃圾收集主要回收两部分内容：废弃常量和无用的类
    • 废弃常量：假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫 做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他 - 地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系 - 统清理出常量池
    • 无用的类同时满足下面3个条件的类（实例、类加载器被回收，java.lang.Class对象没有被引用）。（可以不是必然回收）

算法思想

• 标记-清除算法
  • 标记：首先标记所有需要回收的对象
  • 清除：在标记完成后统一回收所有被标记的对象
  • 缺点：
    • 效率问题：标记和清除两个过程的效率都不高（回收后空间碎片过多，再次回收（即可达性分析时）有时需要遍历整个内存区域）。
    • 空间问题：标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存,而不得不提前触发另一次垃圾收集动作。
• 复制算法
  • 思路：将可用内存按容量分为两个块，每次只用其中之一。当这一块内存用完之后，将还存活的对象复制到另一边去，然后清除所有已经使用过的部分
  • 优点：每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效
  • 缺点：代价是将内存缩小为了原来的一半，未免太高了一点。
  • 解决方法：
    • 新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor
    • 在HotSpot里，考虑到大部分对象存活时间很短将内存分为Eden和两块Survivor，默认比例为8:1:1。代价是存在部分内存空间浪费，适合在新生代使用
• 标记-整理算法
  • 标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
• 分代收集算法
  • 当前商用虚拟机都采用了这种算法，根据对象的存活周期将内存划分为几块，一般是把Java堆分为新生代和老生代，根据各个年代采用适当的收集算法。
  • 新生代一般采用复制算法(Copying)
  • 老生代一搬采用 标记-清理(Mark-Sweep) 或者标记-整理(Mark-Compact) 进行回收

HotSpot的算法实现

• 枚举根节点
  • 从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间
  • 由于要确保在一致性的快照中进行可达性分析，从而导致GC进行时必须要停顿所有Java执行线程。（Sun称为Stop The World）
  • 目前主流的Java虚拟机使用的都是准确式GC，当执行系统停顿下来后并不需要一个不漏的检查完所有执行上下文和全局的引用变量，虚拟机应当有办法直接得知哪些地方存着对象的引用
  • HotSpot使用一组称为OopMap的数据结构来记录哪些地方存着对象的引用
  • 在类加载过程中，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中会在特定的位置记录下栈和寄存器中哪些位置是引用
• 安全点
  • OopMap 内容变化的指令非常多，如果为每一条指令都生成对应的OopMap。导致大量的额外空间，GC的空间成本变高
  • Hotspot只在特定的位置记录这些信息，这些位置称为安全点
  • 即程序执行时并非在所有地方都能停顿下来开始GC，只有到达安全点时才能暂停。
  • 对于安全点基本上是以程序是否具有让程序长时间执行的特征（比如方法调用、循环跳转、异常跳转等）为标准进行选定的。
  • 另外还需要考虑如果在GC时让所有线程都跑到最近的安全点上，有两种方案：抢先式中断和主动式中断。
  • 抢断式中断：不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。 现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。
  • 主动式中断：当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方
• 安全区域
  • 为了处理不执行的程序的安全点问题，提出了安全区域来解决问题。
  • 安全区域是指在一段代码片段之中，引用关系不会发生变化，在这个区域内的任何地方进行GC都是安全的。
  • 虚拟机如个具体的进行内存回收是由虚拟机所采用的GC收集器决定的，而通常虚拟机中往往不止有一种GC收集器。
  • 线程执行到安全区域时，首先标识自己已经进入了安全区域，这样JVM在GC时就不管这些线程了。

垃圾收集器

• Serail收集器
  • Serail 收集器是单线程的，他在进行垃圾收集时必须暂停其他的所有线程，直到收集结束。
  • 随着收集器的发展，用户线程的停顿时间越来越短，但任然无法消除
  • Serial收集器是虚拟机运行在Client模式下默认的新生代收集器
  • 对于单个CPU坏境来说，Serial收集器**由于没有线程交互的开销，专心做垃圾收集，可以获得很高的单线程收集效率
• ParNew收集器
  • ParNew收集器是Serial收集器的多线程版本
  • ParNew收集器是运行在Server模式下虚拟机中首选的新生代收集器
  • 在垃圾收集器中并发与并行的概念:
    • 并行：多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态
    • 并发：用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU上
• Parallel Scavenge收集器
  • 新生代收集器，使用复制算法，并行的多线程收集器
  • 与其他收集器关注于尽可能缩短垃圾收集时用户线程停顿时间不同，它的目标是达到一个可控制的吞吐量
  • 吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%
  • 高吞吐量可以高效的利用CPU时间，尽快得完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务
  • GC停顿时间的缩短是以牺牲吞吐量和新生代空间来换取的
  • Parallel Scavenge收集器也经常被称为吞吐量优先收集器
  • Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量
    • 控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数
    • 直接设置吞吐量大小的-XX：GCTimeRatio参数

内存分配与回收策略

• 对象优先在新生代分配
• 大对象直接进入老年代
• 长期存活的对象将进入老年代
  • 动态对象年龄判断：如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半，大于或等于该年龄的对象直接进入老年代
  • 空间分配担保：发生Minor GC前，虚拟机会先检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果不成立，虚拟机会查看HandlePromotionFailure设置值是否允许担保失败，如果允许继续检查老年代最大可用的连续空间是否大于历次晋升到老年代的平均大小，如果大于会尝试进行一次Minor GC；如果小于或者不允许冒险，会进行一次Full GC
• 对象优先在Eden分配
  • 大多数情况下，对象优先在新生代的Eden区分配
  • 当Eden区没有足够的空间时，虚拟机将发起一次Minor GC
  • Minor GC与Full GC
    • Minor GC：新生代GC，非常频繁，回收速度快
    • Fulll GC：老年代GC，又称为Major GC，经常会伴随一次Minor GC，速度比较慢
• 对象直接进入老年代
  • 大对象是指需要大量连续的内存空间的Java对象,最典型的大对象就是那种很长的字符串以及数组
  • 虚拟机提供了一个参数：PretenureSizeThreshold，大于这个参数的对象将直接在老年代分配
• 长期存活的对象进入老年代
  • 虚拟机给每个对象定义了一个对象年龄计数器（Age），对象每经过一次Minor GC后仍然存活，且能被Survivor容纳的话，年龄就 +1 ，当年龄增加到一定程度（默认为15），就会被晋升到老年代中，这个阈值可以通过参数 MaxTenuringThreshold 来设置。
• 动态对象年龄的判定
  • 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代
• 空间分配担保
  • 为了更好的适应不同程序的内存状况，对象年龄不是必须到达阈值才会进入老年代
  • 只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC

核心收集器

CMS收集器

• CMS收集器是一种以获取最短的回收停顿时间为目标的收集器
• 四个步骤详解：
  • 初始标记：标记一下GC Roots能直接关联到的对象，速度很快
  • 并发标记：进行GC Roots Tracing
  • 重新标记：是为了修正那些在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，在这一阶段的停顿时间会比初始标记阶段稍长一点。
  • 并发清除：（CMS concurrent sweep）

G1收集器

• G1收集器是一款面向服务端应用的垃圾收集器
• 具备优点：
  • G1能充分利用多CPU、 多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行
  • 分代收集
  • 空间整合:从整体上来看是基于“标记-整理”算法实现的，在局部上是基于复制算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。 这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC
  • 可预测的停顿:这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了
• 步骤：
  • 初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短
  • 并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
  • 最终标记（Final Marking）：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行
  • 筛选回收（Live Data Counting and Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划

GC总结

原文：https://www.cnblogs.com/cloud-blog/p/12971240.html