JVM内存模型

什么是JVM

　　JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一个虚构出来的计算机，有着自己完善的硬件架构，如处理器、堆栈等。

为什么需要JVM

　　Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。

　　Java文件必须先通过一个叫javac的编译器，将代码编译成class文件，然后通过JVM把class文件解释成各个平台可以识别的机器码，最终实现跨平台运行代码。

HotSpot内存模型

　　

（一）字节码文件

　　Class字节码文件是jvm认识的一种文件，里面的地址都是逻辑的地址。最后需要运行在操作系统中，操作系统只能识别真实的物理地址。此时需要动态链接，就是在运行时动态地绑定对象、对象地址

　　Class字节码文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件中，中间没有添加任何的分隔符，这使得整个Class文件中存储的内容几乎全部是程序运行的必需数据

　　Class字节码文件只有两种数据类型：无符号数(u)和表(info)

　　详细的字节码结构可以参考下这篇文章：https://blog.csdn.net/weixin_51702416/article/details/125640252

（二）类加载机制

　　Java虚拟机把描述类的数据用类加载器从Class文件加载到内存，并对数据进行校验、转换解析和初始化最终形成可以被虚拟机直接使用的Java类型

　　一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verifification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段 

　　

1.加载阶段 

　　//虚拟机主要完成以下三件事

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

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

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

2.验证阶段 

//确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求,保证这些信息被当作代码运行后不会危害虚拟机自身的安全

（1）文件格式验证

　　是否以魔数0xCAFEBABE开头。　　

　　主、次版本号是否在当前Java虚拟机接受范围之内。　　

　　常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。

　　指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。

　　CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。

　　Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。

（2）元数据验证

　　第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求，这个阶段可能包括的验证点如下：

　　这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。

　　这个类的父类是否继承了不允许被继承的类（被fifinal修饰的类）。

　　如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。

（3）字节码验证

　　第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。

　　保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于“在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中”这样的情况。

　　保证任何跳转指令都不会跳转到方法体以外的字节码指令上。

　　保证方法体中的类型转换总是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险和不合法的。

（4）符号引用验证

　　最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用[插图]的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。

　　符号引用中通过字符串描述的全限定名是否能找到对应的类。

　　在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。

　　符号引用中的类、字段、方法的可访问性（private、protected、public、）是否可被当前类访问。

3.准备阶段　

　　准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段

　　首先是这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值

4.解析阶段

　　解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

　　类或接口的解析

　　字段解析

　　方法解析

　　接口方法解析

5.初始化阶段

　　类的初始化阶段是类加载过程的最后一个步骤，直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

（三）类加载器

1.类加载器　　

　　//只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

　　（1）启动类加载器（Bootstrap Class Loader）：前面已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。

　　（2）扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。

　　（3）应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库。

2.双亲委派机制

　　//各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model）”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

　　（1）工作过程

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

　　

　　（2）作用

　　使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

　　解决安全问题。

　　（3）破坏双亲委托机制　

　　双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式
　　a. 双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。
　　b.双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码。
　　一个典型的例子便是JNDI服务JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，启动类加载器是绝不可能认识、加载这些代码的为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread ContextClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。
　　c. 双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（HotDeployment）等OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构

　　d.JDBC接口规范的实现，就需要破坏双亲委托机制

（四）运行时数据区域

　　蓝色区域共享，褐色部分私有

　　

 1.程序计数器

　　当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

　　如果线程执行的是java方法，记录的就是执行的虚拟机字节码指令的地址，如果是native方法，那么就是undefined。

2.栈 （线程私有）

 　　线程每调用一个方法就会创建一个栈帧（栈帧存储局部变量表、操作数栈、动态链接、方法出入口等）

3.本地方法栈

　　与虚拟机栈类似，为Native方法服务，一般是java调用其他语言时使用。

4.方法区

　　运行时常量池：编译器生成的各种字面值符号引用

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

　　可以为固定大小或动态扩展

　　方法区是线程共享的

　　方法区可以不被垃圾收集器回收 

5.堆

　　堆是所有类实例和数组的内存分配的运行时数据区。

　　虚拟机启动时创建。

　　堆可以为固定大小或动态扩展

　　堆的内存逻辑连续，物理不连续

　　堆是线程共享的

　　对象的堆存储由垃圾收集器回收 

6.运行时常量池

　　方法区的一部分，存放编译器生成的各种字面量和符号引用以及直接引用。

7.直接内存　

　　非虚拟机运行时内存，基于通道与缓冲区的NIO模式下，直接内存可以使用native函数库直接分配堆外内存，然后通过一个存储在java堆中的DirectByteBuffffer对象作为这块内存的引用进行操作。避免java堆和natice堆中来回复制数据。