JVM学习笔记(二)：JVM GC机制与垃圾收集器

最新推荐文章于 2024-06-07 17:48:28 发布

怕乌龟骑

最新推荐文章于 2024-06-07 17:48:28 发布

阅读量591

点赞数

分类专栏： Java 文章标签： JVM GC机制对象生存判定至少两次标记 F-Queue finalize()

本文为博主原创文章，欢迎转载，不必注明，欢迎注明。

本文链接：https://blog.csdn.net/Zereao/article/details/103563850

版权

Java 专栏收录该内容

12 篇文章 2 订阅

订阅专栏

引子

在上一篇文章《JVM学习笔记(一)：Java内存区域》中，我总结了一下几大Java内存区域。接下来，我总结一下JVM的GC机制，以及垃圾收集算法和垃圾收集器。

内存回收区域

谈起JVM的GC机制，我们首先需要关注的就是：回收哪儿的内存？如何判断哪些内存需要被回收？怎么回收？下面就一一解答这些问题。

在上一篇文章中提到的程序计数器、虚拟机栈、本地方法栈三个“线程私有”的区域，随线程生、随线程灭。栈中的栈帧随着方法的进入和退出有条不紊地执行着入栈和出栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就是已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，方法结束或线程结束时，内存就自然跟随着回收了。

而Java堆和方法区则不一样，我们只有在运行时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的。垃圾回收器主要关注的就是这两个部分的内存。

几种引用

在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用和虚引用，这四种引用强度依次减弱。

强引用：强引用是传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“User tom = new User()”这种引用关系。无论在任何情况下，只要强引用关系关系还存在，垃圾收集器就永远不会回收掉被引用的对象。
软引用：被软引用关联着的对象，在系统将要发生内存溢出前，会把这些对象列入回收范围之中，如果这次回收后仍然没有足够的内存，就会抛出内存溢出异常。在JDK 1.2之后提供了SoftReference类来实现软引用。
弱引用：被弱引用关联着的对象只能生存到下一次垃圾回收发生为止。当垃圾收集器开始工作，不管当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后提供了WeakReference类来实现弱引用。
虚引用：也称“幽灵引用”或“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用存在，完全不会对其生存时间造成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2之后提供了 PhantomReference类来实现虚引用。

对象存活判断

在Java堆中存放着几乎所有的Java对象，垃圾收集器在对堆内存进行回收时，首先就要判断这些对象之中哪些还存活，哪些可以被回收。判断对象是否存活，常见的有两种算法：引用计数算法和可达性分析算法。

引用计数算法

引用计数算法（Reference Counting）就是：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加 1；当引用失效时，计数器值就减 1；在任一时刻，计数器为 0 的对象就是不可能再被使用的。

引用计数算法的优点是实现简单，判定效率也很高；缺点是很难解决对象之间相互循环引用的问题。这也就是主流的Java虚拟机里面都没有选用引用计数算法来管理内存的原因。

可达性分析算法

可达性分析算法的思想就是：通过一系列称为“GC Roots”的对象作为起始点集合，从这些节点向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连，则说明此对象是不会再被使用的。

如上图，虽然Object 5、Object 6、Object 7虽然互相有关联，但是他们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

此外，可以作为GC Roots节点的对象包含以下几种：

方法区中类静态属性引用的对象
方法区中常量引用的对象
在本地方法栈中 JNI(即 Native方法)引用的对象
在虚拟机栈(栈帧中的本地变量表)中引用的对象
所有被同步锁(synchronized关键字)持有的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象(如NullPointerException、OutOfMemoryError等)，还有系统类加载器。
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

垃圾收集算法

这里只介绍几种算法的思想，具体的算法实现一般也不会考~😁

1、标记-清除算法

标记-清除（Mark-Sweep）算法是最基础的收集算法，后续的收集算法都是基于该算法的思路改进而来的。

算法的基本思想是：算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

算法的不足主要有两点：

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

这里的标记过程，我会在后文 补充说明 模块详细描述我的理解。

2、复制算法

为了解决效率问题，一种被成为“复制”（Copying）的收集算法出现了。

算法的基本思想是：将内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把之前使用过的那一块内存空间一次性清理掉。

这种算法的优点是：每次都是对整个半区进行内存回收，需要分配内存时不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

不足是：将内存缩小为了原来的一般，代价偏高。同时，在对象存活率较高时就需要进行比较多的复制操作，效率就会变低。

关于该算法，还有一些补充说明：

