java垃圾回收

本文主要总结垃圾回收机制、垃圾回收器以及相关内存分配策略等知识点，用于深入理解java虚拟机在处理内存垃圾上的应用。

java垃圾回收机制

垃圾回收主要关注的是java堆里面的对象回收。下图引用 czwbig关于虚拟机垃圾回收只是的博客，地址如下https://www.cnblogs.com/czwbig/p/11127159.html

java内存运行区域中的程序计数器、虚拟机栈、本地方法栈随线程的生存周期而生存，所以是线程私有的。而堆区和栈区是线程线程共有的。每一个栈帧中分配多少内存是在类的结构确定下来就已经知道的，因此这个区域的内存分配和回收具备确定性，不需要过多考虑回收的问题，因为方法结束或者线程结束时内存就自然跟着回收了。而java堆不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

判断哪些对象需要被回收

有以下2中方法：

1、引用计数法

给对象添加引用计数器，被引用一次计数器值就加1，当引用失效时计数器就减1；当计数器为0的时候，对象就是不可能被使用的，此时垃圾回收器就可以将该对象回收。 缺点无法解决对象之间循环应用的问题。例如：

public void buidDog(){
		Dog newDog = new Dog();
		Tail newTail = new Tail();
		newDog.tail = newTail;
		newTail.dog = newDog;
}

2、可达性分析算法

通过一系列称为“GC ROOTS”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。此算法解决了上述循环引用的问题。

在java语言中，可以作为“GC ROOTS”的对象主要有以下几个：

1、虚拟机栈（栈帧中的本地变量表）中引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中（native）方法引用的对象

作为 GC Roots 的节点主要在全局性的引用与执行上下文中。要明确的是，tracing gc必须以当前存活的对象集为 Roots，因此必须选取确定存活的引用类型对象。

GC 管理的区域是 Java 堆，虚拟机栈、方法区和本地方法栈不被 GC 所管理，因此选用这些区域内引用的对象作为 GC Roots，是不会被 GC 所回收的。

其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此，也可能是 GC roots 的一部分。

强、软、弱、虚引用

JDK1.2 以前，一个对象只有被引用和没有被引用两种状态。后来，Java 对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4 种，这 4 种引用强度依次逐渐减弱。

强引用：

强引用就是指在程序代码中普遍存在的，类似于"Object obj=new Object()"这类的引用，垃圾收集器永远不会回收存活的强引用对象。

软引用：

还有用但是非必须的对象，在系统将要发生内存溢出之前，将会把这些对象列进回收范围之内进行第二次回收。

弱应用

弱引用也是用来描述非必须的对象的，不同的是被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论内存是否足够均会收集该对象。

虚引用

虚引用是最弱的一种引用关系。无法通过虚引用来取得一个对象实例，为一个对象设置虚引用的唯一目的就是能在这个歌对象被回收集器回收时收到一个系统通知。

可达性分析算法

不可达的对象将暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历2次标记：

1、如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。
2、当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，直接进行第二次标记。
3、如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。

这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，因为如果一个对象在 finalize() 方法中执行缓慢，将很可能会一直阻塞 F-Queue 队列，甚至导致整个内存回收系统崩溃。

测试如下：

public class FinalizerTest {
    public static FinalizerTest object;
    public void isAlive() {
        System.out.println("I'm alive");
    }
 
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("method finalize is running");
        object = this;
    }
 
    public static void main(String[] args) throws Exception {
        object = new FinalizerTest();
        // 第一次执行，finalize方法会自救
        object = null;
        System.gc();
 
        Thread.sleep(500);
        if (object != null) {
            object.isAlive();
        } else {
            System.out.println("I'm dead");
        }
 
        // 第二次执行，finalize方法已经执行过
        object = null;
        System.gc();
 
        Thread.sleep(500);
        if (object != null) {
            object.isAlive();
        } else {
            System.out.println("I'm dead");
        }
    }
}

输出如下：

method finalize is running
I'm alive
I'm dead

如果不重写 finalize()，输出将会是：

I'm dead
I'm dead

从执行结果可以看出：
第一次发生 GC 时，finalize() 方法的确执行了，并且在被回收之前成功逃脱；
第二次发生 GC 时，由于 finalize() 方法只会被 JVM 调用一次，object 被回收。
值得注意的是，使用 finalize() 方法来“拯救”对象是不值得提倡的，它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。finalize() 能做的工作，使用 try-finally 或者其它方法都更适合、及时。

java堆永久代的回收

永久代指内存的永久保存的区域，主要存放class和元数据信息。class在被加载的时候元数据信息会被放入永久区域，但是GC不会主动在主程序运行的时候清除永久代信息。所以这也导致永久代的信息会随着类加载的增多而膨胀，最终导致OOM。

注意: 在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。

永久代的垃圾回收主要回收：废弃常量和无用的类。

回收废弃常量与回收 Java 堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串"abc"已经进入了常量池中，但是当前系统没有任何一个 String 对象是叫做"abc"的，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个"abc"常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

但是类需要同时满足下面 3 个条件才能算是“无用的类”：

1、该类的所有实例已经被回收，也就是java堆中不存在该类的任何实例。
2、加载该类的ClassLoader已经被回收。
3、该类对应的java.lang.class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样，不使用了就必然会回收。

在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

垃圾收集算法

一共有4中垃圾回收算法：
1、标记-清理算法
2、复制算法
3、标记-整理算法
4、分代收集算法

标记-清除算法

最基础的收集算法是标记-清除算法，分为标记和清除2个阶段，首先标记处所有需要回收的对象，在标记完成后统一回收所有标记的对象。

缺点：
1、效率问题，标记和清理2个过程效率都不高
2、空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配较大的对象时，无法找到合适的内存空间

算法执行过程如下：

复制算法

为了解决上面的效率问题，一种“复制”算法出现了，它将可用内存按容量划分为大小相等的2块。每次只是用其中的一块，当这一块使用完了后就将活着的对象复制到另外一块上面，然后再把已经使用过的内存空间一次清理掉。

这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。复制算法的执行过程如下图：

现在的商业虚拟机都采用这种算法来回收新生代，IBM 研究指出新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor 。

当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。HotSpot 虚拟机默认 Eden:Survivor = 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（其中一块Survivor不可用），只有 10% 的内存会被“浪费”。

当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

内存的分配担保就好比我们去银行借款，如果我们信誉很好，在 98% 的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。

内存的分配担保也一样，如果另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。关于对新生代进行分配担保的内容，在本章稍后在讲解垃圾收集器执行规则时还会再详细讲解。

标记-整理算法

复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用这种算法。

根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如下：

分代收集

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期的不同将内存划分为几块并采用不用的垃圾收集算法。

一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。