JVM垃圾回收机制

1 垃圾回收区域

  GC主要关注于堆中（重点关注堆）和方法区的垃圾收集
  引申点：虚拟机栈，本地方法栈，程序计数器不用考虑GC；不会发生OOM的区域只有程序计数器。

  Java 内存运行时区域中的程序计数器、虚拟机栈、本地方法栈随线程而生灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由 JIT 编译器进行一些优化），因此这几个区域的内存分配和回收都具备确定性，不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

  而 Java 堆不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

  从次数上讲：

  1 频繁收集Young区
 &emsp2; 较少收集Old区
  3 基本不收集Perm区（元空间）

2 垃圾回收相关算法

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

  那么在JVM中究竟是如何标记一个死亡对象呢？简单来说，当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡。

2.1 引用计数器算法

  给对象添加一引用计数器，被引用一次计数器值就加 1；当引用失效时，计数器值就减 1；计数器为 0 时，对象就是不可能再被使用的，简单高效，缺点是无法解决对象之间相互循环引用的问题。

2.2 可达性分析算法

  Java使用的就是此种算法，通过一系列的称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。此算法解决了上述循环引用的问题。

2.2.1 可作为 GC Roots 的对象

在Java语言中，可作为 GC Roots 的对象举例几种：
  a. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
  b. 方法区中类静态属性引用的对象。
  c. 方法区中常量引用的对象。
  d. 本地方法栈中 JNI（Native方法）引用的对象

  总结一句话就是，除了堆空间外的一些结构，比如 虚拟机栈、本地方法栈、方法区、字符串常量池 等地方对堆空间进行引用的，都可以作为GC Roots进行可达性分析。

  其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此也可能是 GC roots 的一部分。

2.2.2 二次标记回收对象

  不可达的对象将暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

  1、如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。

  2、当对象没有重写 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，直接进行第二次标记。

  3、如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。

  这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，因为如果一个对象在 finalize() 方法中执行缓慢，将很可能会一直阻塞 F-Queue 队列，甚至导致整个内存回收系统崩溃。

2.2.3 对象的finalization机制

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

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

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

注意：永远不要主动调用某个对象的finalize（）方法应该交给垃圾回收机制调用。
理由包括下面三点：

  1、在finalize（）时可能会导致对象复活。
  2、finalize（）方法的执行时间是没有保障的，它完全由Gc线程决定，极端情况下，若不发生GC，则finalize（）方法将没有执行机会。因为优先级比较低，即使主动调用该方法，也不会因此就直接进行回收
  3、一个糟糕的finalize（）会严重影响Gc的性能

3 强、软、弱、虚引用

JDK1.2 以前，一个对象只有被引用和没有被引用两种状态。

后来，Java 对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4 种，这 4 种引用强度依次逐渐减弱。

  1、 强引用就是指在程序代码之中普遍存在的，类似"Object obj=new Object()"这类的引用，垃圾收集器永远不会回收存活的强引用对象。
  2、 软引用：还有用但并非必需的对象。在系统 将要发生内存溢出异常之前 ，将会把这些对象列进回收范围之中进行第二次回收。
  3、 弱引用也是用来描述非必需对象的，被弱引用关联的对象 只能生存到下一次垃圾收集发生之前 。当垃圾收集器工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象。
  4、 虚引用是最弱的一种引用关系。 无法通过虚引用来取得一个对象实例 。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

4 Java 堆永久代的回收

永久代（方法区）的垃圾收集主要回收两部分内容：废弃常量和无用的类。

  1、回收废弃常量与回收 Java 堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个 String 对象是叫做"abc"的，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个"abc"常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

  2、类需要同时满足下面 3 个条件才能算是“无用的类”：
   a. 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
   b. 加载该类的 ClassLoader 已经被回收。
   c. 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
  虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样，不使用了就必然会回收。

  在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

5 垃圾收集算法

  一共有 4 种：

  1、标记-清除算法
  2、复制算法
  3、标记整理算法
  4、分代收集算法

5.1 标记-清除算法

  最基础的收集算法是“标记-清除”（Mark-Sweep）算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

  它的主要不足有两个：
  1、效率问题，标记和清除两个过程的效率都不高；
  2、空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后  在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

  标记—清除算法的执行过程如下图。

5.2 复制算法

  为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

  这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。复制算法的执行过程如下图：

  新生代中98%的对象都是 ‘‘朝生夕死’’ 的,所以并不需要按照1:1的比例来划分空间，而是将内存（新生代内存）分为一块**比较大的Eden(伊甸园)和两块较小的Survivor(幸存者)**空间,每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区）。当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间

  HotSpot默认Eden：Survivor From：Survivor To=8:1:1,所以每次新生代可用内存空间为整个新生代容量的90%，而剩下的10%用来存放回收后存活的对象。

  当Survivor空间不够用时，需要依赖其它内存(老年代进行分配担保)

  HotSpot实现复制算法的流程:

  1、 当Eden区满的时候，会触发第一次Minor gc，把还活着的对象拷贝到Survivor From区；当Eden区再次触发Minor gc的时候，会扫描Eden和From区域，对两个区域进行垃圾回收，经过这次回收后还存活的对象，直接赋值到To区域，并将Eden和From区域清空。
  2、当后续Eden又发生Minor gc的时候，会对Eden和To区域进行垃圾回收，存活的对象复制到From区域，并将Eden和To区域清空。
  3、 部分对象会在From和To区域中复制来复制去，如此交换15次（由JVM参数MaxTenuringThreshold决定，这个参数默认是15），最终还是存活，就存入老年代。

5.3 标记-整理算法

  复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用这种算法。

  根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如下：

5.4 分代收集算法

  当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期的不同将内存划分为几块并采用不用的垃圾收集算法。

  一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

5.5 问题拓展

5.5.1 为什么新生代不使用标记-整理算法？

  复制算法与标记-整理算法都有标记的过程，标记的过程都是采用可达性分析算法，所以跳过这个步骤接着分析。

  复制算法接下来是把标记存活的对象复制到另一块内存区域中，标记-整理算法是将标记的对象整理到一端，这个时候需要注意，并没有进行内存空间清理，针对于新生代需要清理的对象数量十分巨大，所以在将存活的对象插入到待清理对象之前，需要大量移动操作，时间复杂度很高；反观复制算法，不需要移动待回收对象的操作，直接将存活对象复制到另一块空闲内存区域中，大大减小了时间复杂度。

  简单的来说，如果采用了标记整理算法，标记出来的对象需要统一移到一端，但是新生代的对象是朝生夕死的，每一次gc都要频繁移动存活对象，远远没有使用复制算法把存活对象复制到幸存区效率要高，所以这就是为什么新生代不使用标记整理算法。

5.5.2 为什么老年代不使用复制算法？

  考虑到老年代对象的存活周期比较长， 复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。

  更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用这种算法。