JVM虚拟机、类加载

JVM虚拟机

概念：JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

JVM 分为堆区和栈区，还有方法区，初始化的对象放在堆里面，引用放在栈里面，class 类信息常量池（static 常量和 static 变量）等放在方法区

JDK1.7内存模型

JDK1.8内存模型

JVM的分区可以分为两种：线程私有的内存区和线程共享的内存区

线程私有的内存区域

程序计数器：

一块比较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。

Java虚拟机栈：

• 和线程相关，不同线程内，即时运行同一个方法，也是处于不同内存
• .和方法有关，即时是同一一个线程,递归调用某个方法，每次调用都会生成该次方法调用的方法栈

每个方法执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。局部变量表存放的是 8 大基础类型加上一个应用类型，所以还是一个指向地址的指针

每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机栈中入栈和出栈的过程。

此区域一共会产生以下两种异常:

1. 如果线程请求的栈深度大于虚拟机所允许的深度(-Xss设置栈容量)，将会抛StackOverFlowError异常。（方法调用太深，比如递归，每次调用都是一次入栈，入栈的数量太多，就抛出这个异常）
2. 虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM(OutOfMemoryError)异常（内存溢出：线程调用方法，创建方法该次调用的栈帧，内存不足抛出OOM）

本地方法栈：

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

线程共享区域

Java堆：

1. 在JVM启动时创建，所有的对象实例以及数组都要在堆上分配。
2. 如果在堆中没有足够的内存完成实例分配并且堆也无法再拓展时，将会抛出OOM。

方法区/元数据区

用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

此区域的内存回收主要是针对常量池的回收以及对类型的卸载。当方法区无法满足内存分配需求时，将抛出OOM异常。

运行时常量池

编译期及运行期间产生的常量被放在运行时常量池中。

这里所说的常量包括：基本类型、包装类（包装类不管理浮点型，整形只会管理-128到127）和String。

类加载时，会查询字符串常量池，以保证运行时常量池所引用的字符串与字符串常量池中是一致的。

直接内存

在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。也可能导OutOfMemoryError异常出现。

常量池补充

Class文件常量池

Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行时常量池

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。

字符串常量池

存储字符串对象，或是字符串对象的引用。

类加载

类加载的时机

如果类没有进行过初始化，则需要先触发其初始化。虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

• 创建类的实例(new 的方式)。访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法（类.xxx调用）
• 反射的方式
• 初始化某个类的子类，则其父类也会被初始化
• Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
• 当使用JDK1.7的动态语言支持时

类的生命周期

包括7个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中验证、准备、解析3个部分统称为连接（Linking）。

解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。

加载

• 通过一个类的全限定名来获取定义此类的二进制字节流。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

验证

这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。

假设一个类变量的定义为：

public static int value=123;

那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器**<clinit**>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

解析

虚拟机将常量池内的符号引用替换为直接引用的过程。

• 符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
• 直接引用：直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器()方法的过程。

• <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问：

public class Test{
​    static{
​        i=0; //给变量赋值可以正常编译通过
​        System.out.print(i); //这句编译器会提示"非法向前引用"
​    }
​    static int i=1；
}

• <clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。

类加载器

类加载器可以分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器。他们的关系一般如下：

启动类加载器（Bootstrap ClassLoader）

这个类将器负责将存放在****＜JAVA_HOME＞\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器，那直接使用null指定父类加载器即可：

public class MyClassLoader extends ClassLoader{
​    protected MyClassLoader(ClassLoader parent) {
​        super(parent);
​    }
​    // 使用ClassLoader父类的构造方法：根据ClassLoader中loadClass可以知道，设置父类加载器为null会使用Bootstrap ClassLoader来加载
​    protected MyClassLoader() {
​        this(null);
​    }
}

扩展类加载器（Extension ClassLoader）

这个加载器由sun.misc.Launcher $ExtClassLoader实现，它负责加载＜JAVA_HOME＞\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器（Application ClassLoader）

这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

类加载机制————双亲委派机制

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

优点：

• Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类
• 相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱
• 可以通过动态的路径进行类的加载操作

比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。