现在的虚拟机一般采用复制算法来回收新生代，HotSpot中内存划分方式是：将内存分为一块较大的 Eden空间和两块较小的 Survivor空间，每次使用 Eden 和其中一块 Survivor空间。当回收时，将 Eden和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理掉 Eden 和刚才使用过的 Survivor空间。默认情况下，Eden空间和 Survivor空间的大小比为：8 : 1。也就是每次新生代中可用内存空间是整个新声代的 90%。

如果某次回收后有多于 10%内存空间的对象存活，Survivor空间的内存不够用时，就需要老年代进行分配担保。存放不下的对象，将会通过分配担保机制直接进入老年代。

3、标记-整理算法

复制收集算法在对象存活率较高时需要进行比较多的复制操作，效率就会变低。更关键的是，我们需要有额外的空间进行分配担保，以应对内存中所有的对象100%都存活的极端情况，所以在老年代不能直接选用复制收集算法。

根据老年代的特点，有人提出了“标记-整理”（Mark-Compact）算法。

算法的基本思想是：首先标记出需要回收的对象，标记过程与“标记-清除”算法一样，标记完成后，不直接对可回收的对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

4、分代收集算法

当前大多数虚拟机都采用“分代收集”（Generational Collection）算法。其实上面就已经提到了。

该算法的基本思想是：根据对象存活周期的不同，将内存划分为几块。一般是把Java对划分为新生代和老年代，然后根据各个代的特点采取不同的垃圾收集算法：

在新生代中，大量的对象都是“朝生夕死”的，声明周期很短，只有少量存活。这里就采用 复制算法，只需要复制出少量存活的对象就可以完成收集，成本很低。

在老年代中，对象存活率高，没有额外的空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

补充说明：

Minor GC：新生代GC，指发生在新生代的垃圾收集动作。因为Java对象大多都具备“朝生夕灭”的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。
Full GC：也叫做 Major GC，指的是老年代GC，发生在老年代的GC。出现了 Full GC，经常会伴随着至少一次的 Minor GC。Full GC一般会比 Minor GC慢10倍以上。

垃圾收集器

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。当我读到《Our Collectors》这篇文章的时候，仿照着文中的配图，结合着我对周老师书中的理解，也画了下面这幅图：

上图中的横线代表两个虚拟机可以“配合工作”。比如，当新生代我们使用 ParNew收集器时，那老年代我们只能选择 CMS收集器或者 Serial Old收集器。

1、Serial / Serial Old 收集器

Serial Old 收集器就是 Serial 收集器的老年代版本。在新生代使用标记-清除算法，在老年代使用标记-整理算法。下面就不多加区分两种收集器了。

Serial 收集器使用单线程完成垃圾收集工作，并且在其进行垃圾收集时会“Stop The World”，也就是会暂停其他工作线程，直到垃圾收集结束。其优点是：简单而高效，没有线程交互的开销，可以获得最高的单线程收集效率。

Serial 收集器主要面向的是运行在Client模式下的虚拟机，以及数据集较小的应用(大约100MB)。针对第二点，官方文档原文：

it can be useful on multiprocessors for applications with small data sets (up to approximately 100 MB).

Ps：

上面标注的 Serial Old 和 CMS 之间配合工作：Serial Old 可以作为CMS收集器的备用方案，当CMS收集器在并发收集中发生 Current Model Failure 时，此时就可以使用Serial Old 来完成垃圾收集工作。

2、ParNew 收集器

ParNew收集器就是 Serial收集器的多线程版本，两者也共用了相当一部分的代码。它使用多条线程进行垃圾收集。

ParNew收集器主要用于新生代的垃圾收集，使用复制算法。在垃圾收集时，也需要“Stop The World”。

ParNew收集器是运行在Server模式下的虚拟机首选的新生代垃圾收集器，除了其性能好，还有一个原因是，除了Serial收集器外，只有ParNew收集器能够和 CMS收集器配合工作。

Ps：

在周老师的书中，配图是：ParNew在新生代使用复制算法，在老年代使用标记-整理算法。对于这一点，我查阅了官方文档，以及Oracle博客中的一些博文，没有发现有任何地方明确说明了 ParNew用于收集老年代，以及在老年代使用的算法，只提到了ParNew收集器使用复制算法收集新生代。在《Our Collectors》中是这么描述的：

"ParNew" is a stop-the-world, copying collector which uses multiple GC threads.

