JVM垃圾回收机制

(一) 垃圾回收概述

垃圾(Garbage): 指在运行程序中没有任何指针指向的对象, 这个对象就是需要被回收的垃圾

Java自动内存管理, 无需开发人员手动参与内存的分配与回收, 从繁重的内存管理中释放出来. 降低了内存泄漏和内存溢出的风险, 并提供了对内存的监控和调节的技术以及工具

Java垃圾回收器可以对堆以及方法区进行垃圾回收:

• 频繁收集年轻代
• 较少收集老年代
• 基本不懂方法区

(二) 垃圾回收算法

2.1 垃圾标记阶段算法

在堆里存放着几乎所有的Java对象实例, 在GC执行来及回收之前, 首先需要区分内存中哪些是存活对象, 哪些是已经死亡的对象. 只有被标记为已经死亡的对象, GC才会在执行垃圾回收时, 释放掉其所占用的内存空间, 因此这个过程可以称为: 垃圾标记阶段

当一个对象已经不再被任何的存活对象继续引用时, 就可以标记为死亡对象

JVM中判断对象存活一般有两种方式: 引用计数算法 和 可达性分析算法

1. 引用计数算法: 对每一个对象保存一个整型的引用计数器属性, 用于记录对象被引用的情况

• 对于一个对象A, 只要任何一个对象引用了A, 则A的引用计数器就加1; 当引用失效时, 引用计数器就减1. 只要对象A的引用计数器的值为0, 即表示对象A不可能再被使用, 可进行回收
• 实现简单, 垃圾对象便于识别; 判断效率高, 回收没有延迟性
• 抛开引用计数需要的存储和计算开销的问题, 存在一个致命缺陷: 无法处理循环引用的情况, 导致Java内存泄漏的问题(Java垃圾回收器中没有使用这类算法)

    static class Node {
        Node nextNode;
    }
    
    public static void main(String[] args) {
        Node node1 = new Node();
        Node node2 = new Node();
        
        // node1对象 和 node2对象 循环引用
        node1.nextNode = node2;
        node2.nextNode = node1;

        node1 = null;
        node2 = null;
    }

2. 可达性分析算法, 又称之为: 根搜索算法、追踪性垃圾收集:

• 以根对象集合(GC Roots)为起始点, 按照从上至下的方式搜索跟对象集合所连接的目标对象是否可达
• 使用可达性性分析算法后, 内存中的存活对象都会被根对象集合直接或间接连接着, 搜索所走过的路径称为引用链
• 如果目标对象没有任何引用链相连, 则是不可达, 就意味着该对象已经死亡, 可以标记为垃圾对象
• 在可达性分析算法中, 只有能够被根对象集合直接或者间接连接的对象才是存活对象
• 使用可达性分析算法必须在一个能保证一致性的内存快照中进行, 这也是导致STW(Stop The World)的一个重要问题
  

根对象集合(GC Roots) 包括以下几类元素:

• 虚拟机栈中引用的对象
• 本地方法(JNI)栈中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 所有同步锁synchronized持有的对象
• Java虚拟机内部引用: 异常对象、系统加载类

对象的finalization机制: Java语言提供了对象终止机制来允许开发人员提供对象销毁之前的自定义处理逻辑

• 当垃圾回收器对 没有任何引用指向一个对象 回收前, 先回调用这个对象的finalize() 方法
• finalize() 方法允许在子类中被重写, 用于在对象被回收时进行资源释放
• finalize() 方法应该交由垃圾回收机制调用(F-Queue队列: 由虚拟机自动创建的、低优先级的Finalize线程执行), 无需手动调用, 有且只可执行一次
  • finalize() 方法执行时可能会导致对象复活
  • finalize() 方法执行时间时没有保障的, 它完全由GC线程决定的. 如果不发生GC, 此方法永远都不会执行
• 由于finalizeI() 方法的存在, 虚拟机中的对象一般处于三种状态
  • 可触及状态: 从根节点(GC Root)开始, 可以通过引用链达到这个对象
  • 可复活状态: 对象的所有引用都被释放, 但是对象由可能在finalize() 中复活
  • 不可处及状态: finalize() 方法执行完成后, 都没有复活的对象
