JVM111

JVM1

字节码与多语言混合编程

字节码

• 我们平时说的java字节码， 指的是用java语言编译成的字节码。准确的说任何能在jvm平台上执行的字节码格式都是一样的。所以应该统称为:jvm字节码。
• 不同的编译器，可以编译出相同的字节码文件，字节码文件也可以在不同的JVM上运行。
• Java虚拟机与Java 语言并没有必然的联系，它只与特定的二进制文件格式一Class文件格式所关联， Class文件中包含了Java 虚拟机指令集(或者称为字节码、Bytecodes) 和符号表，还有一些其他辅助信息。

多语言混合编程
就是我们编写系统的时候，可以使用好多的语言，比如python了，java了什么的，但是最后这些语言都会被翻译成字节码，无论是什么语言，最终翻译成的字节码都是一样的，最后这些字节码再由java虚拟机运行。

虚拟机与Java虚拟机的介绍

所谓虚拟机(Virtual Machine)， 就是一台虚拟的计算机、它是一款软件，用来执行一系列虚拟计算机指令。大体上，虚拟机可以分为系统虚拟机和程序虛拟机。

1. 大名鼎鼎的Visual Box, VMware就属于系统虚拟机，它们完全是对物理计算机的仿真，提供了一个可运行完整操作系统的软件平台。
2. 程序虚拟机的典型代表就是Java虚拟机,它专门为执行单个计算机程序而设计，在Java虚拟机中执行的指令我们称为Java字节码指令。

• 无论是系统虚拟机还是程序虚拟机，在上面运行的软件都被限制于虚拟机提供的资源中。
• Java虚拟机是一台执行Java字节码的虚拟计算机，它拥有独立的运行机制，其运行的Java字节码也未必由Java语言编译而成。
• JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回收器，以及可靠的即时编译器。
• Java技术的核心就是Java虚拟机(JVM，Java Virtual Machine) ，因为所有的Java程序都运行在Java虚拟机内部。

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

java虚拟机特点

• 一次编译，到处运行
• 自动内存管理
• 自动垃圾回收功能，

JVM整体结构

• HotSpot VM是目前市面上高性能虚拟机的代表作之一。
• 它采用解释器与即时编译器并存的架构。
• 在今天，Java程序的运行性能早已脱胎换骨，已经达到了可以和C/C+ +程序一较高下的地步。
  如下图：
  
  java虚拟机（JVM就是java虚拟机）是用来解释字节码文件的，因此它的入口肯定是一个类文件Class files，这个文件是个字节码文件，然后会被使用JVM虚拟机解释。

类装载器子系统把字节码文件装载到内存中，并生成Class对象，涉及到加载，链接，初始化。

多个线程共享方法区与堆，而至于Java栈，本地方法栈，程序计数器，都是每个线程私有的。

操作系统只能解释机器指令，但是我们的字节码并不等同于机器指令，还必须要把字节码翻译成机器指令，操作系统才能识别。而我们的执行引擎的作用主要就是把字节码翻译成机器指令。

Java代码执行流程

只要让字节码文件符合jvm规范，就可以在jvm上解释执行，即使它不是Java语言开发的，只要这个语言最后生成的字节码是正确的就可以，如下图：

区分栈的指令集架构和寄存器的指令集架构

JVM架构模型
Java编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。Hotspot虚拟机只有一种寄存器：pc寄存器，所以它是基于栈的指令集架构。具体来说:这两种架构之间的区别:

• 基于栈式架构的特点
  设计和实现更简单，适用于资源受限的系统;
  避开了寄存器的分配难题:使用零地址指令方式分配。
  指令流中的指令大部分是零地址指令，其执行过程依赖于操作栈。指令集更小，编译器容易实现。
  不需要硬件支持，可移植性更好，更好实现跨平台
