JVM——GC

JVM(Java Virtual Machine)，Java虚拟机，通过软件模拟Java字节码的指令集，JVM只是保留了PC寄存器，其它的寄存器都进行了裁剪。JVM是一台被定制过的现实当中不存在的计算机。

1、Java内存区域划分

一般来说，JVM所管理的内存包含以下几个运行时数据区域：

• 线程私有区域：

  • -程序计数器：记录当前线程正在执行的字节码行号指示器（通俗的说就是当前线程跑到哪一行代码），当线程重复调度就知道从哪恢复执行。
  • 虚拟机栈：与方法有关，描述的是Java方法的执行模型，每个方法的调用与执行完毕对应一个栈帧在栈里边的入栈和出栈。

  此区域会产生两种异常：
  1）如果线程请求的栈深度大于虚拟机所允许的深度(Xss 设置栈的深度)，将会抛出StackOverFlowError异常。
  2）虚拟机在动态扩展时无法申请到足够的内存，会抛出OutOfMemoryError异常。

  • 本地方法栈：本地方法
    与虚拟机栈的作用完全一样，区别是本地方法栈为虚拟机使用的Native方法服务，而虚拟机栈为JVM执行的Java方法服务。

• 线程共享区域：

  • 堆:数组元素和对象

  Java堆是JVM所管理的最大内存区域，是垃圾回收管理的主要区域，因此也可以称为“GC堆”。Java堆可以处于物理上不连续的内存空间中。
  Java堆在主流虚拟机中可以扩展：
  １）Xms设置堆的最小值
  ２）Xmx设置堆的最大值
  ３）Xmn设置新生代内存大小

  • 方法区:已加载的类信息、常量与静态变量
    此区域的内存回收主要是针对常量池的回收以及对类型的卸载。

  • 运行时常量池：方法区的一部分，存放符号引用与字面量
    符号引用：不同包下都有一个Person类，通过包名.类名调用就是符号引用
    字面量：字符串、final常量、基本数据类型的值，比如10，“abc"这种直接写出来的

2、Java内存溢出异常

2.1 堆溢出

Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免来GC清除这些对象，那么在对象数量达到大堆容量后就会产生内存溢出异常。

内存泄漏：
泄露对象无法被GC
内存溢出：
内存对象确实还应该存活，此时要根据JVM堆参数与物理内存相比较检查是否还应该把JVM堆内存调大，或者检查对象的生命周期是否过长。

2.2 虚拟机栈和本地方法栈溢出

由于我们HotSpot虚拟机将虚拟机栈与本地方法栈合二为一，因此对于HotSpot来说，栈容量只需要由-Xss参数来设置。
关于虚拟机栈会产生的两种异常:

• 如果线程请求的栈深度大于虚拟机所允许的大深度，会抛出StackOverFlow异常
• 如果虚拟机在拓展栈时无法申请到足够的内存空间，则会抛出OOM异常

3、GC

本部分关注3个内容：
如何判断对象是否存活? -> 缓刑阶段(finalize()) -> 如何进行垃圾回收(GC算法)

3.1 判断对象是否存活？

• 引用计数器（无法解决循环引用问题）
  每当有一个地方引用这个变量，计数器加1，每当有一个地方不再引用这个变量，也就是为null，计数器减1，任意时刻当计数器为0时表示不再存活。

• 可达性分析算法（Java采用）
  通过一系列称为GC roots的对象作为起始点，从这些节点开始向下寻找，若从GC roots到对象有路可走（这个路叫引用链），也就是可达，认为对象存活，如果没有路可走，也就是不可达，认为对象不再存活。

3.1.1 哪些对象可以作为GC Roots？

• 虚拟机栈中引用的对象
• 本地方法栈中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象

3.1.2 JDK1.2 关于引用的扩充

• 强引用：Person per = new Person();只要对象被任意一个强引用指向，无论是否发生内存溢出(OOM),都不能回收被强引用指向的对象。

• 软引用：SoftReference类描述软引用。若对象只被软引用指向，当内存够用时不回收此对象，当内存不够用(即将抛出OOM)时，会回收掉所有仅被软引用指向的对象。
  软引用的对象为有用但不必须对象(如缓存对象)

