JVM-垃圾回收机制

JVM-垃圾回收

1.垃圾回收概述

1.概述

1. Java和C++语言的区别，就在于垃圾收集技术和内存动态分配上，C++语言没有垃圾收集技术，需要程序员手动收集。

2. 垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。

3. 关于垃圾收集有三个经典问题：

   哪些内存需要回收？

   什么时候回收？

   如何回收？

4. 垃圾收集机制是Java的招牌能力，极大地提高了开发效率。

2.什么是垃圾？

垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。

如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用。甚至可能导致内存溢出。

为什么需要GC？

清理内存

3.Java垃圾回收机制

自动内存管理

官网介绍：

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html

优点：

• 降低内存泄漏和内存溢出的风险。

  内存泄漏：指你向系统申请分配内存进行使用（new/malloc），然后系统在堆内存中给这个对象申请一块内存空间，但当我们使用完了却没有归系统（delete），导致这个不使用的对象一直占据内存单元，造成系统将不能再把它分配给需要的程序。

  内存溢出：是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

• 将程序员从繁重的内存管理中释放出来，专注业务开发。

缺点：

• 弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。

哪些区域要被回收?

垃圾收集器可以对年轻代、老年代、全栈和方法区的回收，其中Java堆是重点

次数上讲：

• 频繁收集Young区
• 较少收集Old区
• 基本不收集元空间（方法区）

2.垃圾回收相关算法

1.垃圾标记阶段算法

**标记阶段目的：**主要为了判断对象是否存活

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

当一个对象已经不再被任何的存活对象继续引用时，就可以宣判已经死亡。

判断对象存活一般有两种方式：

• 引用计数算法

  对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。

  对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。

  优点：

  • 实现简单，垃圾对象便于辨别；
  • 判定效率高，回收没有延迟性。

  缺点：

  • 需要单独的字段存储计数器，增加了存储空间的开销。
  • 每次赋值都需要更新计数器，伴随这加法和减法操作，增加了时间开销。
  • 引用计数器有一个严重的问题，即无法处理循环引用的情况。导致java的垃圾回收器中没有使用这类算法。

• 可达性分析算法（根搜索算法/追踪性垃圾收集）

  优点：

  • 实现简单。
  • 执行高效。
  • 有效解决再引用计数算法中循环引用的问题，反之内存泄漏的发生。

  实现思路

  GCRoots根集合就是一组必须活跃的引用。

  1. 可达性分析算法以根对象集合（GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
  2. 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链。
  3. 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象已经死亡，可以标记为垃圾对象。
  4. 在可达性分析算法中，只有能够被根对象集合直接或间接连接的对象才是存活对象。

  

  GC Roots可以是哪些元素？

  • 虚拟机栈中引用的对象
  • 本地方法栈内JNI（本地方法）引用的对象
  • 方法区中类静态属性引用的对象
  • 方法区中常量引用的对象
  • 所有被同步锁synchronized持有的对象
  • Java虚拟机内部的引用

  **注意：**如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的化分析结果的准确性就无法保证。这点也是导致GC进行时必须“Stop The World”（停止整个程序）的一个重要原因。

• 对象的finalization机制

  finalize（）方法机制（对象销毁前的回调函数）

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

  当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize（）方法。

  finalize（）方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理工作，比如关闭文件、套接字和数据库连接等。

  注意：永远不要主动调用某个对象的finalize（）方法，应该交给垃圾回收机制调用。

  原因：

  • 在finalize（）时可能会导致对象复活。
  • finalize（）方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize（）方法将没有执行机会。
  • 一个糟糕的finalize（）会严重影响GC的性能。比如finalize是个死循环。

• 生存还是死亡？

  由于finalize（）方法的存在，虚拟机中的对象一般处于三种可能状态。

  • 可触及的： 从根节点开始，可以到达这个对象。
  • 可复活的：对象的所有引用都被释放，但是对象有可能在finalize（）中复活。
  • 不可触及的：对象的finalize（）被调用，并没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize（）只会被调用一次。此时可被回收。

具体过程

判断一个对象objA是否可回收，至少要经历两次标记过程：

1. 如果对象objA到GC Roots没有引用链，则进行第一次标记。
2. 进行筛选，判断此对象是否有必要执行finalize（）方法。
   • 如果对象objA没有重写finalize（）方法，或者finalize（）方法已经被虚拟机调用过，则虚拟机视为“没有必要重写执行”，objA被判定为不可触及的。
   • 如果对象objA重写了finalize（）方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize（）方法执行。
   • finalize（）方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize（）方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize（）方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize（）方法只会被调用一次。

