JVM对象回收依据和垃圾回收算法

对象回收依据

前面介绍的Java内存运行时区域的各个部分中，程序计数器、虚拟机栈、本地方法栈会随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出执行着出栈和入栈的操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由即时编译器进行一些优化，但在基于概念模型的讨论里，答题上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，当方法结束或线程结束时，内存自然就跟随着回收了。
而Java堆和方法区这两个区域则有显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也可能不一样，只有在运行期间，我们才知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器所关注的正式这部分内存该如何管理。
设置JVM参数 -XX:+PrintGCDetails，可以打印垃圾收集的日志信息。

引用计数法

引用计数法（Reference Counting）：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；当计数器为0时对象就是不再被使用的。这种方式实现简单，但是主流垃圾收集器没有用这种方式管理内存的，因为这种方式很难解决循环依赖问题：比如两个对象A和B互相引用，在没有其他地方应用它俩了，但是它俩的计数都不为0，这就永远不会被回收。

可达性分析算法

可达性分析（Reachability Analysis）：通过一系列的称为 “GC Roots” （GC根）的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象倒GC Roots没有任何引用链相连（就是从GC Roots到对象不可达）时，则证明此对象是不可用的，主流的开发语言都是使用的这种方式判断对象是否存活的。如下图所示，object5，object6，object7虽然相互关联，但是GC Roots是不可达的，所以这些对象是可回收的。当前主流的商用语言的内存管理都是通过可达性分析算法来判定对象是否存活的。

Java中的GC Roots对象

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法中使用到的参数、局部变量、临时变量等。
• 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
• 在方法区中常量引用的对象，譬如字符串常量池里（String Table）的引用。
• 在本地方法栈中JNI（Native方法）引用的对象。
• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointException、OutOfMemoryError等），还有系统类加载器。
• 所有被同步锁（synchronized关键字）持有的对象。
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
  除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器，以及当前回收内存区域不同，还可以有其他对象”临时性“地加入，共同构成完整的GC Roots集合。譬如后文将会提到的分代收集和局部回收（Partial GC），如果只针对Java堆中某一块区域发起垃圾收集时（如最典型的只针对新生代的垃圾收集），必须考虑到内存区域是虚拟机自己的实现细节（在用户视角里任何内存区域都是不可见的），更不是独立封闭的，所以某个区域里的对象完全有可能被位于堆中其他区域对象所引用，这时候就需要将这些关联区域的对象也一并加入GC Roots集合中去，才能保证可达性分析的正确性。
  目前最新的i款垃圾收集器（OpenJDK中的G1、Shenandoah、ZGC以及Azul的PGC、C4）无一例外都具备了局部回收的特征，为了避免GC Roots包含过多对象而过度膨胀，它们在实现上也做出了各种优化处理。

对象的引用类型

无论是通过引用计数法判断对象的引用数量，还是哦通过可达分析算法判断对象是否引用链可达，判定对象是否存活都和“引用”离不开关系。在JDK1.2以前，Java里的引用是很传统的定义：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称该reference书是代表某块内存、某个对象的引用。这种定义过于狭隘，一个对象在这种定义下只有“被引用”和“未被引用”两种状态，对于描述一些“食之无味，弃之可惜”的对象就显得无能为力。譬如我们希望能够描述一类对象：当内存空间还足够时，能保留在内存之中，如果内存空间在进行垃圾收集后仍然非常紧张，那就可以抛弃这些对象——很多系统的缓存功能都符合这样的应用场景。
在JDK1.2之后，Java堆引用的概念进行扩充，将引用分为强引用（Strongly Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference），这四种引用强度依次逐渐减弱。

强引用

强引用是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“Obect obj = new Object()”这种引用关系。无论任何情况下，只要强引用关系存在，垃圾收集器就永远不会回收掉被引用的对象。

软引用

软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后提供了SoftReference类来实现软引用。

弱引用

弱引用也是用来描述非必须对象，但是它的强度比软引用更弱一些，被软引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后提供了WeakReference类来实现弱引用。

虚引用

虚引用也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后提供了PhantomReference类来实现虚引用。

对象回收前的准备工作

即使是在可达性分析算法中判定为不可达的对象，也不是“非死不可”，要真正宣告一个对象的死亡，至少要经历两次标记过程：