"ParNew" (and "Serial") implements space_iterate() which will apply an operation to every object in the young generation.

3、Parallel Scavenge / Parallel Old 收集器

Parallel Scavenge收集器是一个新生代收集器，使用复制算法。Parallel Old收集器是 Parallel Scavenge收集器的老年代版本，使用标记-整理算法。该收集器是多线程收集器，并且其目标是为了达到一个可控制的吞吐量（Throughput）。

高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

4、CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

CMS收集器是基于“标记-清除”算法实现的，主要用于老年代的垃圾收集。整个标记过程分为4个步骤：

初始标记：需要“Stop The World”，仅仅只标记一下 GC Roots 能直接关联到的对象。
并发标记：进行 GC Roots Tracing 的过程，也就是找到所有能够与GC Roots直接或间接连接到的对象。耗时较长。
重新标记：需要“Stop The World”，用于修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录。
并发清除：不需要“Stop The World”，并发清理掉需要回收的对象。耗时较长。

CMS收集器的优点是并发收集，低停顿。同时，其缺点也很明显：

CMS收集器对CPU资源非常敏感。实际上，面向并发设计的程序都对CPU资源敏感。在并发标记阶段，用户线程虽然不会暂停，但是标记线程会占用CPU资源，用户程序就会变慢。
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生。当老年代使用到一定比率(JDK6中是 92%)时CMS收集器就会被激活，因为要预留一部分空间提供给并发收集时的程序运算使用。
CMS是基于“标记-清除”算法实现的虚拟机，这就意味着收集结束时会有大量的碎片产生。碎片太多时，就会给大对象的分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配给当前对象，而不得不提前触发一次 Full GC。

5、G1收集器

G1（Garbage First）收集器是一款面向服务端应用的收集器。根据HotSpot开发团队的描述，如果G1表现符合预期，它将成为“ParNew + CMS”组合的低延时替代收集器。G1收集器的特点是：

可预测的GC停顿
更高的GC工作效率
更低的Stop The World停顿时间，没有碎片
并发和并行性更好，能充分利用多CPU、多核环境下的硬件优势
更好的堆利用率

这个地方众说纷纭，我也不想再看了。有兴趣的同学，可以看看周老师对这里的描述，以及《Our Collectors》一文中的Question 4。

补充说明

上面介绍“标记-清除”算法时，没有详细说明标记流程。这里，先介绍一个GC Roots根结点的枚举，以及我自己对标记过程的理解。

Stop The World

在枚举根节点（从GC Roots 节点找到引用链）操作时，可达性分析工作必须在一个能确保“一致性”的快照中进行——这里的“一致性”是指：在整个分析期间，整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象的引用关系还在不断变化的情况，否则分析结果的准确性就无法得到保证。这就导致在GC进行时，JVM会暂停所有的Java执行线程，Sun官方将这一事件称为“Stop The World”，简写为 STW。

即使是在号称几乎不会停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

对象标记过程

首先说明：下面这一小部分内容是作者自己的理解，不一定正确。作者也是在不断学习之中，如果有大牛偶然路过，还望不吝赐教，感激不尽！

首先是周志明老师在《深入理解Java虚拟机》的第3章：3.2.4生存还是死亡 中写的：

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象的死亡，至少要经历两次标记过程①：如果对象在进行可达性分析后发现没有与GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 finalize() 方法②，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行 finalize() 方法③，这个对象将会被放置在一个叫做F-Queue 的队列④之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程⑤去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是如果一个对象的 finalize() 方法执行缓慢，或者发生了死循环，很有可能导致 F-Queue 队列中的其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize() 方法是对象逃脱死亡命运的最后一次机会，稍后GC 将对 F-Queue中的对象进行第二次小规模的标记，如果对象要在 finalize() 方法中成功拯救自己——只需要重新与引用链上的任何一个对象建立关联即可，譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合；如果对象这时候还没有与逃脱，那基本上它就真的(要)被回收了。

当我在看到这面这一段时，我就很疑惑：如上面①处所说：“至少要经历两次标记过程”。而后文提到，只有在这个对象被判定为有必要执行 finalize() 方法的时候，才会被触发第二次标记。那岂不是和作者所说的“至少要经历两次标记过程”矛盾了？

当我看完《Debugging to understand Finalizers》这篇文章的时候，我的理解是这样的：

当对象没有覆盖 finalize() 方法，或者对象的 finalize() 方法已经被调用过时，对象只会被标记一次，在 Minor GC 时便会被回收内存；