2.垃圾回收阶段算法

JVM中比较常见的三种垃圾收集算法：

• 标记-清除算法

  执行过程

  当堆中有效内存空间被耗尽的时候，就会停止整个程序，然后进行两项工作：1.标记2.清除

  • 标记

    Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。

  • 清除

    Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收。

  

  **优点：**容易理解

  **缺点：**效率低；在进行GC的时候，需要停止整个应用程序，用户体验较差；这种方式清理出来的空闲内存是不连续的，产生内碎片，需要维护一个空闲列表（记录垃圾对象地址）。

  **注意：**这里的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次由新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放（覆盖原有的地址）。

• 复制算法

  将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换 两个内存的角色，最后完成垃圾回收。

  

  优点：

  • 实现简单，运行高效。
  • 复制过去以后保证空间的连续性，不会出现”碎片“问题。

  缺点:

  • 内存占用大。
  • 时间开销大。GC需要维护region之间对象的引用关系

  应用场景：如果系统中的垃圾对象很多，需要复制的存活对象数量并不会太大，效率较高。在新生代中回收性价比高。现在的商业虚拟机都是用这种收集算法回收新生代。

3.标记-压缩算法

过程：

• 标记：从根节点开始标记所有被引用对象。
• 压缩：将所有存活对象压缩到内存的一端，按顺序排放。之后，清理边界外的所有空间。

优点：

• 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
• 消除了复制算法当中内存减半的高额代价。

缺点：

• 效率低于复制算法。
• 移动过程中，需要全程暂停用户应用程序。
• 移动过程中，需要全程暂停用户应用程序。

总结

	标记清除	标记压缩	复制
速率	中等	最慢	最快
空间开销	少（但会堆积碎片）	少（不堆积碎片）	通常需要活对象的2倍空间（不堆积碎片）
移动对象	否	是	是

4.分代收集算法

为什么要使用分代收集算法？

不同对象的生命周期不一样。因此不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。

**年轻代：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。**适合复制算法的回收整理。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

**老年代：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。**适合由标记-清除或者标记-清除与标记-整理的混合实现。

分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代。

5.增量收集算法

为什么要使用？

上述现有的算法，在垃圾回收过程中，应用软件将处于一种Stop The World的状态，应用程序所有线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，将严重影响用户体验或系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集算法的诞生。

基本思想

每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

缺点：线程切换和上下文转换的消耗，会使垃圾回收成本上升，造成系统吞吐量的下降。

6.分区算法

将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用，独立回收。好处是可以控制一次回收多少个小区间。

3.垃圾回收相关概念

1.System.gc()

在默认情况下，通过System.gc（）或者Runtime.getRuntime（）.gc（）的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。

然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用（不能确保立即生效）。

JVM实现者可以通过System.gc（）调用来决定JVM的GC行为。而一般情况下，立即回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写应该性能基准，我们可以在运行之间调用System.gc（）。

2.内存溢出与内存泄漏

内存溢出：没有空闲内存，并且垃圾收集器也无法提供更多内存。

内存泄漏：只有对象不会再被程序用到了，但是GC又不能回收他们的情况，叫做严格意义上的内存泄漏。但实际情况很多时候一些不太好的实践会导致对象的生命周期变得很长甚至导致OOM，也叫做宽泛意义上的内存泄漏。

比如：

• 单例模式，单例的生命周期和应用程序是一样长的，所以在单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
• 一些提高close（）的资源未关闭导致内存泄漏。数据库连接、网络连接、io连接。。。

3.Stop The World

是指GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，这个停顿称为STW。

可达性分析算法中枚举根节点会导致所有Java执行线程停顿，为什么需要停顿所有Java执行线程呢？

• 分析工作必须在一个能确保一致性的快照中进行（一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上）。如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证。被STW中断的应用程序线程会在完成GC之后恢复。

STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。

4.对象的引用

在JDK1.2版后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference） 、软引用（Soft Reference） 、弱引用（Weak Reference）、虚引用（Phantom Reference） 。

四种引用强度逐渐减弱。除强引用外，其他三种引用均可以在java.lang.ref包中找到。

Reference 子类中只有终结器引用是包内可见的，其他 3 种引用类型均为public，可以在应用程序中直接使用.

