Java虚拟机（JVM）运行时数据区与类加载过程

根据《Java虚拟机规范》规定，java虚拟机所管理的内存包含了以下几个部分，如图：
注：JDK1.7的时候hotspot已经把原本放在永久代的字符串常量池、静态变量等逐步移动至Java堆中


1.程序计数器：
咱们先来瞅瞅这个很有意思的一个区域，此内存区域时唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

程序计数器时一块较小的内存空间，可以将它看作是当前线程所执行的字节码的行号指示器。在Java虚拟机的概念模型中，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，他是程序控制流的指示器，分支、循环、跳转、异常处理等基础功能都是需要依赖这个计数器来完成。

每个线程都有自己私有的程序计数器，因为java虚拟机的多线程时通过轮流切换，分配处理器的执行时间方式来实现的，在任何一个确定的时间，一个处理器（对于多核处理器来说是一个核）都只会执行一条线程中的指令。所以为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器

注：
如果线程正在执行的是一个java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址，但如果正在执行的是本地方法（Native方法），这个计数器之则为Undefined。

2.虚拟机栈
与程序计数器一样，虚拟机栈也是线程私有的。
它描述的是java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用直至完成的过程，都对应着一个栈帧从入栈到出栈的过程。
局部变量表存放了编译期间可知的各种Java虚拟机基本类型、对象应用和returnAddress类型，这些数据类型在在局部变量表中的存储空间以局部变量槽（slot）来表示。

• 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，及入栈和出栈的操作。

• 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个栈帧会随之创建出来，这个时候，这个方法的操作数栈是空的。

• 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就已经定义好了，保存在方法的Code属性中，为max_stack的值。

• 操作数栈中的数据可以是任何一个Java数据类型。32位的数据占用一个栈深度，64位的数据类型占用两个栈深度

• 虽然操作数栈是使用数组的方式来实现的，但是操作数栈只能用入栈和出栈的操作来完成一次数据访问，而不能使用索引的方式

• 操作数栈主要用于保存计算过程的中间结果，同时作为计算过程中变量的临时存储空间

在《JAVA虚拟机规范》中，对这个区域定义了两类的情况：

1. 线程的请求深度大于虚拟机所允许的深度，将抛出StackOverflowError异常

public class OutOfStackTest {    public static void main(String[] args) { a();    }    public static void a() { b();    }    public static void b() { a();    }}

2. 如果JAVA虚拟机栈可动态扩展，当栈扩展时无法申请到足够的内存会抛出OutOfMemmory异常

public class OutOfMemoryTest {    public static void main(String[] args) { String test ="testsetsetsetset"; while (true){     test = test+test; }    }}

3.本地方法栈
本地方法栈和虚拟机栈相似，区别不过是虚拟机栈为执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用本地方法服务。
《JAVA虚拟机规范》对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以更具需要自由的实现它。hotspot虚拟机就直接把本地方法栈和虚拟机合二为一。与虚拟机一样，线程请求的深度大于虚拟机所允许的深度或者无法申请到足够的内存将抛抛出StackOverflowError异常和OutOfMemoryError异常

注：
由于hotspot虚拟机中并不区分虚拟机栈和本地方法栈，因此对于hotspot来说，-Xoss参数（设置本地方法栈大小）虽然存在，但实际上并没有任何的效果，栈容量大小只能用-Xss参数来设定

4.java堆
对于java应用程序来说，Java堆是虚拟机所管理内存中最大的一块。Java堆是被所有线程共有的一块内存区域，在虚拟机启动的时候创建。此内存区域的唯一目的就是存放对象的实例。

相信大家对这个区域并不陌生，Java堆是垃圾收集器管理的内存区域，我们有时候也被称作“GC堆”。由于现代的垃圾回收器大部分都是基于分代机制实现的，所有我们会发现针对于Java堆，会出现一些“新生代”，“老年代，“永久代”，“Eden”，“From Survivor”,"To Survivor"等转业名词。这些区域其实仅仅是一部分垃圾回收器的共同特性或者说设计风格而已，而不是Java虚拟机具体实现的固有内存布局，也不是对Java堆的进一步细致划分。后续我会专门写一下关于各种垃圾回收器的介绍及实现。

Java世界中，“几乎”所有的实例都在这里分配。在《java虚拟机规范》中对java堆的描述是：“所有的对象实例以及数组都应当在堆上分配”。这里的“几乎”是指从实现的角度来看的。

