JVM内存模型

一些问题：描述运行时数据区、垃圾回收GC(GC时机，3类GC算法,GC ROOT有哪些)、说说4种引用类型、类的生命周期(类加载过程、类初始化时机、类卸载的条件...)

1.JVM内存模型

a.结构

    运行时数据区，执行引擎，本地库接口，本地方法库

b.详细说明'运行时数据区'

    5个子区域：方法区，虚拟机栈，本地方法栈，程序计数器，堆区；

    方法区：存放加载的类信息，常量，静态变量。

    堆区：主要存放对象实体，数组实体；GC工作的主要区域。实体的引用放栈区(虚拟机栈 || 本地方法栈 || 方法区常量 || 方法区静态变量)。

    虚拟机栈：存放栈帧(局部变量表，操作数栈，方法出口)；联想递归过程的现场要保留哪些信息。若线程请求的栈深度超过了JVM所允许的栈深度，抛StackOverflowError异常；如果内存不够，抛OutOfMemoryError 异常。

    本地方法栈：与虚拟机栈相似，不过存放的是native方法的栈帧。

    程序计数器：存放下一条要执行的指令的地址。

    运行时常量池：方法区的一部分；当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

 2.Java垃圾回收机制

a.System.gc()

    System类的静态方法，通过获取运行时类调用GC实现。

    public static void gc() {

        Runtime.getRuntime().gc();

    }

    每个Java应用程序都有一个Runtime类实例，该实例会被自动创建，代表该Java程序的运行环境；

    Runtime类使用单例设计模式，构造方法私有化。具体看源码，较简单。

    显示调用System.gc()提醒JVM进行垃圾回收，但JVM不保证立即执行垃圾回收。

b.判断对象已死的两种算法(引用计数，可达性分析)

    引用计数：当一个对象实体的引用计数为0（外部没有这个对象的引用，也无法再引用这个对象），认为该对象可被回收。

                     问题：无法解决循环引用问题。

    可达性分析：分别以“GC Roots”集合里面的对象为起点，进行图的搜索算法(对象A保存对象B的引用则可认为A存在一条到B的边)，若在搜索以GcRoots(i)为起点的搜索过程中该对象均不可达，则判定为垃圾。

    可作为GC Root的对象有4大类(很容易想)：

    1.虚拟机栈(栈帧中的本地变量表)中引用的对象或native方法栈中引用的对象；

    2.方法区中常量引用的对象或方法区中静态变量引用的对象。

c.jdk1.2之后对象的四种引用方式

    1.强引用(Strong Reference);宁可抛异常，也不进行回收。

    2.软引用(Soft Reference),通过SoftReference类实现；被软引用关联的对象当内存不够时，才会对该对象进行回收。比较适合用来做数据缓存，当内存不够就可以释放缓存。

    3.弱引用(Weak Reference),被弱引用关联的对象只能生存到下一次垃圾回收之前

    4.幽灵引用(影子引用，虚引用)，不会影响对象的生存时间，也无法通过虚引用取得一个对象实例(看源码，提供了get()方法，但返回值为null)。

    SoftReference与PhantomReference提供了get方法。SoftReference返回被引用对象的引用，PhantomReference返回null。

d.方法区的回收(常量池的回收 || 对类的卸载)

    1.假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。

    2.类卸载的3个必要条件，满足时也不一定会进行类卸载(非充分条件)：

          该类的所有实例都已经被回收，

          该类对应的Class实例没有被任何地方引用，

          加载该类的ClassLoader实例已经被回收。(一个实例可以拿到该类的Class实例(obj.getClass())，一个类的Class实例可以拿到加载该类的ClassLoader实例(clzaa.getClassLoader()))，因此，在说3时，首先是在1，2的基础上说的，不然逻辑上就死循环相互引用了。