• 强引用（默认）：是指在程序代码之中普遍存在的引用赋值，即类似“Object obj = new Object()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。造成Java内存泄漏的主要原因之一。
• 软引用：内存不足即回收。在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。
• 弱引用：发现即回收。被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。
• 虚引用：对象回收跟踪。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

4.垃圾回收器

按线程数分：

• 串行垃圾回收器：指的是同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。
• 并行垃圾回收器：可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，此时工作线程被暂停，直至垃圾收集工作结束。

按工作模式分：

• 并发式垃圾回收器：与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。
• 独占式垃圾回收器：一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。

按工作的内存区间分：

• 年轻代垃圾回收器
• 老年代垃圾回收器

1.GC性能指标

吞吐量：运行用户代码的时间栈总运行时间的比例（总运行时间：程序的运行时间+内存回收的时间） 。

垃圾收集开销：垃圾收集所用时间与总运行时间的比例。

暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。

收集频率：相对于应用程序的执行，收集操作发生的频率。

内存占用：Java 堆区所占的内存大小。

快速：一个对象从诞生到被回收所经历的时间。

2.HotSpot垃圾收集器

串行回收器：Serial，Serial old

并行回收器：ParNew，Parallel scavenge，Parallel old

并发回收器：CMS、G1

新生代收集器：Serial，ParNew.Parallel scavenge；

老年代收集器：Serial old.Parallel old.cMS；

整堆收集器：G1；

• Serial垃圾收集器（单线程）

  只开启一条GC线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程。

  适合客户端使用（内存小，堆内存不大，不会创建太多对象）。

  优点：简单高效。

  

• ParNew垃圾收集器（多线程）

  ParNew是Serial的多线程版本。使用了多线程进行垃圾收集，在多CPU环境下性能比Serial会有一定提升；但线程切换需要额外的开销，因此在单CPU环境中表现不然Serial。

  

• Parallel Scavenge垃圾收集器（多线程）

  和ParNew一样都是多线程、新生代垃圾收集器。

  不同：

  Parallel Scavenge追求CPU吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。

  ParNew：追求降低用户停顿时间，适合交互式应用。

• Serial Old垃圾收集器（单线程）

  是Serial的老年版本，都是单线程收集器，只启用一条GC线程，都适合客户端应用。

  唯一区别：Serial Old工作在老年代，使用“标记-整理”算法；Serial工作在新生代，使用复制算法。

• Parallel Old垃圾收集器（多线程）

  是Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

• CMS回收器（低延迟）

  CMS(Concurrent Mark Sweep，并发标记清除)收集器是以获取最短回收停顿时间为目标的收集器，他在垃圾收集时使得用户线程和GC线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。

  • 初始标记：Stop The World，仅使用一条初始标记线程对所有与GC Roots之间关联的对象进行标记。

  • 并发标记：使用多条标记线程，与用户并发执行。此过程进行可达性分析，标记出所有废弃对象。速度很慢。

  • 重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发

    标记过程中新出现的废弃对象标记出来。

  • 并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记

    的对象。这个过程非常耗时。

  

  优点：

  • 并发收集
  • 低延迟

  缺点：

  • 会产生内存碎片
  • CMS收集器对CPU资源非常敏感。
  • 无法处理浮动垃圾。

• G1回收器（区域划分代式）

  因为应用程序所应对的业务越来越大、复杂，用户越来越多，没有GC就不能保证应用程序正常进行，而经常造成STW的GC又跟不上实际的需求，所以在Java7 update 4后引入了G1（Garbage-First）。

  **目标：**在延迟可控的情况下获得尽可能高的吞吐量。

  

  G1是一个并行回收器，它把堆内存分割为很多不相关的区域。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。

  G1跟踪各个Region里面的垃圾堆积价值的大小（回收所获得的空间大小以及回收所需时

  间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。侧重点在于回收垃圾最大量的区间。

  G1是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高的概率满足GC停顿时间的同时，还兼备高吞吐量的性能特征。

  从整体上看，G1 是基于“标记-整理”算法实现的收集器，从局部（两个 Region之间）上看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。

  一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？

  并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上Remembered Set 即可防止对整个堆内存进行遍历。

  工作过程：

  • 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。

  • 并发标记：使用一条标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。

  • 最终标记：Stop The World，使用多条标记线程并发执行。

  • 筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收

    线程并发执行。