• 由于finalizeI() 对象可复活机制, 导致判断一个对象是否可以被回收, 至少要经历两次标记过程

2.2 垃圾清除阶段算法

当成功区分出内存中存活对象和死亡对象后, GC接下来的任务就是执行垃圾回收, 释放掉无用对象所占用的内存空间, 以便由足够的可用内存空间为新对象分配内存

JVM中常见的三种垃圾收集算法: 标记-清除算法(Mark-Sweep)、复制算法(Copying)、标记-压缩算法(Mark-Compact )

1. 标记-清除算法(Mark-Sweep): 是一种非常基础和常见的垃圾收集算法, 当堆中的有效内存空间被耗尽的时候, 就会停止整个程序(STW), 然后先后进行两个阶段的工作: 标记–>清除

• 标记: Collector垃圾收集器从引用根节点开始遍历, 标记所有被引用的对象. (一般在对象的Header中记录为可达对象)
• 清除: Collector垃圾收集器对堆内存从头到尾进行线性的遍历, 如果发现某个对象在其Header中没有标记为可达对象, 则将其回收

标记-清除(Mark-Sweep)算法的缺点:

• 效率不算高, 需要遍历两次堆空间对象
• 在进行GC的时候, 需要停止整个应用程序, 导致用户体验差
• 这种方式清理出来的空闲内存是不连续的, 产生内存碎片. 需要维护一个空闲列表

注: 清除垃圾对象不是意义上的真正清空, 而是把需要清除的对象地址保存在空闲的地址列表. 如果有新对象需加载时, 如果原垃圾的位置空间能够存储, 直接覆盖存储

2. 复制(Copying)算法: 将已分配的内存空间分为两块, 每次只使用其中的一块, 在垃圾回收时将正在使用内存块(From)中的存活对象复制到未被使用的内存块(To)中, 之后清除正在使用的内存块中的所有对象, 交换两个内存角色, 最后完成垃圾回收 (类似于年轻代中的Survivor0 和 Survivor1)

复制(Copying)算法的优缺点:

• 优点: 没有标记和清除过程, 实现简单, 运行高效且复制后能保证空间的连续性, 不会出现"碎片"问题
• 缺点: 需要两倍的内存空间, 且需要改变对象的引用地址
• 复制算法特别适用于垃圾对象很多, 存活对象很少的场景. 不适用老年代

3. 标记压缩(整理)算法(Mark-Compact):

• 标记: Collector垃圾收集器从引用根节点开始遍历, 标记所有被引用的对象. (一般在对象的Header中记录为可达对象)
• 清除: Collector垃圾收集器对堆内存从头到尾进行线性的遍历, 如果发现某个对象在其Header中没有标记为可达对象, 则将其回收
• 整理阶段: 将所有的存活对象压缩到内存的一端, 按顺序排放
  
• 优点: 消除了标记-清除算法中, 内存区域分散的缺点. 给新对象分配内存时, JVM只需要只有一个内存的起始地址即可
• 缺点: 效率要低于标记-清除算法, 也需要改变对象的引用地址

4. 分代收集算法(Generational Collection)

	Mark-Sweep	Mark-Compact	Copying
速度	中等	最慢	最快
空间消耗	少(产生内存碎片)	少	需要存活对象的2倍内存空间
移动对象	否	是	是

这三种算法都各自存在自己独特的优势和缺点, 且并没有一种算法可以完全替代其他算法. 因此分代收集算法应运而生

分代收集算法: 基于不同的对象的生命周期是不一样的事实下, 对不同生命周期的对象进行划分, 一般划分为新生代和老年代以及方法区, 根据划分的区域使用不同的垃圾回收算法, 以便提高回收效率

目前几乎所有的GC都是采用分代收集算法来实现垃圾回收的, 在HotSpot中, 基于分代的概念, GC所使用的内存回收算法必须结合年轻代和老年代各自的特点

• 年轻代: 区域相对于老年代较小, 对象生命周期短, 存活率低, 回收频繁
  • 采用复制算法: 复制算法的效率只和当前存活的对象大小有关, 因此很适用于年轻代的回收, 而复制算法内存利用率不高的问题, 通过两个survivor区的设计来缓解
