文章目录

判断对象是否已死
- 经典垃圾收集器

垃圾回收（Garbage Collection，GC），就是通过垃圾收集器把内存中没用的对象清理掉。垃圾回收涉及到以下内容：

判断对象是否已死
选择垃圾收集算法
选择垃圾收集的时间
选择适当的垃圾收集器清理垃圾

针对于程序计数器、虚拟机栈、本地方法栈，因为他们是随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作，所以不需要过多考虑如何回收的问题，当方法结束或者线程结束时，内存自然就跟随着回收了。
而 Java堆，方法区：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也可能不一样，只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。

判断对象是否已死

在堆里面存放着 Java 世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”(“死去”即不可能再被任何途径使用的对象)了。主要是有如下算法来判断：

0.引用计数算法

在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一;当引用失效时，计数器值就减一;任何时刻计数器为零的对象就是不可能再被使用的。类似于C++中的智能指针，但是它确无法解决对象之间相互循环引用（C++是使用weak_ptr 解决的）。

1.可达性分析算法

算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”(Reference Chain)，如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。
在这里插入图片描述

哪些对象可以作为GC Roots？

Java内存区域

在虚拟机栈(栈帧中的本地变量表)中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
在方法区中常量引用的对象，譬如字符串常量池(String Table)里的引用。
在本地方法栈中JNI(即通常所说的Native方法)引用的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象(比如NullPointExcepiton、OutOfMemoryError)等，还有系统类加载器。
所有被同步锁(synchronized关键字)持有的对象。
反映Java虚拟机内部情况的JM XBean、JVM TI中注册的回调、本地代码缓存等。

2.引用

在JDK 1.2版之前，Java里面的引用是很传统的定义: 如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称该reference数据是代表某块内存、某个对象的引用。这种定义并没有什么不对，只是现在看来有些过于狭隘了，一个对象在这种定义下只有“被引用”或者“未被引用”两种状态，对于描述一些“食之无味，弃之可惜”的对象就显得无能为力。譬如我们希望能描述一类对象:当内存空间还足够时，能保留在内存之中，如果内存空间在进行垃圾收集后仍然非常紧张，那就可以抛弃这些对象——很多系统的缓存功能都符合这样的应用场景。
在JDK 1.2版之后，扩充了四种引用类型：

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

3.生存还是死亡之 finalize()方法（可与编程思想联动啦）

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记。
随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”

一次对象的自我拯救演示：

/**
 1. 此代码演示了两点:
 2. 1.对象可以在被GC时自我拯救。
 3. 2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次 * @author zzm
 */
public class FinalizeEscapeGC {
   
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
   
        System.out.println("yes, i am still alive :)");
    }

    @Override
    protected void finalize() throws Throwable {
   
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable {
   
        SAVE_HOOK = new FinalizeEscapeGC();
//对象第一次成功拯救自己
        SAVE_HOOK = null;
        System.gc();
// 因为Finalizer方法优先级很低，暂停0.5秒，以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
   
            SAVE_HOOK.isAlive();
        } else {
   
            System.out.println("no, i am dead :(");
        }
// 下面这段代码与上面的完全相同，但是这次自救却失败了

    }
}
//        SAVE_HOOK=null;
//        System.gc();
//        // 因为Finalizer方法优先级很低，暂停0.5秒，以等待它 Thread.sleep(500);
//        if(SAVE_HOOK!=null){
   
//        SAVE_HOOK.isAlive();}else{
   
//        System.out.println("no, i am dead :(");}

4.回收方法区

堆的一次垃圾回收可以回收掉70%至99%的内存空间。
方法区的垃圾收集主要回收两部分内容:废弃的常量和不再使用的类型。

举个常量池中字面量回收的例子，假如一个字符串“ java”曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是“ java”，换句话说，已经没有任何字符串对象引用常量池中的“ java”常量，且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收，而且垃圾收集器判断确有必要的话，这个“ java”常量就将会被系统清理出常量池。常量池中其他类(接口)、方法、字段的符号引用也与此类似。
判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:
1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例
2. 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的
3. ·该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

关于是否要对类型进行回收，HotSpot虚拟机提供了- Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClass-Loading、-XX: +TraceClassUnLoading查看类加载和卸载信息，其中-verbose:class和-XX:+TraceClassLoading可以在
Product版的虚拟机中使用，-XX:+TraceClassUnLoading参数需要FastDebug版[1]的虚拟机支持。

5.垃圾收集算法

5.1 分代收集理论

建立在两个分代假说之上:

弱分代假说(Weak Generational Hypothesis):绝大多数对象都是朝生夕灭的。
强分代假说(Strong Generational Hypothesis):熬过越多次垃圾收集过程的对象就越难以消亡。
在Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或者某些部分的区域 ——因而才有了“Minor GC”“Major GC”“Full GC”这样的回收类型的划分;也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法——因而发展出了**“标记-复制算法”“标记-清除算法”“标记-整理算法**”等针对性的垃圾收集算法。

5.2 标记-清除算法

算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。
但是有两个缺点：

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

5.3 标记-复制算法

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，1969年Fenichel提出了一种称为“半区复制”(Semispace Copying)的垃圾收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效，不过其缺陷也显而易见，这种复制回收算法的代价是将可用内存缩小为了原来的一半，空间浪费未免太多了一点。

Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的 Survivor空间,每次分配内存只使用Eden和其中一块Survivor。发生垃圾收集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。