当对象对应的类重写了 finalize() 方法，JVM会针对每一个重写了 finalize() 方法的类的对象注册一个 java.lang.ref.Finalizer 类的实例，该 Finalizer 实例将会引用到这个对象（重写了 finalize()方法的类的对象）。而没有覆盖 finalize() 方法对象则不会有对应的 Finalizer 实例生成，也不会有后面的操作，将正常参与GC内存回收。

Finalizer类的实现类似一个双向链表，每个Finalizer实例结点都包含其前驱结点、后继结点的引用信息。也就是说，所有重写了 finalize() 方法的类的对象，在构造时，都会对应生成一个该对象专属的 Finalizer 实例，这些实例最终将成为一条 Finalzer链。

下面是 Finalizer类的部分源码：

final class Finalizer extends FinalReference<Object> {
    // 静态对象，所有的 Finalzer实例共享同一个队列
    private static ReferenceQueue<Object> queue = new ReferenceQueue<>();
    private static Finalizer unfinalized = null;
    private static final Object lock = new Object();

    // 其前驱结点、后继结点的引用信息
    private Finalizer next = null, prev = null;

    /**
     * 私有构造
     * 所有重写了的 finalize() 方法的类的对象，在构造时，都会通过下面的 finalizee 引用，
     * 额外生成一个该对象专属的 Finalizer 实例，这些示例最终将成为一条 Finalizer 链
     */
    private Finalizer(Object finalizee) {
        super(finalizee, queue);
        // 即下面的这个 add 方法
        add();
    }

    // 通过 add 方法，所有的 Finalizer 对象最终会构成一条链
    private void add() {
        synchronized (lock) {
            if (unfinalized != null) {
                this.next = unfinalized;
                unfinalized.prev = this;
            }
            unfinalized = this;
        }
    }
    // 此处省略其他代码
}

由于这些对象会被 Finalizer 类的实例引用，所以在接下来的这一次 GC 中，这些对象将不会被回收；当这次GC执行完成之后，JVM就能知道，除了这些 Finalizer实例，没有其他什么地方再引用到这些对象了。GC内部将会把这些 Finalizer实例添加到一个 java.lang.ref.ReferenceQueue<T> 队列中。这个添加到队列的操作，一定是在一次GC之后才会触发。

如上图，我写的一个测试用例。在System.gc()执行之前，我们在IDEA上找到 Memory 调试模块，点击 Load Classes，然后搜索 “final”这个关键字(如图)，就可以找到我标注的那个 java.lang.ref.Finalizer Class，我们双击它，就可以看到图中的弹窗。弹窗中我们可以得到三条信息以证明上面我的理解：

针对每一个重写了finalize()方法的类的对象，JVM会创建一个引用到该对象的Finalizer实例。如图中的蓝色框标记，Finalizer@785的 referent字段就引用了我的 FinalizeObj@471 对象。
所有的Finalzer实例都共享同一个 ReferenceQueue 队列。如图中的 ReferenceQueue@1207.
在一次GC之前，该ReferenceQueue 队列还为空，没有任何对象放入。

我们将断点打在 Finalize 类中的 FinalizerThread 类中的 run() 方法中，然后让代码继续执行，执行System.gc()方法后，并且让主线程休眠1秒。可以观察到如下图：

我们个给断点加上条件，条件就是筛选出引用了我写的 finalizeObj 的 Finalizer对象。然后我们可以观察到：在 queue.remove() 之前，引用覆盖了finalize() 方法的 FinalizeObj@471 这个对象的 Finalizer实例 Finalizer@785 已经被添加到了 ReferenceQueue@1207 这个队列中。在从队列中拿到Finalizer@785实例时，该实例引用的队列变为了一个NULL队列（实际上该队列是ReferenceQueue.NULL，类似于 Collections.emptyList() 返回的空List一样）。

此时 Finalizer@785 实例仍然是引用了 FinalizeObj@471 这个对象的。下面我们看看 f.runFinalizer(jla) 到底执行了什么：

private void runFinalizer(JavaLangAccess jla) {
    synchronized (this) {
        if (hasBeenFinalized()) return;
        remove();
    }
    try {
        Object finalizee = this.get();
        if (finalizee != null && !(finalizee instanceof java.lang.Enum)) {
            jla.invokeFinalize(finalizee);
            /* Clear stack slot containing this variable, to decrease
               the chances of false retention with a conservative GC.
              注意下面行代码，改变了 Finalizer 引用的 FinalizeObj 的指针指向
              将 finalizee 指向null，而不是指向 FinalizeObj。
              这样，FinalizeObj就没有任何地方引用了！将正常参与GC垃圾回收 */
            finalizee = null;
        }
    } catch (Throwable x) { }
    super.clear();
}