• 基于寄存器架构的特点
  典型的应用是x86的二进制指令集:比如传统的PC以及Android的Davlik虚拟机。
  指令集架构则完全依赖硬件，可移植性差。
  性能优秀和执行更高效;
  花费更少的指令去完成一项操作。
  在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主。

栈式架构是零地址指令，每八位进行对齐，每八位为基本单位。指令集更小，但是指令更多；寄存器架构它是每16位为基本单位（双字节方式进行对齐，也就是每16位对齐）

基于栈的计算流程（以Java虚拟机为例）
下面有个2+3的java代码，如下：

public class StackStruTest {//这是java源文件，字节码文件我们程序员看不懂，需要进行反编译public static void main(String[] args) {int i = 2;int j = 3;int k = i + j;}
}

在idea中运行StackStruTest.java类生成字节码文件StackStruTest.class，生成的字节码文件会被保存到target目录里面，如下图：

然后打开test路径对应的终端，如下图：

最后需要对字节码文件StackStruTest.class进行反编译，反编译的命令是javap -v 字节码文件名字，如下图：

反编译结果如下图：

基于寄存器的计算流程
只需要两行代码，如下：

mov eax,2 //将eax寄存器的值设为2
add eax,3 //使eax寄存器的值加3

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

JVM的生命周期

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

虚拟机的执行

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

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

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

JVM虚拟机类型

SUN Classic VM的介绍

• 早在1996年Java1. 0版本的时候，Sun公司发布了一款名为sun Classic VM的Java虚拟机，它同时也是世界上第一款商用Java虚拟机，JDK1. 4时完全被淘汰。
• 主流的虚拟机解释器和编译器并存，而这款虚拟机内部只提供解释器。
• 如果使用JIT编译器，就需要进行外挂。但是一旦使用了JIT编译器，JIT就会接管虚拟机的执行系统。解释器就不再工作。解释器和编译器不能配合工作。
• 现在hotspot内置了此虚拟机。

热点代码：当虚拟机发现某个方法或代码块的运行特别频繁的时候，就会把这些代码认定为“热点代码”，为了提高其执行效率，在运行时，虚拟机会把这些代码编译成与本地平台相关的机器码，并放在方法区缓存起来。

HotSpot VM的介绍

SUN公司的HotSpot VM

• HotSpot历史
  最初由一家名为“Longview Technologies”的小公司设计。
  1997年， 此公司被Sun收购;2009年，Sun公司被甲骨文收购。
  JDK1.3时， HotSpot VM成为默认虚拟机

• 目前Hotspot占有绝对的市场地位，称霸武林。
  不管是现在仍在广泛使用的JDK6,还是使用比例较多的JDK8中， 默认的虚拟机都是HotSpot。
  Sun/Oracle JDK和OpenJDK的默认虚拟机。
  因此本课程中默认介绍的虚拟机都是HotSpot,相关机制也主要是指HotSpot的GC机制。(比如其他两个商用虚拟机都没有永久代的概念)

• 从服务器、桌面到移动端、嵌入式都有应用。

• 名称中的HotSpot指的就是它的热点代码探测技术。
  通过计数器找到最具编译价值代码，触发即时编译或栈上替换。
  通过编译器与解释器协同工作，在最优化的程序响应时间与最佳执行性能中取得平衡。

在jdk7及以前，习惯上把方法区称为永久代，jdk8开始，使用元空间取代了永久代。不过元空间与永久代最大的区别在于：元空间不再虚拟机设置的内存中，而是使用本地内存。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。

内存结构概述

内存结构三层总体划分图，如下图：

• 第一层：Class文件由类装载子系统（类加载器Class Loader）加载进内存，有三个过程包括加载，链接，初始化。其中链接过程有验证，准备，解析子过程。
• 第二层：运行时数据区。包括线程共享区域：方法区（落地实现jdk7永久代，jdk8元空间），堆。线程私有区域：虚拟机栈，本地方法栈，程序计数器。
• 第三层：执行引擎，本地方法接口（本地方法库）

三层划分结构细节，如下图：