• 老年代: 区域比较大, 对象生命周期长, 存活率高, 回收不及年轻代频繁
  • 采用标记-清除或标记-整理算法, 甚至是两者的结合
  • 标记阶段的开销与存活对象的数量成正比
  • 清除阶段的开销与所管辖区域的的大小成正比
  • 整理阶段的开销与存活对象的数量成正比

5. 增量收集算法和分区算法

上述现有的算法, 在垃圾回收过程中, 应用软件处于一种Stop The World的状态, 在STW状态下, 应用程序所有的线程都会挂起, 暂停一切正常的工作, 等待垃圾回收的完成. 如果等待时间较长, 会严重影响用户体验或者系统的稳定性

增量收集算法:

• 垃圾收集线程和应用程序线程交替执行, 垃圾收集线程只收集一小片区域的内存空间, 接着切换到应用程序线程, 依次反复, 直到垃圾收集完成
• 增量收集算法的基础仍是传统的标记-清除和复制算法, 只是对线程间冲突的妥善处理, 允许垃圾收集线程以分阶段的方式完成标记、清理或者复制的功能
• 缺点: 由于线程切换和上下文转换的消耗, 会使得垃圾回收的总体成本上升, 造成系统吞吐量的下降

分区算法:

• 一般来说, 在相同条件下, 对空间越大, 一次GC所需要的时间就越长, STW停顿时间也越长. 为了更好的控制GC产生的停顿时间, 将一块大的内存区域分隔成多个小块, 每次合理地回收若干个小区间, 而从降低GC所产生的停顿
• 分区算法将整个堆空间划分成连续的不同小区间, 每个区间都独立使用, 独立回收. 多个小区间并行回收
  
  
  
  

(三) 垃圾回收概念

1.System.gc() 的理解

• 在默认情况下, 通过System.gc() 或者 Runtime.getRuntime().gc() 的调用, 会显示的触发Full GC, 同时对老年代和新生代进行回收, 尝试释放被丢弃对象占用的内存
• System.gc() 调用附带一个免责申明, 无法保证成功的调用垃圾收集器

---

2.内存溢出(OOM):

• javadoc中对OutOfMemoryError的解释是: JVM没有空闲内存创建对象, 并且垃圾收集器也无法提供更多内存
• Java虚拟机的堆内存设置太小, 以及 代码中创建了大量对象, 并且长时间不能被垃圾收集器收集(如: JDK1.6下的永久代)
• 在抛出OutOfMemoryError之前, 通常情况下会触发垃圾收集器收集垃圾(Full GC)

---

3.内存泄漏(Memory Leak):

• 严格来说: 只有对象不会再被程序使用到了, 但是GC又不能回收他们的情况, 称之为内存泄漏
• 宽泛来说: 无法分析对象的生命周期的范围, 导致大量对象的生命周期变得很长甚至导致OOM (如: 将方法局部变量定义成类的成员变量)
• 内存泄漏并不会立刻引起程序崩溃, 但是一旦发生了内存泄漏, 程序中的可用内存就会被逐步蚕食, 直至耗尽所有内存, 最终出现OutOfMemory异常, 导致程序崩溃

内存泄漏的例子:

• 单例模式下创建的对象的生命周期和应用程序是一样长的, 因此, 在单例程序中, 如果持有对外部对象的引用的话, 那么这个外部对象是不能被回收的, 则会导致内存泄漏的产生
• 一些提供close的资源未关闭导致内存泄漏: 数据库连接对象、网络连接(socker) 以及IO连接

---

4.STW(Stop The Word):

• STW: 指的是GC事件发生过程中, 会产生应用程序的停顿. 停顿产生时整个应用程序线程都会被暂停, 没有任何的响应
• 可达性分析算法中枚举根节点(GC Roots)会导致所有Java执行线程停顿
  • 分析工作必须在一个能确保一致性的快照中执行
  • 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
  • 如果出现分析过程中对象引用关系还在不断变化, 则分析结果的准确性无法保证