《JAVA虚拟机规范》规定，Java堆可以处于物理上不连续的空间中，但逻辑上它应该被视为连续的。一个JVM只有一个堆，堆内存的大小是可以调节的：通过参数-Xms和-Xmx设定。

5.方法区
他用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码缓存等信息
这里不得不提到永久代。由于我们基本上都是在HotSpot虚拟机上进行开发，部署程序的，所以好多人都愿意把方法区称呼为“永久代”，但本质上方法区和永久代不是等价的，因为仅仅是当时的Hotspot虚拟机设计团队选择把收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已。

• JDK1.7的hotspot已经把原本放在永久代的字符串常量池、静态变量等移动至Java堆中。
• 到了JDK1.8则完废弃了永久代的概念，改用与JRockit、J9一样的本地内存中实现的元空间来代替

《Java虚拟机规范》对于方法区的约束时分厂宽松的，除了和堆一样不需要连续的内存和可以选择固定大小或者可拓展外，甚至还可以选择不实现垃圾收集。只是相对而言垃圾收集的这个行为在这个区域很少出现。这个区域的内存回收目标主要针对的是对常量池的回收和对类型的卸载，一般来说这个区域的回收效果是比较难以让人满意的，尤其是对于类型的卸载，条件非常苛刻，但是对这部分内存的回收也是必要的。

6.运行时常量池
运行时常量池时方法区的一部分，用于存放编译器生成的各种字面量常量与符号的引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
Java虚拟机对于Class文件每一部分的格式都有严格的规定，如每一个字节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可、加载和执行，但对于运行时常量池并没有做任何细节的要求，不过一般来说，除了保存Class文件中描述的符号引用外，还会把由符号引用翻译出来的直接引用也存储在运行时常量池中。
运行时常量池有一个重要的特征就是具有动态性，Java语言并不要求常量一定只有编译期才能产生，也就是说运行期间也可以将新的常量放入常量池中，我们接触比较多的就是String类的intern()方法

下面我们来看看类的生命周期，在JVM内存各个区域的流转
类的生命周期包含以下几个阶段：

1.加载
注意，此加载阶段只是整个“类加载”过程中的一个阶段。
在加载阶段，Java虚拟机需要做以下三件事情

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

在这里对于类的加载时机，加载方式，不做拓展，感兴趣的可以了解一下。Java虚拟机设计团队有意将类加载阶段中的“通过一个类的权限定名来获取描述该类的二进制流”这个动作的放到Java虚拟机外部去实现，以便让应用程序自己去决定如何去获取所需的类。实现这个动作的代码就被称为“类加载器”

相对于类加载的其他阶段，非数组类型的加载阶段（准确的说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的阶段。加载阶段即可以使用Java虚拟机内置的引导类加载器完成，也可以由用户自定义的类加载器去完成。这里就涉及到了大家耳熟能详的类加载的双庆委派机制。

对于数组而言，数组类本身不通过类加载器创建，他是由Java虚拟机直接在内存中动态构建出来的，但数组类于类加载器仍然有很密切的关系，因为数组类的元素类型最终还是要靠类加载器来完成加载的。

加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区中了，方法区中的数据存储格式完全由虚拟机实现自定义，《Java虚拟机规范》未规定此区域的数据结构。类型数据妥善安置在方法区后，会在Java堆内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

注意，加载阶段与链接阶段（验证，准备，解析）的部分动作是交叉进行的，加载阶段尚未结束，链接阶段可能已经开始。但是这两个阶段的开始时间始终保持固定的先后顺序。

2.验证
验证这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。这个验证的过程大致分为四个阶段的检验动作：

• 文件格式验证
  比如验证是否以魔数0xCAFEBABE开头；主、次版本好是否在当前Java虚拟机接受范围之类等等。该阶段的主要目的是保证输入的字节流能正确的解析并存储与方法区内，格式上符合描述一个Java类型信息的要求。这个阶段是基于二进制字节流进行的，只有通过了这个阶段的验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全都是基于方法区的存储结构上进行的，不会直接读取、操作字节流了。
• 元数据验证
  这个阶段是对字节码描述的信息进行语义分析，用以保证其描述的信息符合《Java虚拟机规范》的要求。如这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）；这个类是否继承了不允许被继承的类（被final修饰的类）等等。主要目的是对类的元数据信息进行语义的效验。
• 字节码验证
  字节码验证的主要目的是通过字节流分析和控制流分析，确定程序的语义是合法的，符合逻辑的。在对元数据验证后，这个阶段就要对方法体（Class文件中的Code属性）进行校验分析，保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。如。保证任何跳转指令都不会跳转到方法体以外的字节码指令上；保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作等等