5.4 标记-整理算法

方法与标记清除基本相同，但是他是一种移动式的方法，就是将所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。 移动需要时间，以及需要更新所有引用这些对象的地方，而且在移动的过程中程序是不可用的（这个和我们现在做的私有化一样）。不移动，那就是造成很多的内存锁片，需要类似于slab分配器之类的东西来进行内存管理。

不移动会导致内存分配和访问更加复杂和频繁，吞吐降低，但是 GC延迟很低
移动会导致 GC 过程更加复杂和频繁，延迟很大，但是吞吐提高。

6. HotSpot的算法细节实现（就是如何找到存活对象，以及如何进行垃圾回收的）

6.1根/GC roots节点枚举

固定可作为GC Roots的节点主要在全局性的引用(例如常量或类静态属性)与执行上下文(例如栈帧中的本地变量表)中，尽管目标明确，但查找过程要做到高效并非一件容易的事情，现在Java应用越做越庞大，光是方法区的大小就常有数百上千兆，里面的类、常量等更是恒河沙数，若要逐个检查以这里为起源的引用肯定得消耗不少时间。
Q：问什么从这些根节点开始呐？

枚举根节点时也是必须要停顿的
当用户线程停顿下来之后，其实并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得到哪些地方存放着对象引用的。在HotSpot 的解决方案里，是使用一组称为OopMap的数据结构来达到这个目的。一旦类加载动作完成的时候， HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译(见第11章)过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信息了，并不需要真正一个不漏地从方法区等GC Roots开始查找。

6.2 安全点

引用关系会发生变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间，这样垃圾收集伴随而来的空间成本就会变得无法忍受的高昂。
实际上HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置被称为安全点(Safep oint)

因此：是在安全点的时候，JVM进行的垃圾收集。

安全点的两个思考问题：

如何选择安全点？
如何在垃圾收集发生时让所有线程(这里其实不包括执行JNI调用的线程)都跑到最近的安全点，然后停顿下来。
答：

安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准 进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。
第二个问题有两种解决解决方案：（1）抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。（2）主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的。

6.3 安全区域

如何确定安全区域？为什么会这样检查虚拟机？收到的信号是什么？从哪里来？
在这里插入图片描述

6.4 记忆集与卡表

记忆集：只需在新生代上建立一个全局的数据结构(该结构被称为“记忆集”，Remembered Set)，这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。

收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。因此有了下面的这些记录精度：

字长精度:每个记录精确到一个机器字长(就是处理器的寻址位数，如常见的32位或64位，这个精度决定了机器访问物理内存地址的指针长度)，该字包含跨代指针。
对象精度:每个记录精确到一个对象，该对象里有字段含有跨代指针。
卡精度（卡表）:每个记录精确到一块内存区域，该区域内有对象含有跨代指针。

卡表最简单的形式可以只是一个字节数组，而HotSpot虚拟机确实也是这样做的。
字节数组 CARD_TABLE 的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”(Card Page)。一般来说，卡页大小都是以2的N次幂的字节数。
一个卡页的内存中通常包含不止一个对象，只要卡页内有一个(或更多)对象的字段存在着跨代指针，那就将对应卡表的数组元素的值标识为1，称为这个元素变脏(Dirty)，没有则标识为0。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它们加入GC Roots中一并扫描。

6.5 写屏障（如何维护卡表?何时变脏？谁让他变脏）

何时变脏：有其他分代区域中对象引用了本区域对象时，其对应的卡表元素就应该变脏，变脏时间点原则上应该发生在引用类型字段赋值的那一刻。
如何变脏：如果是解释执行的字节码，JVM介入处理。如果是编译执行的场景，那就使用写屏障(Write Barrier)技术维护卡表状态。写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形(Around)通知，供程序执行额外的动作，也就是说赋值的前后都在写屏障的覆盖范畴内。在赋值前的部分的写屏障叫作写前屏障(Pre-Write Barrier)，在赋值后的则叫作写后屏障(Post-Write Barrier)。

// 写后屏障更新卡表
void oop_field_store(oop* field, oop new_value) {
    // 引用字段赋值操作
*field = new_value;
// 写后屏障，在这里完成卡表状态更新 post_write_barrier(field, new_value);
}

伪共享问题：其实就是缓存行冲突的问题。具体见书吧。

6.6 并发的可达性分析

在根节点枚举这个步骤中，由于GC Roots相比起整个Java堆中全部的对象毕竟还算是极少数，且在各种优化技巧(如OopMap)的加持下，它带来的停顿已经是非常短暂且相对固定(不随堆容量而增长)的了。可从GC Roots再继续往下遍历对象图进行标记，这一步骤的停顿时间就必定会与Java堆容量直接成正比例关系了:堆越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长。

必须在一个能保障一致性的快照上才能进行对象图的遍历。因为可能存在把原本存活的对象错误标记为已消亡的情况。类似于Java中的并发编程而已。

白色:表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是
白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

·黑色:表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接(不经过灰色对象)指向某个白色对象。

灰色:表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

产生的原因：

赋值器插入了一条或多条从黑色对象到白色对象的新引用;
·赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

如何解决呐？增量更新(Incremental Update)和原始快照(Snapshot At The Beginning， SAT B ) 。

增量更新：将变化记录下来，进行重放
原始快照：无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照来进行搜索。

经典垃圾收集器

经典垃圾收集器以及ZGC实践