3.内存分配与回收策略

    对象的内存分配，往大方向讲，就是在堆上分配 。主要分配在新生代的 Eden 区上，少数情况下也可能直接分配在老年代中。

   a.新生代GC（Minor GC）与老年代GC（Major GC/Full GC） ：

        1.大多数情况下，对象在新生代Eden区中分配。 当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。新生代有3个区，统计的角度看，新生代对象存活的时间一般较短，朝生夕死”，因此把新生代划分为一块较大的Eden区和两块较小的Survivor 区。要两块Survivor 区是便于使用'复制算法’;若Eden:Survivor :Survivor 为8:1:1，则实际可用空间为90%。当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

        2.大对象直接进入老年代，最典型的大对象就是那种很长的字符串以及数组 ；长期存活的对象也会通过一定策略转移到老年区。可以通过设置JVM的PretenureSizeThreshold参数来确定大对象的阈值。 

        3.对新生代的GC比较频繁，且速度较快；对老年代的GC一般伴随着一次或多次的Minor GC，因此Major GC也叫Full GC。Major GC较慢。

    b.Full GC触发的条件：

        1.调用System.gc()。建议 JVM 进行 Full GC，虽然只是建议而非一定，但很多情况下它会触发 Full GC，而是增加 Full GC 的频率。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存。可通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc()。

         2.老年代空间不足。大对象直接进入老年代、长期存活的对象转入老年代等。

       3.空间分配担保失败。使用复制算法的 Minor GC 当Survivor空间不够时需要老年代的内存空间作担保，如果出现了 HandlePromotionFailure 担保失败，则会触发 Full GC。

    c.4种垃圾收集算法：

        1.标记-清除算法。将需要回收的对象进行标记，然后清除。主要问题在于会产生大量碎片；之后的算法都是基于该算法进行改进。

        2.复制算法。将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。可以得到连续的未使用区，主要不足是只使用了一半的空间。

        3.标记-整理算法。让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存(还不错)。可以得到连续的未使用区。

        4.现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。一般将 Java 堆分为新生代和老年代。

1. 新生代(主要是Eden区)使用：复制算法。
2. 老年代使用：标记-清理 或者 标记-整理 算法。

4.JVM类加载机制

    a.类生命周期的7个阶段:加载、验证、准备、解析、初始化、使用、卸载。

    b.类的初始化时机(若没有加载，验证，准备，解析过，则都会随着发生)：

            1.使用new关键字实例化对象时、读取或设置一个类的静态字段时(被final修饰，编译时把结果放到常量池的静态字段除外)、调用一个类的静态方法时。

            2.初始化一个类时，若发现父类还没有初始化，则需要先触发父类的初始化。

            3.使用java.lang.reflect包对类进行反射调用时，若类没有初始化，则需要触发其初始化。

            4.JVM启动后，用户程序需要指定一个要执行的主类(即含main()方法的那个类)，JVM会先初始化这个主类。

            5.被动引用。通过子类引用父类的静态字段时，不会触发子类的初始化；通过数组定义类引用，不会触发类的初始化；常量在编译时期进入常量池，本质上并没有直接引用到定义常量的类，因此不会触发类的初始化。

    c.类加载阶段完成的工作:“加载"是"类加载"（Class Loading）过程的一个阶段,别混淆。

            1.通过一个类的全限定名来获取该定义该类的二进制字节流。

            2.将字节流所代表的静态存储结构转化为方法区的运行时数据结构。

            3.在内存中生成一个代表该类的Class对象，作为方法区这个类的各种数据的访问入口。

    d.类加载器：

        对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

    e.双亲委派模型：

        如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载，而是把这个请求委派给父类加载器，每一个层次的加载器都是如此，依次递归。因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成此加载请求（它搜索范围中没有找到所需类）时，子加载器才会尝试自己加载。

        使用双亲委派模型来组织类加载器之间的关系，使得 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object，它存放在 rt.jar 中，无论哪个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。相反，如果没有双亲委派模型，由各个类加载器自行加载的话，如果用户编写了一个称为java.lang.Object 的类，并放在程序的 ClassPath 中，那系统中将会出现多个不同的 Object 类，程序将变得一片混乱。如果开发者尝试编写一个与 rt.jar 类库中已有类重名的 Java 类，将会发现可以正常编译，但是永远无法被加载运行。

 

参：

 

深入理解Java虚拟机第二版

https://www.cnblogs.com/alias-blog/p/5793108.html

https://github.com/CyC2018/Interview-Notebook/blob/master/notes/JVM.md