chapter4.1 JVM完整笔记

admin管理员组

文章数量:1582014

1. Java虚拟机概念

Java虚拟机是一台执行Java字节码的虚拟计算机，它拥有独立的运行机制，其运行的Java字节码也未必由Java语言编译而成。（只要符合JVM字节码的格式就可以运行）

JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回器（GC），以及可靠的即时编译器（JIT）。

Java技术的核心就是Java虚拟机（JVM，Java Virtual Machine），因为所有的Java程序都运行在Java虚拟机内部。

Java虚拟机就是二进制字节码的运行环境，负责装载字节码到其内部，解释/编译为对应平台上的机器指令执行。每一条Java指令，Java虚拟机规范中都有详细定义，如怎么取操作数，怎么处理操作数，处理结果放在哪里。

特点：

• 一次编译，到处运行（JVM字节码）
• 自动内存管理
• 自动垃圾回收功能（GC）

java代码执行流程
java程序–（编译）–>字节码文件–（解释执行）–>操作系统（Win，Linux，Mac JVM）

1.1 JVM的整体结构

图（↓）
/*Class Files：字节码文件
*Class Loader：将字节码文件加载到内存当中

*Runtime Data Area
*Method Area：生成class对象，对静态属性进行初始化，存放相关的信息
*Heap
*program Register
*Native Method Stack
*Java Virtual Stack

*Execution Engine：真正执行字节码指令，依次执行。将会用到Program Counter Register，NativeMethodStack和JVMstack。
*Native Method Interface

*PS：ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定
*/

详细图（↓）：

1.2 JVM的架构模型

Java编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。具体来说：这两种架构之间的区别：

基于栈式架构的特点

1. 设计和实现更简单，适用于资源受限的系统；
2. 避开了寄存器的分配难题：使用零地址指令方式分配。
3. 指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈。指令集更小，指令多执行性能比寄存器差，编译器容易实现。
4. 不需要硬件支持，可移植性更好，更好实现跨平台

基于寄存器架构的特点

1. 典型的应用是x86的二进制指令集：比如传统的PC以及Android的Davlik虚拟机。
2. 指令集架构则完全依赖硬件，可移植性差
3. 性能优秀和执行更高效
4. 花费更少的指令去完成一项操作。
5. 在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主方水洋

总结

由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以不能设计为基于寄存器的。优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令，执行性能比寄存器差。

时至今日，尽管嵌入式平台已经不是Java程序的主流运行平台了（准确来说应该是HotSpotVM的宿主环境已经不局限于嵌入式平台了），那么为什么不将架构更换为基于寄存器的架构呢？(因为栈的架构可以跨平台)

1.3 生命周期：

虚拟机的启动
Java虚拟机的启动是通过引导类加载器（bootstrap class loader）创建一个初始类（initial class）来完成的，这个类是由虚拟机的具体实现指定的。

虚拟机的执行

• 一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序。
• 程序开始执行时他才运行，程序结束时他就停止。
• 执行一个所谓的Java程序的时候，真真正正在执行的是一个叫做Java虚拟机的进程。

虚拟机的退出
有如下的几种情况：

• 程序 正常执行结束
• 程序在执行过程中遇到了异常或错误而异常终止
• 由于操作系统用现错误而导致Java虚拟机进程终止
• 某线程调用Runtime类或system类的exit方法，或Runtime类的halt方法，并且Java安全管理器也允许这次exit或halt操作。
• 除此之外，JNI（Java Native Interface）规范描述了用JNI Invocation API来加载或卸载 Java虚拟机时，Java虚拟机的退出情况。

2. 类加载机制

类加载器子系统作用
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。
ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池Constant pool信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

2.1 类的加载过程

类的加载过程LoadingClass有三个环节：
第一个环节：Loading加载（三种加载器BootStrap ClassLoader，Extension ClassLoader，Application ClassLoader）
第二个环节：Linking 链接（包括Verify验证，Prepare准备，Resolve解析）
第三个环节：Initialization初始化（静态变量初始化）

2.1.1 Loading

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

加载class文件的方式

• 从本地系统中直接加载
• 通过网络获取，典型场景：Web Applet
• 从zip压缩包中读取，成为日后jar、war格式的基础
• 运行时计算生成，使用最多的是：动态代理技术
• 由其他文件生成，典型场景：JSP应用
• 从专有数据库中提取.class文件，比较少见
• 从加密文件中获取，典型的防Class文件被反编译的保护措施

2.1.2 Linking 链接（包含Verify，Prepare，Resolve ）

Verify 验证

• 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。
• 主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
  （可以使用工具：Binary Viewer查看）

Prepare 准备

• 为类变量分配内存并且设置该类变量的默认初始值，即零值；
• 这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化；
• 不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到java堆中。

Resolve 解析

• 将常量池内的符号引用转换为直接引用的过程。
• 事实上，解析操作往往会伴随着jvm在执行完初始化之后再执行
• 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。（句柄？？）
• 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info/CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

2.1.3 Initialization初始化（静态变量初始化）

1. 初始化阶段就是执行类构造器方法<clinit>()的过程。
2. 此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
3. 注意：如果没有静态变量c或者静态代码块，那么字节码文件中就不会有clinit方法
4. 构造器方法中指令按语句在源文件中出现的顺序执行。
5. <clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）
6. 若该类具有父类，jvm会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
7. 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。
8. 任何一个类在声明后，都有生成一个构造器，默认是空参构造器