类的加载器以及类加载过程

首先来看张图片，如下图：

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

类加载器ClassLoader角色

• class file存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
• class file加载到JVM中，被称为DNA元数据模板，放在方法区。
• 在.class文件 –> JVM –> 最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。

如下图：

类加载过程

public class HelloLoader {public static void main(String[] args) {System.out.println("谢谢 ClassLoader 加载我....");System.out.println("你的大恩大德，我下辈子再报！");}}

HelloLoader 的加载过程:

• 执行 main( ) 方法（静态方法）就需要先加载承载类 HelloLoader。
• 加载成功，则进行链接、初始化等操作，完成后调用 HelloLoader 类中的静态方法 main。
• 加载失败则抛出异常

如下图：

完整的类的加载过程
加载----->链接（验证----->准备------>解析）------>初始化
如下图：

加载过程：

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

加载.class文件的方式

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

链接过程 （分为三个子阶段：验证—> 准备----->解析）
验证(Verify):

• 目的在于确保class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,不会危害虚拟机自身安全。

• 主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。
  
  所有的能够被java虚拟机识别的字节码文件，它的开头全都是CAFE BABE。
  准备(Prepare):

• 为类变量分配内存并且设置该类变量的默认初始值,即零值。

• 这里不包含用final修饰的static,因为final在编译的时候就会分配了,准备阶段会显式初始化;

• 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。

例 变量a在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1

public class HelloApp {private static int a = 1;   //prepare：a = 0 ---> initial : a = 1public static void main(String[] args) {System.out.println(a);}
}

解析(Resolve):

• 将常量池内的符号引用转换为直接引用的过程。
• 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。
• 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在(java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
• 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等:对应常量池中的CONSTANT_class_info, CONSTANT_Fieldref_info, CONSTANT_Methodrefn_info等。
• 符号引用
  反编译class文件后可以查看符号引用 （反编译命令 javap -v HelloApp.class ）

初始化
注意这里的初始化并不是指我们类中的构造方法，而是字节码反编译之后的构造器方法，如下图：

• 初始化阶段就是执行类构造器方法()的过程。
• 此方法不需定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
• 构造器方法中指令按语句在源文件中出现的顺序执行。
• ()不同于类的构造器。(关联:构造器是虚拟机视角下的())
• 若该类具有父类,JVM会保证子类的()执行前,父类的()已经执行完毕。
• 虚拟机必须保证一个类的()方法在多线程下被同步加锁 。也就是说，一个类的方法被A线程调用的时候，那么这个类的方法就不能再被B线程调用。针对这个点，有一个例子，如下：

public class DeadThreadTest {public static void main(String[] args) {Runnable r = () -> {System.out.println(Thread.currentThread().getName() + "开始");DeadThread deadThread = new DeadThread();System.out.println(Thread.currentThread().getName() + "结束");};Thread t1 = new Thread(r, "线程1");Thread t2 = new Thread(r, "线程2");t1.start();t2.start();}
}class DeadThread {static {if(true) {System.out.println(Thread.currentThread().getName() + "初始化当前类");while(true) {}}}
}

输出结果如下：

可以发现只有线程1可以初始化我们的DeadThread类，这是因为当线程1初始化我们的类的时候，有一个死循环；而由于虚拟机必须保证一个类的()方法在多线程下被同步加锁，因此这个时候其它线程就不能再初始化DeadThread类。这个点开发中注意，一定要避免，否则可能会有隐含的错误。

字节码反编译软件Bytecode Viewer
如下图：

首先在idea里面运行ClassInitTest类生成字节码文件，如下图：

接着把字节码文件拖到Bytecode Viewer反编译字节码的软件中，可以看到字节码的反编译结果，如下图：

idea中自带的字节码反编译插件

首先先编译我们的java文件，如下图：

编译以后再View的地方会看到一个反编译字节码的标签，如下图：

然后就能够看到我们的字节码的反编译的结果了，如下图：