• 如果一个对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那么它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。加入对象没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。
• 如果这个对象被判定为有必要执行finalize()方法，那么该对象就会被放置在一个名为F-Queue的队列之中，并在稍后由一条虚拟机自动建立、低优先级的Finalizer线程去执行他们的finalize()方法。**这里所说的"执行"是指虚拟机会触发这个方法开始运行，但不承诺一定会等待它运行结束。**这样做的原因是：如果某个对象的finalize()方法方法执行缓慢或产生了死循环，将很可能导致F-Queue队列中的其他对象永久处于等待，甚至导致整个内存回收子系统的崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，在第二次标记时它将被移除“即将回收”这个集合；如果这个时候对象还没有逃脱，那基本上就真的要被回收了。

回收方法区

有些人认为方法区（例如HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，《Java虚拟机规范》中提到过可以不要求虚拟机在方法区中实现垃圾回收，事实上也确有未实现或者未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类型卸载），方法区垃圾收集的“性价比”通常是比较低的：在Java堆中，尤其是在新生代中，对常规应用进行一次垃圾收集通常可以回收70%—99%的内存空间，相比之下，方法区回收囿于苛刻的判定条件，其区域垃圾收集的回收成果远远低于此。
方法区的垃圾收集主要回收两部分内容：废弃的常量和不再使用的类型。

方法区中常量的回收

回收废弃常量与回收Java堆中对象非常类似。举个常量池中字面量回收的例子：假如一个字符串"java"曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是"java"，换句话说，已经没有任何字符串对象引用常量池中的"java"常量，且虚拟机中也没有其他地方引用这个字面量。如果正在这时发生内存回收，而且垃圾收集器判断确有必要的话，"java"这个常量就将会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用也与此类似。

方法区中类型的回收

判断一个常量是否“废弃”还是相对简单的，但而要判定一个类型是否属于“不再被使用的类”的判断条件就比较苛刻了。需要同时满足以下三个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何子类的实例。
• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则是很难达成的。
• 该类堆应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
  Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而不是像对象一样，没有了引用就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息。其中-verbose:class和-XX:+TraceClassLoading可以在Product版本的虚拟中使用，-XX:+TraceClassUnLoading参数需要在FastDebug版的虚拟支持。
  在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要ava虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

垃圾收集算法

从如何判定对象消亡的角度出发，垃圾收集算法可以划分为“引用计数式垃圾收集”（Reference Counting GC）和“追踪是垃圾收集”（Tracing GC）两大类，这两类也常被称为“直接垃圾收集”和“间接垃圾收集”。

分代收集理论

当前商业虚拟机的垃圾回收器大多数都遵循了“分代收集”（Generational Collection）的理论进行设计，分代收集名为理论，实质上是一套符合大多数程序运行实际情况的经验法则，它建立在两个分代假说之上：

• 弱分代假说（Weak Generational Hypothesis）：大多数对象都是朝生夕灭的。
• 强分代假说（Strong Generational Hypothesis）：熬过越多次来讲收集过程中的对象就越难以消亡。
  这两个分代假说共同奠定了多款常用的垃圾收集器的设计原则：收集器应该将Java堆划分出不同区域，然后就回收对象依据其年龄（对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。显而易见，如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，那么把它们集中放在一起，每次回收时只关注如何保留少量存活而不是去标记那些大量将要回收的对象，就能以较低代价回收到大量的空间；如果剩下的都是难以消亡的对象，那把它们集中放在一块，虚拟机便可以使用较低的频率来回收这块区域，这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。
  在Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或这某些部分区域——因而才有了“Minor GC”、“Major GC”、“Full GC”这样的回收类型的划分；也才能够针对不同的区域安排与区域内存储对象存亡特征相匹配的垃圾收集算法——因而发展出了“标记-复制算法”、“标记-清除算法”、“标记-整理算法”等针对性的垃圾回收算法。
  把分代收集理论具体放到现在的商用Java虚拟机里，这记者一般至少会把Java堆划分为新生代（Young Generation）和老年代（Old Generation）两个区域。但分代收集并非只是简单划分一下内存区域那么容易，它至少还存在一个明显的困难：对象不是孤立的，对象之间会存在跨代引用。假如现在要进行一次只局限于新生代区域内的收集（Minor GC），但新生代中的对象是完全有可能被老年代所引用的，为了找出该区域中的存活对象，不得不在固定的GC Roots之外，再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性。遍历整个老年代所有对象的方案虽然理论上可行，但无疑会为内存回收带来很大的性能负担。为了解决这个问题，就需要堆分代收集理论添加第三条经验法则：
