前言：
每个Java开发人员都知道字节码由JRE（Java运行时环境）执行。但许多人不知道JRE是Java Virtual Machine（JVM）的实现，它分析字节码，解释代码并执行它。作为开发人员，我们应该知道JVM的架构是非常重要的，因为它使我们能够更有效地编写代码。在本文中，我们将更深入地了解Java中的JVM架构和JVM的不同组件。
什么是JVM？
Virtual Machine是物理机器的软件实现。Java是用在VM上运行的WORA（Write Once Run Anywhere）概念而开发的。编译器将Java文件编译为Java .class文件，然后将.class文件输入到JVM中，JVM会加载并执行类文件。下面是JVM的架构图。
1. Java 内存区域与内存溢出异常
1.1 运行时数据区域
根据《Java 虚拟机规范(Java SE 7 版)》规定，Java 虚拟机所管理的内存如下图所示。
1.1.1 程序计数器
内存空间小，线程私有。字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成
如果线程正在执行一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器的值则为 (Undefined)。此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。
1.1.2 Java 虚拟机栈
线程私有，生命周期和线程一致。描述的是 Java 方法执行的内存模型：每个方法在执行时都会床创建一个栈帧(Stack Frame)用于存储 局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。
局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)
StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。
OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够的内存。
1.1.3 本地方法栈
区别于 Java 虚拟机栈的是，Java 虚拟机栈为虚拟机执行 Java 方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。也会有 StackOverflowError 和 OutOfMemoryError 异常。
1.1.4 Java 堆
对于绝大多数应用来说，这块区域是 JVM 所管理的内存中最大的一块。线程共享，主要是存放对象实例和数组。内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。可以位于物理上不连续的空间，但是逻辑上要连续。
OutOfMemoryError：如果堆中没有内存完成实例分配，并且堆也无法再扩展时，抛出该异常。
1.1.5 方法区
属于共享内存区域，存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
现在用一张图来介绍每个区域存储的内容。
1.1.6 运行时常量池
属于方法区一部分，用于存放编译期生成的各种字面量和符号引用。编译器和运行期(String 的 intern() )都可以将常量放入池中。内存有限，无法申请时抛出 OutOfMemoryError。
1.1.7 直接内存
非虚拟机运行时数据区的部分
在 JDK 1.4 中新加入 NIO (New Input/Output) 类，引入了一种基于通道(Channel)和缓存(Buffer)的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。可以避免在 Java 堆和 Native 堆中来回的数据耗时操作。
OutOfMemoryError：会受到本机内存限制，如果内存区域总和大于物理内存限制从而导致动态扩展时出现该异常。
1.2 HotSpot 虚拟机对象探秘
主要介绍数据是如何创建、如何布局以及如何访问的。
1.2.1 对象的创建
创建过程比较复杂，建议看书了解，这里提供个人的总结。
遇到 new 指令时，首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，执行相应的类加载。
类加载检查通过之后，为新对象分配内存(内存大小在类加载完成后便可确认)。在堆的空闲内存中划分一块区域(‘指针碰撞-内存规整’或‘空闲列表-内存交错’的分配方式)。
前面讲的每个线程在堆中都会有私有的分配缓冲区(TLAB)，这样可以很大程度避免在并发情况下频繁创建对象造成的线程不安全。
内存空间分配完成后会初始化为 0(不包括对象头)，接下来就是填充对象头，把对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息存入对象头。
执行 new 指令后执行 init 方法后才算一份真正可用的对象创建完成。
1.2.2 对象的内存布局
在 HotSpot 虚拟机中，分为 3 块区域：对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)
对象头(Header)：包含两部分，第一部分用于存储对象自身的运行时数据，如哈希码、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，32 位虚拟机占 32 bit，64 位虚拟机占 64 bit。官方称为 ‘Mark Word’。第二部分是类型指针，即对象指向它的类的元数据指针，虚拟机通过这个指针确定这个对象是哪个类的实例。另外，如果是 Java 数组，对象头中还必须有一块用于记录数组长度的数据，因为普通对象可以通过 Java 对象元数据确定大小，而数组对象不可以。
实例数据(Instance Data)：程序代码中所定义的各种类型的字段内容(包含父类继承下来的和子类中定义的)。
对齐填充(Padding)：不是必然需要，主要是占位，保证对象大小是某个字节的整数倍。
1.2.3 对象的访问定位
使用对象时，通过栈上的 reference 数据来操作堆上的具体对象。
通过句柄访问
Java 堆中会分配一块内存作为句柄池。reference 存储的是句柄地址。详情见图。
使用直接指针访问
reference 中直接存储对象地址
比较：使用句柄的最大好处是 reference 中存储的是稳定的句柄地址，在对象移动(GC)是只改变实例数据指针地址，reference 自身不需要修改。直接指针访问的最大好处是速度快，节省了一次指针定位的时间开销。如果是对象频繁 GC 那么句柄方法好，如果是对象频繁访问则直接指针访问好。
虚拟机类加载机制
虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、装换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型。
在 Java 语言中，类型的加载、连接和初始化过程都是在程序运行期间完成的。
类加载时机
类的生命周期( 7 个阶段)
其中加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。解析阶段可以在初始化之后再开始(运行时绑定或动态绑定或晚期绑定)。
以下五种情况必须对类进行初始化(而加载、验证、准备自然需要在此之前完成)：
遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时没初始化触发初始化。使用场景：使用 new 关键字实例化对象、读取一个类的静态字段(被 final 修饰、已在编译期把结果放入常量池的静态字段除外)、调用一个类的静态方法。
使用 java.lang.reflect 包的方法对类进行反射调用的时候。
当初始化一个类的时候，如果发现其父类还没有进行初始化，则需先触发其父类的初始化。
当虚拟机启动时，用户需指定一个要加载的主类(包含 main() 方法的那个类)，虚拟机会先初始化这个主类。
当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需先触发其初始化。
前面的五种方式是对一个类的主动引用，除此之外，所有引用类的方法都不会触发初始化，佳作被动引用。举几个例子~
public class SuperClass {
static {
System.out.println("SuperClass init!");
}
public static int value = 1127;
}
public class SubClass extends SuperClass {
static {
System.out.println("SubClass init!");
}
}
public class ConstClass {
static {
System.out.println("ConstClass init!");
}
public static final String HELLOWORLD = "hello world!"
}
public class NotInitialization {
public static void main(String[] args) {
System.out.println(SubClass.value);
/**
* output : SuperClass init!
*
* 通过子类引用父类的静态对象不会导致子类的初始化
* 只有直接定义这个字段的类才会被初始化
*/
SuperClass[] sca = new SuperClass[10];
/**
* output :
*
* 通过数组定义来引用类不会触发此类的初始化
* 虚拟机在运行时动态创建了一个数组类
*/
System.out.println(ConstClass.HELLOWORLD);
/**
* output :
*
* 常量在编译阶段会存入调用类的常量池当中，本质上并没有直接引用到定义类常量的类，
* 因此不会触发定义常量的类的初始化。
* “hello world” 在编译期常量传播优化时已经存储到 NotInitialization 常量池中了。
*/
}
}
类的加载过程
加载
通过一个类的全限定名来获取定义次类的二进制流(ZIP 包、网络、运算生成、JSP 生成、数据库读取)。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法去这个类的各种数据的访问入口。
数组类的特殊性：数组类本身不通过类加载器创建，它是由 Java 虚拟机直接创建的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建的，数组创建过程如下：
如果数组的组件类型是引用类型，那就递归采用类加载加载。
如果数组的组件类型不是引用类型，Java 虚拟机会把数组标记为引导类加载器关联。
数组类的可见性与他的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为 public。
内存中实例的 java.lang.Class 对象存在方法区中。作为程序访问方法区中这些类型数据的外部接口。
加载阶段与连接阶段的部分内容是交叉进行的，但是开始时间保持先后顺序。
6.2.2 验证
是连接的第一步，确保 Class 文件的字节流中包含的信息符合当前虚拟机要求。
文件格式验证
是否以魔数 0xCAFEBABE 开头
主、次版本号是否在当前虚拟机处理范围之内
常量池的常量是否有不被支持常量的类型（检查常量 tag 标志）
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 编码的数据
Class 文件中各个部分集文件本身是否有被删除的附加的其他信息
……
只有通过这个阶段的验证后，字节流才会进入内存的方法区进行存储，所以后面 3 个验证阶段全部是基于方法区的存储结构进行的，不再直接操作字节流。
元数据验证
这个类是否有父类（除 java.lang.Object 之外）
这个类的父类是否继承了不允许被继承的类（final 修饰的类）
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
类中的字段、方法是否与父类产生矛盾（覆盖父类 final 字段、出现不符合规范的重载）
这一阶段主要是对类的元数据信息进行语义校验，保证不存在不符合 Java 语言规范的元数据信息。
字节码验证
保证任意时刻操作数栈的数据类型与指令代码序列都鞥配合工作（不会出现按照 long 类型读一个 int 型数据）
保证跳转指令不会跳转到方法体以外的字节码指令上
保证方法体中的类型转换是有效的（子类对象赋值给父类数据类型是安全的，反过来不合法的）
……
这是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。这个阶段对类的方法体进行校验分析，保证校验类的方法在运行时不会做出危害虚拟机安全的事件。
符号引用验证
符号引用中通过字符创描述的全限定名是否能找到对应的类
在指定类中是否存在符方法的字段描述符以及简单名称所描述的方法和字段
符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问
……
最后一个阶段的校验发生在迅疾将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，还有以上提及的内容。
符号引用的目的是确保解析动作能正常执行，如果无法通过符号引用验证将抛出一个 java.lang.IncompatibleClass.ChangeError 异常的子类。如 java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError 等。
准备
这个阶段正式为类分配内存并设置类变量初始值，内存在方法去中分配(含 static 修饰的变量不含实例变量)。
public static int value = 1127;
这句代码在初始值设置之后为 0，因为这时候尚未开始执行任何 Java 方法。而把 value 赋值为 1127 的 putstatic 指令是程序被编译后，存放于 clinit() 方法中，所以初始化阶段才会对 value 进行赋值。
基本数据类型的零值
特殊情况：如果类字段的字段属性表中存在 ConstantValue 属性，在准备阶段虚拟机就会根据 ConstantValue 的设置将 value 赋值为 1127。
解析
这个阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用
符号引用以一组符号来描述所引用的目标，符号可以使任何形式的字面量。
直接引用
直接引用可以使直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用和迅疾的内存布局实现有关
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符 7 类符号引用进行，分别对应于常量池的 7 中常量类型。
初始化
前面过程都是以虚拟机主导，而初始化阶段开始执行类中的 Java 代码。
类加载器
通过一个类的全限定名来获取描述此类的二进制字节流。
双亲委派模型
从 Java 虚拟机角度讲，只存在两种类加载器：一种是启动类加载器（C++ 实现，是虚拟机的一部分）；另一种是其他所有类的加载器（Java 实现，独立于虚拟机外部且全继承自 java.lang.ClassLoader）
启动类加载器
加载 lib 下或被 -Xbootclasspath 路径下的类
扩展类加载器
加载 lib/ext 或者被 java.ext.dirs 系统变量所指定的路径下的类
引用程序类加载器
ClassLoader负责，加载用户路径上所指定的类库。
除顶层启动类加载器之外，其他都有自己的父类加载器。
工作过程：如果一个类加载器收到一个类加载的请求，它首先不会自己加载，而是把这个请求委派给父类加载器。只有父类无法完成时子类才会尝试加载。
破坏双亲委派模型
keyword：线程上下文加载器(Thread Context ClassLoader)
运行时数据区
运行时数据区分为5个主要组件：
方法区——所有的类级别数据将存储在这里，包括静态变量。每个JVM只有一个方法区，并且它是一个共享资源。
堆区域——所有对象及其对应的实例变量和数组将存储在这里。每个JVM也有一个堆区域。由于方法和堆区域共享多个线程的内存，因此所存储的数据非线程安全。
堆栈区——对于每个线程，将创建一个单独的运行时栈。对于每个方法调用，将在堆栈存储器中产生一个条目，称为堆栈帧。所有局部变量将在堆栈内存中创建。堆栈区域是线程安全的，因为它不是共享资源。堆栈帧分为三个子元素：
局部变量数组——与方法相关，涉及局部变量以及将在此存储的相应值的多少。
操作数堆栈——如果需要执行任何中间操作，那么操作数堆栈将充当运行时工作空间来执行操作。
帧数据——对应于方法的所有符号存储在此处。在任何异常的情况下，捕捉块信息将被保持在帧数据中。
PC寄存器——每个线程都有单独的PC寄存器，用于保存当前执行指令的地址，一旦指令执行，PC寄存器将更新到下一条指令。
本地方法堆栈——本地方法堆栈保存本地方法信息。对于每个线程，将创建一个单独的本地方法堆栈。
执行引擎
分配给运行时数据区的字节码将由执行引擎执行。执行引擎读取字节码并逐个执行它。
解释器——解释器解释字节码较快，但执行慢。解释器的缺点是当一个方法被多次调用时，每次都需要新的解析。
JIT编译器——JIT编译器消除了解释器的缺点。执行引擎将在转换字节码时使用解释器的帮助，但是当它发现重复的代码时，它使用JIT编译器，编译器会编译整个字节码并将其更改为本地代码。这个本地代码将直接用于重复的方法调用，从而提高系统性能。
中间代码生成器——生成中间代码
代码优化器——负责优化上面生成的中间代码
目标代码生成器——负责生成机器代码或本地代码
分析器——一个特殊组件，负责查找热点，即该方法是否被多次调用。
垃圾收集器：收集和删除未引用的对象。可以通过调用“System.gc（）”触发垃圾收集器，但不能保证执行。JVM的垃圾回收收集创建的对象。
总结：
前面两次粗略的阅读，能理解内容，但是很难记住细节。每每碰到不会的知识点就上网查，所以知识点太碎片脑子里没有体系不仅更不容易记住，而且更加容易混乱。但是通过这种方式记录发现自己清晰了很多，就算以后忘记，知识再次捡起的成本也低了很多。
学习路线图，进群：433540541，免费获取学习资料哦。