• STW事件和采用哪款GC无关, 所有的GC都会触发STW, 只能说高效的垃圾回收器都尽可能的缩短暂停时间
• STW时JVM在后台自动发起和自动完成的, 在用户不可见的情况下, 把用户正常的工作线程全部暂停

---

5.垃圾回收的并行与并发:

并发: 在操作系统中, 是指一个时间段中有几个程序都处于已启动运行到运行完毕之间, 且这几个程序都是在同一个处理器上运行. 并发并不是真正意义上的同时进行, 是CPU在一个时间段来回在不同的程序中高速切换运行

并行: 当系统存在一个以上CPU时, 不同的CPU执行不同的进程(程序), 两个进程(程序)互不抢占CPU资源, 且同时进行 (决定并行的因素是CPU的核心数量)

• 并发: 指的是多个进程, 在同一时间段同时发生了. 多个进程之间相互抢夺资源
• 并行: 指的是多个进程, 在同一时间点同时发生了. 多个进程之间互不干扰

垃圾回收的串行: 指用户线程与垃圾收集线程同时交替执行, 且垃圾收集线程是单线程, 在执行垃圾收集线程时需要暂停用户线程(STW)

垃圾回收的并行: 并行是多个垃圾回收线程并行的工作, 在执行垃圾收集线程时需要暂停用户线程(STW)

垃圾回收的并发: 用户线程和垃圾回收线程在同一时间点同时执行, 运行在不同的CPU(CMS、G1)

---

5.垃圾回收的安全点(Sage Point)和安全区域(Safe Region):

安全点(Sage Point): 程序执行时并非在所有地方都能停顿下来开始GC, 只有在特定的位置才能停顿下来开始GC, 这些位置称之为安全点

• Safe Point的选择和数量都很重要, 如果数量太少可能导致GC等待的时间太长, 如果太多可能导致运行时的性能问题. 因此会根据 是否具有让程序长时间执行的指令的特征为标准选择Sage Point, 如: 方法调用、循环跳转和异常跳转等
• 采用主动式中断让所有线程执行到安全点停顿下来: 设置一个中断标志, 各个线程运行到Safe Point的时候主动读取这个标志, 如果中断标志存在, 则将自己的线程中断挂起

安全点机制保证了程序线程在执行时挂起, 但如果线程处于Sleep或Blocked状态, 由于无法确定休眠时间, 就无法快速挂起线程. 在这种情况下, 就需要安全区域(Safe Region)来解决

安全区域(Safe Region): 指在一段代码片段中, 对象的引用关系不会发生变化, 在这个区域中的任何位置开始GC都是安全的, 这个区域就被称之为安全区域

• 当线程运行到Safe Region的代码中, 首先该线程标识进入Safe Region, 如果这段时间发生GC, JVM会忽略标识为Safe Region状态的线程, 不会挂起该线程, 让其继续执行
• 当线程即将离开Safe Region时, 会检查JVM是否已经完成GC, 如果完成了, 则线程离开此区域继续运行. 否则该线程挂起等待直到GC完成后恢复

---

6. 对象引用: 存在4中对象引用(强、弱、软、虚 引用), 这4中引用强度依次逐渐减弱. 除了强引用外, 在java.lang.ref.Reference抽象类中可以找到其他三种类型对应的类

• 强引用(StrongReference): 最传统的"引用"定义, 如 Object obj = new Object(). 无论任何情况下, 只要强引用关系还存在, GC都不会回收这类对象

• 软引用(SoftReference): 在系统将要发生内存溢出之前, 将软引用的对象直接回收, 如果还是内存不足, 则抛出OOM异常(缓存对象, Mybatis 内部类对象. 内存不足即回收)

  /**
   *	-Xms10m -Xmx10m: 设置堆内存为10M
   */
  public class SoftReferenceTest {
  
      public static class User {
          private int id;
          private String name;
  
          public User(int id, String name) {
              this.id = id;
              this.name = name;
          }
  
          @Override
          public String toString() {
              return "User [id = " + this.id + ", name = " + this.name + "]";
          }
      }
  
      public static void main(String[] args) {
          // 创建一个软引用对象
          SoftReference<User> userSoftReference = new SoftReference<>(new User(1, "张三"));
          System.out.println("软引用对象实例: " + userSoftReference.get());
          System.gc();
          System.out.println("---------- GC 执行完成 ----------");
          System.out.println("内存足够下发生GC, 软引用对象实例: " + userSoftReference.get());
  
          try {
              byte[] buffer = new byte[1024 * 1024 * 7]; // 设置一个7M的数组(内存不足, 发生OOM异常)
          } catch (Throwable e) {
              System.out.println(e.toString());
          } finally {
              System.out.println("内存不足, 软引用对象实例: " + userSoftReference.get());
          }
      }
  }
  

  