• 跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用想到对于同代引用来说仅占极少数。
  依据这条假说，我们就不应在为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在跨代引用以及存在哪些跨代引用，只需要在新生代上简历一个全局的数据结构（记忆集，Remember Set），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系（如将自己或者某个属性赋值）时维护记录数据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍然是划算的。

标记-清除算法

这是最早出现也是最基础的垃圾收集算法，后续的手机就算法大多是以它为基础，对其缺点进行改进而得到的。如它的名字，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象。
标记-清除算法回收的效果图如下：

通过上面的图片我们可以看到“标记-清除”算法主要缺点有两个：

• 执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分都是需要被回收的，这是必须进行大量标记和清除的动作，导致标记和清除这两个过程的执行效率都随着对象数量增长而降低。
• 内存空间碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。

标记-复制算法

为了接解决"标记-清除"算法面对大量可回收对象执行效率低的问题，提出了一种称为“半区复制”（Semispace Copying）的垃圾收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活的着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，这种复制回收算法的代价是将可用内存缩小为了原来的一半没空间浪费太多。
标记-复制算法回收的效果图如下：

现代商用Java虚拟机大多都优先采用了这种收集算法区回收新生代，IBM公司曾有一项专门研究新生代对象“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此并不需要按照1 : 1的比例来划分新生代的内存空间。
Andrew Appel针对对象“朝生夕灭”的特点，提出了一种更优化的半区复制分代策略，称为"Appel式回收“。HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只是用Eden和一块Survivor。发生垃圾收集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已经用过的那块Survivor空间。HotSpot虚拟机默认的Eden和Survivor的大小比例是8 : 1，即每次新生代中可用内存空间为整个空间容量的90%，即10%的新生代是会被浪费的。98%的对象可被回收仅仅是测试数据，任何人都没有办法保证每次回收都只有不多于10%的对象存活，因此Appel式回收有一个充当罕见情况的”逃生门“的安全设计：当Survivor空间不足以容纳一次Minor GC之后存活的对象时，就需要依赖内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。
内存的分配担保机制是：如果另一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，这些对象便将通过分配担保机制直接进入老年代。

标记-整理算法

标记-复制算法在对象存活率较高时就要将进行较多大的复制操作，效率会降低，并且还有额外空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
针对老年代对象的存亡特征，提出了标记-整理（Mark-Compact）算法，其中的标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，二十让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。
标记-整理算法回收的效果图如下：

如果移动存活对象，尤其是在老年代这种每次回收都又大量对象存活的区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停所有用户线程才能进行，像这样的停顿被最初的虚拟机设计者称为“Stop The World”。
但如果像标记-清除算法那样完全不考虑移动和整理存活的对象的话，弥散与堆中存活对象导致的空间碎片化问题就只能依赖于更复杂的内存分配器和内存访问器来解决。如通过“分区空闲分配链表”来解决内存分配问题（计算机硬盘存储大文件就不要求物理连续的磁盘空间，能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的）。内存访问是用户最频繁的操作，加入在这个环节上增加了额外的负担，必然会直接影响应用程序的吞吐量。
基于以上两点，是否移动对象都存在弊端，从垃圾收集的时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，但从整个应用的吞吐量来看，移动对象会更划算。HotSpot虚拟机里面关注吞吐量的Parallel Scavenge收集器是基于标记-整理算法的，而关注延迟的CMS收集器则是基于标记-清除算法的。
另外还有一种“和稀泥式”的解决方案可以不再内存分配和访问上增加额外负担，做法是让虚拟机平时多数时间采用标记-清除算法，暂时容忍内存碎片的存在，知道内存空间的碎片化程度已经大到影响对象分配时，在采用标记-整理算法收集一次，以获得规整的内存空间。CMS收集器是基于标记-清除算法的，但面临空间碎片过多时采用的就是这种处理办法。

文章参考：
《深入理解Java虚拟机第三版》、判断对象是否可回收、垃圾回收算法