概述
完整图如下:
如果想手写一个虚拟机的话:
需要考虑以下部分:类加载器,执行引擎
类加载子系统的作用
类加载子系统负责从文件或者网络中加载class文件,class文件在开头有特定的文件标识。ClassLoader只负责class文件的加载,至于他是否可以执行,则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间。除了类的信息之外,方法区还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)
- class file存在于本地硬盘上,可以理解为设计师画在纸上的模板,而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
- class file加载到JVM中,被称为DNA元数据模板,放在方法区。
- 在.class文件->JVM->最终成为元数据模板,此过程就要一个运输工具(类装载器Class Loader),扮演一个快递员的角色。
类加载过程
public class HelloLoader {
public static void main(String[] args) {
System.out.println("我已经被加载啦");
}
}
完整的流程如下:
加载阶段
通过一个类的全限定名获得此类的二进制流
将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问接口
加载class文件的方式
- 在本地系统中直接加载
- 通过网络获取,典型场景:Web Applet
- 从zip压缩包中读取,称为日后的jar,war 包格式的基础
- 运行时计算生成,使用最多的是动态代理技术
- 有其他文件生成,典型场景:JSP从专有数据库中提取.class文件,比较少见
- 从加密文件中获取,典型的防Class文件被反编译的保护措施
链接阶段
1、验证Verify
目的在于确保Class文件的字节流中包含信息符合当前虚拟机的要求,保证加载类的正确性,不会危害虚拟机自身安全
主要包括四种验证:文件格式验证,元数据验证,字节码验证,符号引用验证。
2、准备Prepare
为类变量分配内存并设置该类变量的初始值,即零值
public class HelloApp {
private static int a = 1; // 准备阶段为0,在下个阶段,也就是初始化的时候才是1
public static void main(String[] args) {
System.out.println(a);
}
}
上面的变量a在准备阶段会被赋初始值,但不是1 而是0
这里不包含被final修饰的static值,因为final在编译阶段就会被分配,准备阶段会显示初始化;
这里不会为实例变量分配初始化,因为实例变量会分配在方法区中,而实例变量会随着对象一起分配到Java堆中。
3.解析 Resolve
将常量内的符号引用转化为直接引用的过程
事实上,解析操作往往会伴随着 JVM在执行初始化之后在执行。
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确在《java虚拟机规范》的class文件格式中,直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
解析动作主要针对类或接口,字段、类方法、接口方法、方法类型。对应常量池的CONSTANT Class info、CONSTANT Filedref info,CONSTANT Methodref info等。
初始化阶段
初始化阶段就是执行类构造器方法的过程
此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
- 也就是说,当代码块中有static变量的时候,就会有clinit方法
构造器方法中指令按语句在源文件出现的顺序执行。
()不同于类的构造器。(关联:构造器是虚拟机视角下的())若该类具有父类,JVM会保证子类的()执行前,父类的()已经执行完毕。
- 任何一个类在声明后,都有生成一个构造器,默认是空参构造器
public class ClassInitTest {
private static int num = 1;
static {
num = 2;
number = 20;
System.out.println(num);
System.out.println(number); //报错,非法的前向引用
}
private static int number = 10;
public static void main(String[] args) {
System.out.println(ClassInitTest.num); // 2
System.out.println(ClassInitTest.number); // 10
}
}
关于涉及父类时候的变量赋值过程
public class ClinitTest1 {
static class Father {
public static int A = 1;
static {
A = 2;
}
}
static class Son extends Father {
public static int b = A;
}
public static void main(String[] args) {
System.out.println(Son.b);
}
}
输出结果为2,首先加载ClinitTest1的时候,会找到main方法,然后执行Son的初始化,但是Son继承Father的加载过程,首先看到原来被赋值成1,然后被赋值成2,最后返回
iconst_1
putstatic #2 <com/atguigu/java/chapter02/ClinitTest1KaTeX parse error: Expected 'EOF', got '#' at position 30: …st_2 putstatic #̲2 <com/atguigu/…Father.A>
return
虚拟机必须保证一个类的()方法在多线程下被同步加锁。
public class Demo01{
public static void main(String[] args) {
Runnable r=()->{
System.out.println(Thread.currentThread().getName()+"开始");
DeadThread t = new DeadThread();
System.out.println(Thread.currentThread().getName()+"结束");
};
Thread t1=new Thread(r,"线程一");
Thread t2=new Thread(r,"线程二");
t1.start();
t2.start();
}
}
class DeadThread{
static {
if(true){
System.out.println(Thread.currentThread().getName()+"初始化当前类");
while(true){
}
}
}
}
运行结果:
线程一开始
线程二开始
线程一初始化当前类
只能执行一次初始化,也就是同步加锁的过程
加载器的分类
JVM支持两种类型的类加载器。分别是引导类加载器(Bootstrap ClassLoader)和用户自定义类加载器 (User-Defined ClassLoader)
从概念上讲,自定义类加载器一般是指程序中开发人员自定义的一种类加载器。但是java虚拟机规范却没有这样定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
最常见的类加载器有三类:
这四者是包含关系,不是上下级关系,也不是子系统的继承关系
通过一个类获取他的加载器:
public class ClassLoaderTest {
public static void main(String[] args) {
// 获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader);
// 获取其上层的:扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader);
// 试图获取 根加载器
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader);
// 获取自定义加载器
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader);
// 获取String类型的加载器
ClassLoader classLoader1 = String.class.getClassLoader();
System.out.println(classLoader1);
}
}
得到的结果,从结果可以看出,根加载器无法通过代码获取,同时目前用户所使用的的加载器为系统类加载器。同时我们通过获得String类型加载器,发现是null,那么说明String类型是通过根加载器进行加载的,也就是说Java的核心类库都是使用根加载器进行加载的。
sun.misc.Launcher A p p C l a s s L o a d e r @ 18 b 4 a a c 2 s u n . m i s c . L a u n c h e r AppClassLoader@18b4aac2 sun.misc.Launcher AppClassLoader@18b4aac2sun.misc.LauncherExtClassLoader@1540e19d
null
sun.misc.Launcher$AppClassLoader@18b4aac2
null
虚拟机自带的加载器
启动类加载器(引导类加载器,Bootstrap ClassLoader)
- 这个类加载是C/C++语言实现的,嵌套在JVM内部。
- 它是用来加载Java的核心库(JAVAHOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
- 并不是继承java.lang.ClassLoader,没有父类加载器
- 加载扩展类和应用程序类加载器,并指明他们的父类加载器。
- 出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
扩展类加载器(Extension ClassLoader)
- Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。
- 派生于ClassLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下载类库。如果用户创建jar包放在此目录下,也会自动由扩展类加载器加载。
应用程序类加载器(系统类加载器,AppClassLoader) - java语言编写,由sun.misc.LaunchersAppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 他负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类的加载是程序中默认的类加载器,一般来说java应用的类都是由他加载完成的
- 通过ClassLoader#getSystemClassLoader()方法可以获取到该类的加载器
用户自定义类加载器
在Java的日常程序开发中,类的加载几乎是由上述三种加载器相互配合执行,在必要时,我们还可以自定义加载器,来制定类的加载方式。
自定义加载器的作用: - 隔离加载类
- 修改类的加载方式
- 扩展加载源
- 防止源码泄露
用户自定义类加载器的实现步骤: - 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式,实现自己类加载器,以满足一些特殊的需求
- 在JDK1.2之前,在自定义类加载器时,总会继承ClassLoader类并重写loadClass()方法,而是建议直接继承URIClassLoader类,这样就可以避免自己去加载findclass()方法获取字节码流的方式,使自定义类加载器编写更加简洁。
查看根加载器所能加载的目录
根加载器只能加载java/lib目录下的class。
public class ClassLoaderTest1 {
public static void main(String[] args) {
System.out.println("*********启动类加载器************");
// 获取BootstrapClassLoader 能够加载的API的路径
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
System.out.println(url.toExternalForm());
}
// 从上面路径中,随意选择一个类,来看看他的类加载器是什么:得到的是null,说明是 根加载器
ClassLoader classLoader = Provider.class.getClassLoader();
}
}
得到结果:
file:/E:/Software/JDK1.8/Java/jre/lib/resources.jar
file:/E:/Software/JDK1.8/Java/jre/lib/rt.jar
file:/E:/Software/JDK1.8/Java/jre/lib/sunrsasign.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jsse.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jce.jar
file:/E:/Software/JDK1.8/Java/jre/lib/charsets.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jfr.jar
file:/E:/Software/JDK1.8/Java/jre/classes
null
关于ClassLoader
ClassLoader类,它是一个抽象类,其后所有的加载器都继承自ClassLoader(不包括启动类加载器)
sun.misc.Launcher它是java虚拟机的入口应用:
获取CLassLoader的路径
- 获取当前ClassLoader:clazz.getClassLoader()
- 获取当前线程上下文的Classloader:Thread.currentThread().getContextClassLoader()
- 获取系统的ClassLoader:ClassLoader.getSystemClassLoader()
- 获取调用者的ClassLoader:DriverManager.getClallerClassLoader()
双亲委派机制
- 如果一个类加载器收到了一个类加载请求,他并不会自己去加载,而是委托给父类的加载器去执行。
- 如果父类加载器还存在其父类加载器,则会进一步向上委托,依次递归,请求将最终达到启动类加载器
- 如果父类的加载器可以完成加载任务,就成功返回,倘若父类加载器无法完成加载任务,子类加载器才会自己尝试去加载,这就是双亲委派机制。
双亲委派机制举例
当我们加载jdbc.jar 用于实现数据库连接的时候,首先我们需要知道的是 jdbc.jar是基于SPI接口进行实现的,所以在加载的时候,会进行双亲委派,最终从根加载器中加载 SPI核心类,然后在加载SPI接口类,接着在进行反向委派,通过线程上下文类加载器进行实现类 jdbc.jar的加载。
沙箱安全机制
如:自定义的String类的时候会率先使用引导类加载器加载,而引导类加载器在加载过程中会先加载jdk自带的文件(rt.jar包中java/lang/String.class),报错信息中说没有main方法,就是因为加载的是rt.jar中的String类。这样可以保证对java核心代码的保护这就是沙箱安全机制。
双亲委派机制的好处
- 避免类的重复加载
- 保护程序安全,防止核心API被修改
- 自定义类java.lang.string
- 自定义类java.lang.ShkStart(阻止创建java.lang包下的类)
其他
如果判断两个class是否相同
在JVM中表示两个class对象是否为同一个类存在两个必要条件
- 类的完整类名必须一致
- 加载这个类的ClassLoader必须一致(指Classloader对象)必须相同
在jvm中如果两个类对象(class)来源于同一个class文件,被同一个虚拟机所加载,但只要加载他们的Classloader实例对象不同,那么这两个类对象也是不同的。
JVM必须知道一个类型是由启动类加载器加载的还是由用户类加载器加载的。如果同一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类信息的一部分保存在方法中当解析一个类型到另一个类型的时候,JVM必须保证这两个类型的类加载器是相同的。
类的主动使用和被动使用
- 创建类的实例
- 访问某个类或接口的静态变量,或者对该静态变量赋值
- 调用类的静态方法
- 反射:(比如:Class.forName(“com.cc.Demo01”))
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK开始启动动态语言的支持
- java.lang.invoke.MethodHandle实例的解析结果REF getStatic、REF putStatic 、REF invokeStatic句柄对应的类没有被初始化,则初始化
注:除以上七种情况,其他使用java类的方式都被看做对类的被动使用,不会导致类的初始化。