脚踏实地

访问量 次
访客数 人

JVM中的垃圾回收机制

2021.04.21 阅读量次

什么是垃圾

垃圾回收（Garbage Collection，GC），顾名思义就是释放垃圾占用的空间，防止内存爆掉。有效的使用可以使用的内存，对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收。 如果不及时对内存中的垃圾进行清理，那么这些垃圾对象所占的内存空间会一直保留到应用程序的结束，被保留的空间无法被其它对象使用，甚至可能导致内存溢出。

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

垃圾收集机制是Java的招牌能力，极大地提高了开发效率。 如今，垃圾收集几乎成为现代语言的标配，即使经过如此长时间的发展，Java的垃圾收集机制仍然在不断的演进中，不同大小的设备、不同特征的应用场景，对垃圾收集提出了新的挑战，这当然也是面试的热点。

垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。 一般用会有这么几种算法来确定一个对象是否是垃圾：

  • 引用计数算法
  • 可达性分析算法

为什么需要垃圾回收

对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早都会被消耗完，因为不断地分配内存空间而不进行回收，就好像不停地生产生活垃圾而从来不打扫一样。

除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象。

随着应用程序所应付的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。

早期垃圾回收

在早期的C/C++时代，垃圾回收基本上是手工进行的。 开发人员可以使用 new 关键字进行内存申请，并使用 delete 关键字进行内存释放。例如以下代码：