• 弱引用：WeakReference类描述弱引用。若对象只被弱引用指向，当下次GC开始时，无论内存是否够用，都会回收掉只被弱引用指向的对象

• 虚引用：PhatomReference类描述虚引用。虚引用不对生存周期产生任何影响，也无法通过虚引用取得一个对象。被虚引用指向的对象在进行GC之前会受到一个回收信息。

3.2 对象的缓刑阶段-finalize()

即使在可达性分析算法中不可达的对象也并非“非死不可”，这时它们处于缓刑阶段。要宣告一个对象的真正死亡，至少要经过两次标记过程。
当一个对象被标记为不可达时，GC线程在回收时：

• 若此对象所在的类没有覆写finalize()，则认为此对象不再存活，可以回收
• 若此对象所在的类覆写了finalize()
  • 且未被JVM调用，由JVM调用finalize() …
  • 已被JVM调用，认为此对象不再存活

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个叫做F-Queue的队列之中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它（这里所说的执行指的是虚拟机会触发finalize() 方法）。finalize()方法是对象逃脱死亡的后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如 果对象在finalize()中成功拯救自己(只需要重新与引用链上的任何一个对象建立起关联关系即可)，那在第二次标记 时它将会被移除出"即将回收"的集合；如果对象这时候还是没有逃脱，那基本上它就是真的被回收了。

观察对象的自我拯救：

public class GCTest {
    public static GCTest test;

    public void isAlive() {
        System.out.println("I am alive!");
    }

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

    public static void main(String[] args) throws InterruptedException {
        test = new GCTest();
        test = null;
        System.gc();
        Thread.sleep(1000);
        if (test != null) {
            test.isAlive();
        } else {
            System.out.println("NO,I am dead!");
        }

        test = null;
        System.gc();
        Thread.sleep(500);
        if (test != null) {
            test.isAlive();
        } else {
            System.out.println("NO,I am dead!");
        }

    }
}

观察运行结果可以发现，finalize方法确实被JVM触发，并且对象在被回收前成功逃脱。但是从结果也可以看出，两个完全一样的代码段，结果一次逃脱成功，一次逃脱失败。
这是因为，任何一个对象的finalize方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又面临回收，它的finalize方法不会被再次执行，因此第二次自救失败。

3.2.1 回收方法区

方法区的垃圾回收主要分为两部分：废弃常量和无用的类

• 回收废弃常量和回收Java堆中的对象非常相似。以常量池中的字面量为例，假如一个字符串“abc”已经进入了常量池，但是当前系统没有任何一个String对象引用常量池的“abc”常量，也没有其他地方引用这个字面量，如果此时发生GC并且有必要的话，这个“abc”常量会被系统清理出常量池。
• 判定一个类是否是“无用的类”需要同时满足三个条件：
  • 该类所有实例都已经回收（即在Java堆中不存在任何该类的实例）
  • 加载该类的ClassLoader已经被回收
  • 该类对应的Class对象没有在任何其它地方被引用，无法在任何地方通过反射访问该类的方法

区别final finally finalize

• final：终结器，常量，不可变类，无法被覆写的方法
• finally：保证重点代码一定被执行，在异常体系中。
• finalize：JVM垃圾是否存活

考点：return的值

public class Test {
    public static void main(String[] args) {
        System.out.println(test()); //3
    }

    public static int test() {
        int i = 0;
        try {
            i = 1;
            return i;
        } catch (Exception e) {
            i = 2;
            return i;
        } finally {
            i = 3;
            return i;
        }
    }
}

上面程序执行结果为3，说明如果finally里存在return语句，即便try,catch中存在return语句，也会在return之前执行finally代码块。

public class Test {
    public static void main(String[] args) {
        System.out.println(test()); //1
    }

    public static int test() {
        int i = 0;
        try {
            i = 1;
            return i;
        } catch (Exception e) {
            i = 2;
            return i;
        } finally {
            i = 3;
        }
    }
}