• 符号引用验证
  这个阶段的校验行为，发生在虚拟机将符号引用转化为直接引用的时候。是不是很熟悉，没错，这个转换的动作将砸链接的第三个阶段–解析阶段中发生。
  符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的类信息进行匹配性校验，也就是该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。如符号引用中通过字符串描述的权限定名是否能找到对应的类；在指定的类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段等等

3.准备
准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配并设置类变量初始值的阶段。从概念上来说，这些变量所使用的内存都应当在方法区中进行匹配。但是我们必须要重视的一个问题，上面我们也提到了，方法区本身就是一个逻辑上的区域。在JDK7之前，HotSpot使用“永久代”来实现方法区，所以我们可以这样说。但是，JDK7之后类变量则会随着Class对象一起放在堆中，这时候这样说就完全是一种对逻辑概念的表述了。
在这个阶段进行的内存分配，仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。基本数据类型的赋初始值如下：

当然，这里有特殊情况，也就是当静态变量被final修饰的时候则会被直接赋实际值，而非初始值。如

public static final int value = 100;

这里在准备阶段则会被直接赋值100，而不是初始化为0。

4.解析

这个阶段是Java虚拟机将符号引用替换为直接引用的过程。
我们来看看什么是符号引用，什么事直接引用。

• 符号引用
  符号引用是以一组符号来描述引用的目标，符号引用可以是任何形式的字面量，只要使用时能够无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以不同，但是他们能接受的符号引用都必须是一致的，因为符号引用的字面量形式明确的定义在了《Java虚拟机规范》的Class文件格式中。
• 直接引用
  直接引用是可以直接指向目标的指针，相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用那引用的目标必定已经在虚拟机的内存中存在。

解析的动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这几类符号引用进行。

5.初始化

类的初始化阶段是类加载过程的最后一个步骤，在初始化阶段会为类的静态变量赋初值。我们也可以将这个阶段看成就是执行类构造器()方法的过程。()方法并不是我们在Java代码中直接编写的方法，他是Javac编译器的自动生成物。关于()方法有以下几点需要关注的

• ()方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义到定义在静态语句快之前的变量，定义在它之后的变量，在前面的静态语句快中可以赋值，但是不能访问
  关于这一点我们可以通过以下代码来验证：

public class TestClass {   public static void main(String[] args) {ClassInit init = ClassInit.newInstance();System.out.println("x=: "+init.x);System.out.println("y=: "+init.y);   }}class ClassInit {   private static ClassInit init  = new ClassInit();   public static int x=2;   static {x=3;y=3;   }   public static int y=2;   public static ClassInit newInstance(){return init;   }}

输出结果如图

我们将static字段赋值和静态代码块的位置修改后执行

class ClassInit {    private static ClassInit init  = new ClassInit();    static { x=3; y=3;    }    public static int y=2;    public static int x=2;    public static ClassInit newInstance(){ return init;    }}

输出结果如下：

当然，如果有自定义的构造方法的话，会先执行构造方法，如图：

class ClassInit {    private static ClassInit init  = new ClassInit();    public static int y;    public static int x=2;    static { x++; y++;    }    public ClassInit(){ x++; y++;    }    public static ClassInit newInstance(){ return init;    }}

执行结果如图：

代码会先执行构造方法后，x=1;y=1；然后按顺序执行static变量赋值，x++=2;y=1；然后执行静态代码块中的代码后x=3,y=2;感兴趣的朋友可以修改位置参数等调试一下看看，比较有意思

• ()方法与类的构造函数不同，他不需要显示地调用父类构造器，Java虚拟机会保证在子类的()方法执行前，父类的()方法已经执行完毕，因此在Java虚拟机中第一个被执行的()方法肯定是java.lang.Object。
• 由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于自类的变量赋值操作。
• ()方法对于类或接口来说并不是必须的，如果一个类中并没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成()方法。
• 接口中也会与类一样生成()方法，虽然在接口中不能使用静态代码块，但是仍然有变量初始化的赋值操作。但是和类不同的是，执行接口的()方法不需要先执行父接口的()方法，因为只有当父接口中定义的变量被使用的时候，父接口才会被初始化。此外，接口的实现类在初始化的时候也一样不会执行接口的()方法。
• Java虚拟机必须保证一个类的()方法在多线程环境中被正确地加锁同步。