2.2 类加载器的分类

JVM支持两种类型的加载器，分别为引导类加载器（BootStrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有三个，如下所示：
（三种加载器BootStrap ClassLoader，Extension ClassLoader，Application ClassLoader）

2.2.1 自定义类与核心类库的加载器

对于用户自定义类来说：使用系统类加载器AppClassLoader进行加载
java核心类库都是使用引导类加载器BootStrapClassLoader加载的

2.2.2 虚拟机自带的加载器

①启动类加载器/引导类加载器（BootStrap ClassLoader）null

• 这个类加载使用C/C++语言实现的，嵌套在JVM内部
• 它用来加载java的核心库（JAVA_HOME/jre/lib/rt.jar/resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
• 并不继承自java.lang.ClassLoader,没有父加载器
• 加载拓展类和应用程序类加载器，并指定为他们的父加载器
• 处于安全考虑，BootStrap启动类加载器只加载包名为java、javax、sun等开头的类

②拓展类加载器（Extension ClassLoader）$Ext

• java语言编写 ，由sun.misc.Launcher$ExtClassLoader实现。
• 派生于ClassLoader类
• 父类加载器为启动类加载器
• 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会由拓展类加载器自动加载

③应用程序类加载器（系统类加载器，AppClassLoader）$App

• java语言编写， 由sun.misc.Launcher$AppClassLoader实现。
• 派生于ClassLoader类
• 父类加载器为拓展类加载器
• 它负责加载环境变量classpath或系统属性 java.class.path指定路径下的类库
• 该类加载器是程序中默认的类加载器，一般来说，java应用的类都是由它来完成加载
• 通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器

④用户自定义类加载器
为什么要自定义加载器

1. 隔离加载类：确保应用的框架，避免冲突等。
2. 修改类加载的方式
3. 拓展加载源：sql等
4. 防止源码泄漏

用户自定义类加载器实现步骤：

1. 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
2. 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass（）方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass（）方法，而是建议把自定义的类加载逻辑写在**findclass（）**方法中
3. 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass（）方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

2.3 ClassLoad类

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
常用方法：

方法名称	描述
getParent（）	返回该类加载器的超类加载器
loadClass（String name）	加载名称为name的类，返回结果为java.lang.Class类的实例
findClass（String name）	查找名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass（String name）	查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例
defineClass（String name，byte[] b,int off,int len）	把字节数组b中的内容转换为一个Java类 ，返回结果为java.lang.Class类的实例
resolveClass（Class<?> c）	连接指定的一个java类

e.g.

1. class.forName(“xxxxx”).getClassLoader()
2. ~
3. ~.getParent()

2.5 沙箱

比如自定义一个string类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

类比举例： 我们在读写U盘信息时可以用360沙箱，防止U盘内的病毒等污染沙箱外的系统和应用程序。

3. 运行时数据区

Runtime Data Area
Method Area：把每个字节码文件在内存中相应的class/interface加载进来，存放类的信息，常量，域信息，方法信息。
PC Register：
Stack Area：
LV OS DL RA
NativeMethod：
Heap Area：创建JAVA对象，被多个线程共享的

Execution Engine
解析成机器指令

3.1 内存与线程

3.1.1 内存

内存是非常重要的系统资源，是硬盘和cpu的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM内存布局规定了JAVA在运行过程中内存申请、分配、管理的策略，保证了JVM的高效稳定运行。不同的jvm对于内存的划分方式和管理机制存在着部分差异（对于Hotspot主要指方法区）

3.1.2 分区介绍

java虚拟机定了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与县城一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。
如图，灰色的区域为单独线程私有的，红色的为多个线程共享的，即

每个线程：独立包括程序计数器、虚拟机栈、本地栈
线程间共享：堆、堆外内存（方法区、永久代或元空间、代码缓存）
一般来说，jvm优化95%是优化堆区，5%优化的是方法区

3.1.3 线程

线程是一个程序里的运行单元，JVM允许一个程序有多个线程并行的执行；
在HotSpot JVM，每个线程都与操作系统的本地线程直接映射。

当一个java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。java线程执行终止后。本地线程也会回收。

操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，它就会调用java线程中的run()方法.

3.2.1 JVM系统线程

主要的后台系统线程在HotSpot JVM里主要是以下几个：（不包括调用main方法的main线程以及所有这个main线程自己创建的线程）

1. 虚拟机线程：这种线程的操作是需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是他们都需要JVM达到安全点，这样堆才不会变化。这种线程的执行类型包括**"stop-the-world"的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销**。
2. 周期任务线程：这种线程是时间周期事件的体现（比如中断），他们一般用于周期性操作的调度执行。
3. GC线程：这种线程对在JVM里不同种类的垃圾收集行为提供了支持。
4. 编译线程：这种线程在运行时会将字节码编译成到本地代码。
5. 信号调度线程：这种线程接收信号并发送给JVM，在它内部通过调用适当的方法进行处理。

3.3.1 程序计数器（PC寄存器）

JVM中的程序计数寄存器（Program Counter Register）中，Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能够运行。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。

1.1 作用

• PC寄存器是用来存储指向下一条指令的地址，

本文标签： 完整笔记JVM