JVM的GC-CSDN博客

本文链接：https://blog.csdn.net/richard331/article/details/89488409

垃圾收集（Garbage Collection， GC）

虚拟机中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出有条不紊地执行着出栈和入栈操作。-----------（这几个区域的内存分配和回收都具备确定性，在这个几个区域内就不需要过多考虑回收的问题，因为方法结束或线程结束，内存自然就跟随着回收了）

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

判断对象是否还存活

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

public class ReferenceCountingGC {

    public Object instance = null;

    private static final int _1MB = 1024 * 1024;

    private byte[] bigSize = new byte[2 * _1MB];

    public static void testGC() {
        ReferenceCountingGC objectA = new ReferenceCountingGC();
        ReferenceCountingGC objectB = new ReferenceCountingGC();
        objectA.instance = objectB;
        objectB.instance = objectA;

        objectA = null;
        objectB = null;

		//发送GC后，回收objectA和objectB
        System.gc();
    }

    public static void main(String[] args) {
        ReferenceCountingGC.testGC();
    }

}

这里对象被回收了，说明两个相互引用的对象也被回收了，说明虚拟机并不是通过引用计数器来判断对象是否存活。

可达性分析算法（Reachability Analysis）
主流的商业程序语言Java、C#的主流实现都是通过可达性分析来判断对象是否存活。
算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时（达不到），则证明此对象是不可用的。
在这里插入图片描述
在图中，Object5和Object6达不到GC Roots，所以它们将会被判定为可回收的对象。
在Java语言中，可作为GC Roots的对象包括下面的几种

虚拟机栈（栈帧中的本地变量表）中引用对象
方法区中类静态属性引用对象
方法区中常量引用的对象
本地方法栈中JNI（即一般来说的Native方法）引用对象

引用

在JDK1.2后，Java对引用的概念进行扩充，将引用分为四类：强引用(Strong Reference)、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference），这四类引用类型强度逐渐减弱。

强引用就是指程序代码之中普遍存在的，类似于“Object objet = new Object（）”这类的引用，只要强引用还在，垃圾收集器永远不会回收掉引用的对象。
软引用是用来描述一些还有用但非必要的对象。对于软引用管理的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收访问之中进行第二次回收。如果这次回收没有回收到足够1内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被软引用管理的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。JDK1.2之后，提供了WeakReference类来实现弱引用。
虚引用也称为幽灵引用或幻影引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为了一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供PhantomReference类来实现弱引用。

判定对象死亡

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

···
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 InterruptedException {
    SAVE_HOOK = new FinalizeEscapeGC();

    //对象第一成功拯救自己
    SAVE_HOOK = null;
    System.gc();

    //因为finalize方法优先级很低，所以暂停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();
    //因为finalize方法优先级很低，所以暂停0.5秒
    Thread.sleep(500);
    if (SAVE_HOOK != null) {
        SAVE_HOOK.isAlive();
    } else {
        System.out.println("no, i am dead: )");
    }

}

}

在这里插入图片描述
从运行结果来看，SAVE_HOOK对象的finalize()方法确实被GC收集器触发过，并且在被收集前成功逃脱了。

另外值得注意的地方是，代码中两端完全一样的代码片段，执行结果确实一次逃脱成功，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，一次第二段代码的自救就失败了。

FinalizeEscapeGC.SAVE_HOOK = this;

这段代码注释掉以后，运行结果为：
在这里插入图片描述

垃圾回收算法

标记-清除算法（Mark-Sweep）

标记-回收算法如同字面一样，分为两个阶段：首先标记处所有需要回收的对象，在标记完成用户统一回收（标记方法有：引用计数器和可达性分析算法）。

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

复制算法（Copying）

将内存分为两部分，每次只是用其中的一块。当前这一块内存用完了，就将还存活着的对象复制到另一块上，然后再把已经使用的内存空间进行清除。
这样使得每次都是整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要一动堆顶指针，按顺序分配内存即可，实现简单，运行高效。
在

标记-整理算法（Mark-Compact）
标记-整理算法，标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，二是让所有存活的对象都向另一端一动，然后直接清理掉端边界以外的内存。
现在的商业虚拟机都采用这种收集算法来回收新生代。
新生代可分为：Eden、From Survivor、To Survivor三块区域，比例为8:1:1。当回收的时候，将Eden和Fron Surivor中还存活这的对象一次性复制到另一块To Survivor空间上，最后处理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机和Survivor的大小比例是8:1。新生代中可用的内存为90%，当需要复制到另一块的Survivor空间不够用时，需要老年代区域进行分配。
分代算法(Generational Collection)
分代算法根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老生代，这样就可以根据各个年代的特点采用最合适的收集算法。在新生代中，每次垃圾收集都发现有大批量的对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。老年代因为对象存活率该、没有额外的框架对它进行分配担保，就必须要使用"标记——清理"或者“标记——整理”算法来进行回收。