这个与之前程序的区别是finally块中没有return语句了，这次返回的结果为1，但是明明i的值已经修改过，为什么还是返回1呢，原来，当try catch块中有return语句时，return语句会暂存变量值，然后执行finally代码块，最后打印的是暂存的值。

public class ExceptionTest {
    int age;

    public static void main(String[] args) {
        System.out.println(test().age); //30
        //引用类型，指向同一块堆空间，只new一次
    }

    public static ExceptionTest test() {
        ExceptionTest test = new ExceptionTest();
        try {
            test.age = 10;
            return test;
        } catch (Exception e) {
            test.age = 20;
            return test;
        } finally {
            test.age = 30;
        }
    }
}

这个程序中finally块中也没有return，为什么打印出的结果却是30呢，按照上面那个程序的思路，应该打印10才对，这是因为在这个程序中采用了引用类型，指向同一块堆空间，并且只new一次，所以返回修改后的值。如果在finally块中重新new一个ExceptionTest对象，返回的就是10。

3.3 GC算法

堆分为新生代与老年代。
新生代：对象存活率非常低
老年代：对象存活率较高

3.3.1 标记-清除算法

标记-清除算法就是首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
缺点：
1）效率问题：标记和清除两个过程效率都不高
2）空间问题：标记清除后会产生大量不连续的内存碎片，可能导致以后在程序运行过程中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另一次垃圾收集。

3.3.2 复制算法（新生代回收算法）

"复制"算法是为了解决"标记-清理"的效率问题。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一 块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另一块上面，然后再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配时也就不需要考虑内存碎片等复杂 情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运行高效。

将新生代分为一块较大Eden区和两块较小的Survivor区(From区和To区),每次使用Eden和其中一块Survivor。
Eden:Survivor = 8:1:1

3.3.3 标记-整理算法（老年代回收算法）

复制收集算法在对象存活率较高时会进行比较多的复制操作，效率会变低。因此在老年代一般不能使用复制算法。
针对老年代的特点，提出了一种称之为"标记-整理算法"。标记过程仍与"标记-清除"过程一致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉端边界以外的内存。

为何老年代不采用复制算法:老年代的对象存活率较高，采用复制算法复制的开销很大，效率降低。

3.3.4 分代收集算法

当前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，这个算法根据对象存活周期的不同将内存划分为几块。
一般是把Java堆分为新生代和老年代。在新生代中，每次垃圾回收都有大批对象死去，只有少量存活，因此我们采用复制算法；而老年代中对象存活率高、没有额外空间对它进行分配担保，就必须采用 "标记-清理"或者"标记-整 理"算法。

面试题：Minor GC和Full GC有什么区别？

• Minor GC:发生在新生代的垃圾回收，采用复制算法，效率较高，发生频率较高
• Full GC(Major GC):发生在老年代的垃圾回收，采用标记-整理算法，速度一般比MinorGC慢10倍以上，发生频率较低。一般发生Full GC至少会伴随一次Minor GC。

如果存活对象大于From区、To区，需要老年代分配一些空间给它，所以有一个分配空间的策略，大对象直接进入老年代。老年代也有可能不够用，这时才会发生老年代的垃圾回收，概率很低。

4、内存分配与回收策略

4.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发生一次Minor GC 。

4.2 大对象直接进入老年代

所谓的大对象是指，需要大量连续空间的Java对象，典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来放置大对象。
虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的在于避免Eden区以及两个Survivor区之间发生大量的内存复制(新生代采用复制算法收集内存) 。

4.3 长期存活的对象将进入老年代

既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代中。
为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对象年龄设为1。对象在Survivor空间中每"熬过"一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

4.4 动态对象年龄判定

为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄 的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

4.5 空间分配担保

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间， 如果大于，则此次Minor GC是安全的；如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。 如果 HandlePromotionFailure=true，那么会继续检查老年代大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
上面提到了Minor GC依然会有风险，是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（ 极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。
取平均值仍然是一种概率性的事件，如果某次Minor GC后存活对象陡增，远高于平均值的话，必然导致担保失败，如果出现了分配担保失败，就只能在失败后重新发起一次Full GC。虽然存在发生这种情况的概率，但大部分时候都是能够成功分配担保的，这样就避免了过于频繁执行Full GC。