• 弱引用(WeakReference): 弱引用的对象, 一定会被下一次GC回收掉的对象. 无论内存空间是否足够, 都会被回收(WeakhashMap, 发现即回收)

  public static void main(String[] args) {
         // 创建一个弱引用对象
         WeakReference<User> userWeakReference = new WeakReference<>(new User(1, "张三"));
         System.out.println("弱引用对象实例: " + userWeakReference.get());
         System.gc();
         System.out.println("---------- GC 执行完成 ----------");
         System.out.println("内存足够下发生GC, 弱引用对象实例: " + userWeakReference.get());
  }
  

  

• 虚引用(PhantomReference): 一个对象是否有虚引用的存在,完全不会对其生命周期构成影响, 也无法通过虚引用获取一个对象的实例. 为一个对象设置虚引用的目的是: 跟踪垃圾回收的过程: 这个对象被垃圾回收时收到一个系统通知. 必须和引用队列一起使用(对象回收跟踪)

  public static void main(String[] args) {
         // 创建一个队列
         ReferenceQueue<User> queue = new ReferenceQueue<>();
         // 创建一个虚引用对象
         PhantomReference<User> userPhantomReference = new PhantomReference<User>(new User(1, "张三"), queue);
         System.out.println(userPhantomReference.get()); // 输出Null
  }
  

(四) 垃圾回收器

4.1 GC分类和性能指标

垃圾回收器没有在规范中进行过多的规定, 可以有不同的厂商、不同版本的JVM来实现. 由于JDK的版本处于高速迭代过程中, 因此Java发展至今已经衍生了众多的GC版本, 从不同的角度分析垃圾收集器, 可以将GC分为不同的类型

• 按垃圾回收线程数分类: 可以分为串行垃圾回收器和并行垃圾回收器
  • 串行回收: 在同一时间段内只允许一个CPU用于执行垃圾回收操作(用户线程暂停), 适用于单核CPU
  • 并行回收: 可以实现多个CPU同时执行垃圾回收(用户线程暂停STW)
    
• 按照工作模式分类: 可以分为并发式垃圾回收器和独占式垃圾回收器
  • 并发式垃圾回收器: 垃圾回收线程和用户线程交替工作
  • 独占式垃圾回收器: 垃圾回收线程一旦运行, 停止所有的用户线程, 直至GC完成
    
• 按照碎片处理的方式分类: 压缩式垃圾回收器 和 非压缩式垃圾回收器
• 按工作的内存分类: 年轻代垃圾回收器 和 老年代垃圾回收器

---

垃圾回收器的性能指标

• 吞吐量:运行用户代码时间占总运行时间的比例

  • 吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾回收时间)
  • 吞吐量优先的情况下, 应用程序能够容忍较高的暂停时间, 且 在单位时间内, STW的时间最短: 0.2 + 0.2 = 0.4
    

• 暂停时间: 执行垃圾收集时, 程序的工作线程被暂停的时间

  • 暂停时间优先的情况下, 尽可能让单次STW的时间最短: 0.1 + 0.1 + 0.1 + 0.1 + 0.1 = 0.5
    

• 内存占用: Java堆区所占用的内存大小 (随着硬件的发展, 内存占用大些越来越能容忍, 因此内存占用衡量会较少的关注)

高吞吐量 和 低暂停时间 是一对相互竞争的目标, 因此在设计使用GC算法时, 必须要明确侧重于一方, 或者是 找到双方的一个折中点: 在最大吞吐量优先的情况下, 降低停顿时间