MibBridge *pBridge= new cmBaseGroupBridge();
//如果注册失败，使用Delete释放该对象所占内存区域
if(pBridge->Register (kDestroy) != NO ERROR）
	delete pBridge;

这种方式可以灵活控制内存释放的时间，但是会给开发人员带来频繁申请和释放内存的管理负担。

倘若有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生内存泄漏。 垃圾对象永远无法被清除，随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃。

有了垃圾回收机制后，上述代码极有可能变成这样

MibBridge *pBridge=new cmBaseGroupBridge(); 
pBridge->Register(kDestroy);

现在，除了Java以外，C#、Python、Ruby等语言都使用了自动垃圾回收的思想，也是未来发展趋势，可以说这种自动化的内存分配和来及回收方式已经成为了现代开发语言必备的标准。

Java的垃圾回收机制

自动内存管理，无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险。 没有垃圾回收器，Java也会和C++一样，各种悬垂指针、野指针、泄露问题让你头疼不已。 自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发。

对于Java开发人员而言，自动内存管理就像是一个黑匣子，如果过度依赖于“自动”，那么这将会是一场灾难，最严重的就会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。 此时，了解JVM的自动内存分配和内存回收原理就显得非常重要，只有在真正了解JVM是如何管理内存后，我们才能够在遇见outOfMemoryError时，快速地根据错误异常日志定位问题和解决问题。

当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。

垃圾回收主要关注的区域

垃圾收集器主要对方法区 、堆中的垃圾进行收集。 GC作用区域

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

针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种：

  • 部分收集 (Partial GC)：
    • 新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集；
    • 老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集；
    • 混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。
  • 整堆收集 (Full GC)：收集整个 Java 堆和方法区。

从次数上讲：频繁收集新生代 > 较少收集老年代 » 基本不收集方法区

垃圾判定算法

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

在运行程序中，当一个对象已经不再被任何存活的对象引用时，就可以就可以判定该对象已经死亡了。 判定对象是否存活在有两种算法，引用计数算法、可达性分析算法。

引用计数算法

引用计数算法是通过在对象头中分配一个空间来保存该对象被引用的次数。 如果该对象被其它对象引用，则它的引用计数加 1，如果删除对该对象的引用，那么它的引用计数就减 1，当该对象的引用计数为 0 时，那么该对象就会被回收。 在堆中判定新生代中的幸存者区是否可以进老年代，会有一个年龄计数器，这里用的就是引用计数算法。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间循环引用的问题。 当p的指针断开的时候，内部的引用形成一个循环，从而造成内存泄漏。

循环引用

虽然引用计数算法存在循环引用的问题，但是很多语言的资源回收选择，例如：因人工智能而更加火热的Python，它更是同时支持引用计数和垃圾收集机制。 具体哪种最优是要看场景的，业界有大规模实践中仅保留引用计数机制，以提高吞吐量的尝试。

Python如何解决循环引用？

  • 手动解除：很好理解，就是在合适的时机，将引用计数器中的计数属性置为零，解除引用关系。
  • 使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用。

可达性分析算法

可达性分析算法是以根对象集合GCRoots为起始点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到GCRoots没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。

可达性分析算法

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是，该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。 只要你无法与GCRoot建立直接或间接的连接，系统就会判定你为可回收对象。所谓根集合GCRoots就是一组必须活跃的引用，即有在栈中有指针指向堆中的地址，它们是程序运行时的起点，是一切引用链的源头。

在Java中，GCRoots包括以下几种：

  1. 虚拟机栈中引用的对象；例如：各个线程被调用的方法中使用到的参数、局部变量等；
  2. 本地方法栈内,本地方法引用对象方法区中类静态属性引用的对象;例如：Java类的引用类型静态变量；
  3. 方法区中常量引用的对象；例如：字符串常量池里的引用；
  4. 所有被同步锁synchronized持有的对象；
  5. Java虚拟机内部的引用；例如：一些常驻的异常对象、系统类加载器等；
  6. 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等；
  7. 除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GCRoots集合，比如：分代收集和局部回收；

除了堆空间产生对象的一些结构外，比如：虚拟机栈、本地方法栈、方法区、字符串常量池等地方对堆空间的对象的引用，都可以作为GCRoots进行可达性分析。

对象集合GCroots

如何判定是否为GC root? 由于Root采用栈方式存放变量和指针，所以如果一个指针，保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个GC root。代码演示：

public class StackReference {
    public void greet() {
        Object localVar = new Object(); // 这里的 localVar 是一个局部变量，存在于虚拟机栈中
        System.out.println(localVar.toString());
    }

    public static void main(String[] args) {
        new StackReference().greet();
    }
}
  • 在greet方法中localVar是一个局部变量，存在于虚拟机栈中，可以被认为是GCRoots。
  • 在greet方法执行期间，localVar引用的对象是活跃的，因为它是从GCRoots可达的。
  • 当greet方法执行完毕后，localVar的作用域结束，localVar引用的 Object 对象不再由任何GCRoots引用（假设没有其他引用指向这个对象），因此它将有资格作为垃圾被回收掉。

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行，如果这点不满足，分析结果的准确性就无法保证。 简单来说就是执行这个算法的时候，要停止程序标记对象，不能一边改变对象的引用一边判定对象是不是垃圾。

这点也是导致GC进行时必须Stop The World的一个重要原因。即使是号称几乎不会发生停顿的CMS收集器，标记根节点时也是必须要停顿的。

垃圾收集算法

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。 目前在JVM中比较常见的三种垃圾收集算法是:

  • 标记清除算法（Mark-Sweep）
  • 复制算法（Copying）
  • 标记整理算法（Mark-Compact）

标记清除算法

标记清除算法是一种非常基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并并应用于Lisp语言。

标记清除算法是最基础的一种垃圾回收算法，它分为两部分，先把内存区域中的这些对象进行标记，哪些属于可回收的标记出来（可达性分析法），然后把这些垃圾拎出来清理掉。 当堆中的有效内存空间被耗尽的时候，就会STW，然后进行两项工作，第一项则是标记，第二项则是清除；

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

标记清除算法

标记的是可达对象，不是垃圾对象，清除回收的是垃圾对象。

标记的是可达对象，不是垃圾对象，清除回收的是垃圾对象，那么什么是清除？

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

缺点：

  • 标记清除算法的效率不算高；
  • 在进行GC的时候，需要停止整个应用程序，用户体验较差；
  • 这种方式清理出来的空闲内存是不连续的，会产生内碎片，需要维护一个空闲列表；存放大对象可能会存不下；

复制算法

复制算法是在标记清除算法上演化而来的，为了解决标记清除算法的内存碎片问题，M.L.Minsky于1963年发表了著名的论文：“使用双存储区的Lisp语言垃圾收集器（CA LISP Garbage Collector Algorithm Using Serial Secondary Storage）”。 M.L.Minsky在该论文中描述的算法被人们称为复制算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，它也被M.L.Minsky成功地引入到了Lisp语言的一个实现版本中。

复制算法

将分配内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中存活对象复制到未被使用的内存块中去，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

复制算法虽然解决了标记清除算法带来的问题，实现简单，运行高效，但是也出现了新的问题：

  • 因为用复制的形式，需要两倍的内存空间，或者说只能用分配内存的一半。
  • 对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小； 简单来说，从From区被复制到To区的可达对象，需要改变之前对象的指针引用，需要内存和时间的开销。

复制算法最坏情况，如果系统中的垃圾对象很少，复制算法需要复制的存活对象数量就会很多，那么大部分对象从一个区域移动到另一个区域，GCRoots需要改变了对象的地址，加大了维护成本。 所以复制算法适合，系统中的垃圾对象很多，可复制的存活的对象很少的情况。利用这个特点，在新生代中的幸存者区里面就用到了复制算法的思想。

标记整理算法

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。 如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

标记清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。 1970年前后，G.L.Steele、C.J.Chene和D.s.Wise等研究者发布标记整理算法。在许多现代的垃圾收集器中，人们都使用了标记整理算法或其改进版本。

标记整理算法

标记整理算法，标记过程仍然与标记清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，再清理掉端边界以外的内存区域。

执行过程：

  • 标记：垃圾收集器从引用根节点（GCRoots）开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
  • 整理：将所有的存活对象压缩到内存的一端，按顺序排放，之后执行清除的步骤。
  • 清除：垃圾收集器对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收。

与标记清理算法相比，多了一个步骤"压缩（整理）"，也就是移动对象的步骤，是否移动回收后的存活对象是一项优缺点并存的风险决策。 标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

标记整理算法，消除了标记清除算法当中，内存区域分散的缺点，也规避了复制算法当中，内存减半的高额代价。 看起来很美好，但由于多了整理这一步，内存变动更频繁，需要整理所有存活对象的引用地址，在效率上比复制算法差很多。

标记整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记清除多了一个整理内存的阶段。

标记清除算法 标记整理算法 复制算法
时间开销 中等 最慢 最快
空间开销 少（会堆积碎片） 少（不堆积碎片） 通常需要存活对象的两倍空间（不堆积碎片）
移动对象 否 是 是

这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法思想应运而生。

分代收集思想

分代收集算法严格来说并不是一种思想或理论，而是融合上述三种基础的算法思想，而产生的针对不同情况所采用不同算法的一套组合拳。

分代收集算法，是基于不同的对象的生命周期是不一样的这样一个事实。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。 一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。 但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

分代的思想被现有的虚拟机广泛使用，几乎所有的垃圾回收器都区分新生代和老年代。 在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

  • 年轻代：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。适合复制算法；复制算法内存利用率不高的问题，通过Hotspot中的两个幸存者区的设计得到缓解。
  • 老年代：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。不适合复制算法，一般是由标记清除或者是标记清除与标记整理的混合实现。

增量收集算法

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

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。 每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

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

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。 但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。 为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。

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

Java JVM
发表评论