上面 finalizee = null 这一行执行完毕， Finalizer@785 实例将不再引用 FinalizeObj@471 这个对象。当下一次GC来临时，FinalizeObj@471 这个对象将会被回收。

还需要补充的是，上面断点我们打在了 FinalizerThread 这个类中。下面是该类的构造方法：

FinalizerThread(ThreadGroup g) {
    super(g, "Finalizer");
}

这个方法很简单，初始化一个名为“Finalizer”的线程。我们在Finalizer类代码末尾(不同的JDK版本可能位置不同，我的是JDK8)，可以看到有一个静态块：

static {
    ThreadGroup tg = Thread.currentThread().getThreadGroup();
    for (ThreadGroup tgn = tg;
         tgn != null;
         tg = tgn, tgn = tg.getParent());
    Thread finalizer = new FinalizerThread(tg);
    // 线程优先级比主线程低
    finalizer.setPriority(Thread.MAX_PRIORITY - 2);
    // 守护线程
    finalizer.setDaemon(true);
    finalizer.start();
}

当 Finalizer 这个类加载的时候，就会启动一个优先级略低的守护线程，名为“Finalizer”。实际上，我们通过 Jps、Jstack 命令可以发现这个名为“Finalizer”的守护线程。

这个线程优先级比主线程低，从 FinalizerThread 源码中的 run() 方法可以看出，该线程只做一件事情：这个线程一直循环，每档它发现有新的 Finalizer实例出现在 ReferenceQueue 这个队列中时，就将该Finalizer实例从队列中弹出，并且得到其引用的重写了 finalize() 方法的对象，然后执行该对象的 finalize() 方法，并且移除掉Finalizer实例对该对象的引用。此时，该对象将会被标记为不可达。因此，当下一次GC来临时，该对象就会被回收内存。

理解了上面的这些内容后，我们再看上面引用的周老师的内容中，我的标注：

①：至少要经历两次标注过程，我觉得描述的有问题。如果对象没有覆盖 finalize() 方法，只会被标记一次，就等待被回收。
④：F-Queue：即上面的 java.lang.ref.ReferenceQueue<T> 队列，并且放入其中的也不是重写了 finalize() 方法的对象，而是引用了该对象的对应的 Finalizer 实例。
⑤：虚拟机自动建立的、低优先级的 Finalizer 线程，即上面提到的名为 “Finalizer”的低优先级线程。

总结

本文主要分为两部分：第一部分是根据周志明老师的《深入理解Java虚拟机》总结了一下JVM的GC机制，第二部分是自己根据自己的理解，结合源码分析，总结了一下对象死亡判定时的标记过程。现在获取知识的途径有很多，获取的知识也很杂。不同的人会有不同的看法。你一搜“JVM”这个关键词，网上99%的内容都是搬运的周老师书中的内容，本文也不例外，也搬运的有。所以，在更多的时候，我们对知识，要有自己的思考，而不是死记硬背。希望和大家一起进步~

参考文档

1、《深入理解Java虚拟机》第三版，周志明著，第三章

2、JDK finalize() 方法的注释文档

3、https://bbs.csdn.net/topics/392309703

4、https://stackoverflow.com/questions/2506488/when-is-the-finalize-method-called-in-java

5、https://plumbr.io/blog/garbage-collection/debugging-to-understand-finalizer

6、https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html

7、https://dzone.com/articles/garbage-collectors-serial-vs-0

8、https://blogs.oracle.com/jonthecollector/our-collectors

怕乌龟骑

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
JVM学习笔记(二)：JVM GC机制与垃圾收集器

引子在上一篇文章《JVM学习笔记(一)：Java内存区域》中，我总结了一下几大Java内存区域。接下来，我总结一下JVM的GC机制，以及垃圾收集算法和垃圾收集器。内存回收区域谈起JVM的GC机制，我们首先需要关注的就是：回收哪儿的内存？如何判断哪些内存需要被回收？怎么回收？下面就一一解答这些问题。在上一篇文章中提到的程序计数器、虚拟机栈、本地方法栈三个“线程私有”的区域，随...
复制链接

扫一扫