龙空技术网

JVM类加载

好想做点什么 150

前言:

此刻各位老铁们对“cmd中javac找不到文件”可能比较关心,大家都需要学习一些“cmd中javac找不到文件”的相关知识。那么小编也在网摘上搜集了一些关于“cmd中javac找不到文件””的相关资讯,希望兄弟们能喜欢,朋友们一起来学习一下吧!

类的生命周期

加载,验证,准备,初始化,卸载 这五个阶段先后顺序是确定的。但是解析阶段不一定:它在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定(动态绑定或晚期绑定)。

静态绑定:在程序执行前方法已经被绑定(也就是说在编译过程中就已经知道这个方法到底是哪个类中的方法),此时由编译器或其它连接程序实现。 所有私有方法、静态方法、构造器及初始化方法<clinit>都是采用静态绑定机制。在编译器阶段就已经指明了调用方法在常量池中的符号引用,JVM运行的时候只需要进行一次常量池解析即可。

动态绑定:动态绑定(后期绑定)是指:在程序运行过程中,根据具体的实例对象才能具体确定是哪个方法。通俗的是指,对象在调用方法的时候能够自己判断该调用谁的方法。所以动态绑定一般发生在继承、方法重载时。 假设,对象o是类C1的实例,其中C1是C2的子类,C2是C3的子类,那么o也是C2,C3的实例。如果对象o调用一个方法p,JVM会依次在类C1,C2,C3中查找方法p的实现,直到找到为止。类对象方法的调用必须在运行过程中采用动态绑定机制: 首先,根据对象的声明类型(对象引用的类型)找到“合适”的方法。具体步骤如下: ① 如果能在声明类型中匹配到方法签名完全一样(参数类型一致)的方法,那么这个方法是最合适的。 ② 在第①条不能满足的情况下,寻找可以“凑合”的方法。标准就是通过将 参数类型进行自动转型之后再进行匹配。如果匹配到多个自动转型后的 方法签名f(A)和f(B),则用下面的标准来确定合适的方法:传递给f(A) 方法的参数都可以传递给f(B),则f(A)最合适。反之f(B)最合适 。 ③ 如果仍然在声明类型中找不到“合适”的方法,则编译阶段就无法通过。 然后,根据在堆中创建对象的实际类型找到对应的方法表,从中确定具体的方法在内存中的位置。
JVM规范没有强制约束 加载 过程何时开始,这部分可以由虚拟机的具体实现自由把握。但是对于初始化阶段,虚拟机规范严格规定了有且只有 5种情况 必须立即对类进行初始化操作(加载 验证 准备自然要在此之前开始)。遇到new、getstatic、putstatic、invokestatic四条字节码指令时,如果类没有进行初始化,则必须先触发其初始化操作。使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发初始化操作。当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。但是接口在初始化时,并不要求其父接口全部完成了初始化,只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化。虚拟机启动时,用户需要制定一个要执行的主类,虚拟机会先初始化这个主类当使用JDK1.7 的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic,REF_putStatic,REF_invokeStatic的方法句柄时,并且这个句柄对应的类没有进行初始化,虚拟机需要先触发其初始化操作。

类加载过程

加载

加载阶段虚拟机需要完成以下3件事情:

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

对于数组类而言,情况就有所不同,数组本身不通过类加载器创建,它是由虚拟机直接创建的。但是数组类和类加载器仍有密切联系,因为数组类的元素类型最终是要靠类加载器去创建的。

数组类创建规则:

如果数组的元素类型是引用类型,那就使用系统提供的或者用户自定义的类加载器去加载。该数组将在 加载数组元素类型 的类加载器 的类命名空间上被标识。(一个类必须与类加载器一起确定唯一性)如果数组的元素类型不是引用类型(如 int[] 数组),虚拟机会把该数组标记为与引导类加载器关联。数组类的可见性和数组元素类型可见性一致,如果元素类型不是引用类型,那么可见性默认为public。

加载完成后:

虚拟机将外部二进制字节流按照虚拟机所需的格式存储在方法区之中,方法区的数据存储格式由虚拟机自行实现。然后在内存中实例化一个java.lang.Class对象(Class对象比较特殊,它虽然是对象,但是存放在方法区中),这个对象将作为程序访问方法区中类型数据的外部接口。

加载阶段和连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的,加载阶段尚未完成,连接阶段可能已经开始,但这些夹在加载阶段进行的动作,仍属于连接阶段的内容。

验证

验证是连接阶段的第一步,这一阶段是为了确保Class文件的字节流中包含的信息符合当前虚拟机得到要求,不会危害虚拟机自身的安全。

验证阶段大致会完成4个阶段的动作:

文件格式验证是否以魔数0xCAFEBABE开头主次版本号是否在当前虚拟机处理范围之内常量池的常量中是否有不被支持的常量类型 。。。。。

验证点还有很多,这里不一一列举。该验证阶段主要保证输入的字节流能正确地解析并存储于方法区之内,格式上符合一个描述Java类型信息的要求。

这阶段的验证是基于二进制字节流进行的,只有通过了这个阶段的验证后,字节流才会进入内存的方法区进行存储,后面的验证阶段全部是基于方法区的存储结构进行的,不会再直接操作部字节流。

元数据验证

此阶段是对类的元数据信息进行语义分析,以保证其描述的信息符合Java语言规范的要求。

此阶段部分验证点如下:

- 这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)- 这个类的父类是否继承了不允许被继承的类(被final修饰的类)- 如果这个类不是抽象类,是否实现了其父类或接口中要求实现的所有方法。。。。。
字节码验证

此阶段是验证阶段最复杂的一个阶,主要目的是通过数据流和控制流分析,确定程序语义是合法的,符合逻辑的。此阶段对类的方法体进行校验分析,保证校验的类在运行时不会做出危害虚拟机安全的事件。

在JDK1.7之后,对于主版本号大于50的Class文件,使用类型检查来完成数据流分析校验则是唯一选择,不允许退回类型推导的校验方式。

符号引用验证

此阶段的验证发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三阶段----解析阶段中发生。符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验。

符号引用验证的目的是确保解析动作能正常执行,如果无法通过符号引用验证,将抛出java.lang.IncompatibleClassChangeError异常的子类。

对于虚拟机来说,验证阶段是一个非常重要,但不是一定必要的阶段。如果运行的代码经过反复使用和验证,那么在实施阶段可以考虑使用 -Xverify:none 参数来关闭大部分的验证措施,缩短类加载时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的的内存在方法区中被分配。

此阶段进行内存分配的仅包括类变量(static修饰),而不包括实例变量,实例变量将会在对象实例化时分配在堆中。此外,这里的初始值是数据类型的零值。但是被 final修饰的类变量 会直接用程序中定义的值进行值初始化。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。其中解析过程在某些情况下可以在初始化阶段之后再开始,这是为了支持 Java 的动态绑定。

符号引用:符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要能够使用时能无歧义地定位到目标即可。直接引用:直接引用是可以直接指向目标的指针,相对偏移量或是一个能间接定位到目标的句柄。

初始化

初始化阶段是执行类构造器<clinit()>方法的过程

<clinit()>方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块(static{})中的语句结合并产生的。编译器收集顺序是由语句在源代码中出现的顺序决定的,静态语句块中只能访问到定义静态语句块之前的变量。定义在它之后的变量,静态语句块可以赋值,但不能访问。<clinit()>方法和类的构造函数(实例构造器<init()>)不同,它不需要显示地调用父类构造器,虚拟机会保证子类的<clinit()>方法执行之前,父类的<clinit()>方法已经执行完毕。所以虚拟机第一个执行的<clinit()>方法肯定是java.lang.Object。<clinit()>方法对于类或接口来说并不是必需的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit()>方法。接口中不能使用静态语句块,但仍然有变量初始化的赋值操作,因此接口和类一样都会生成<clinit()>方法。但是接口与类不同,执行接口的<clinit()>方法不需要先执行父接口的<clinit()>方法。只有当父接口中定义的变量使用时,父接口才会初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit()>方法。虚拟机会保证一个类的<clinit()>方法在多线程环境中被正确地加锁、同步,如果多个线程同时初始化一个类,那么只会有一个线程去执行类的<clinit()>方法,其他线程需要阻塞等待。

类加载器

对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性,每个类加载器都有一个独立的命名空间。

比较两个类是否相等:只有这两个类是由同一个类加载器加载的前提下才有意义。

双亲委派模型

启动类加载器(Bootstrap ClassLoader):这个类负责将存放在<JAVA_HOME>\lib 目录中的,或者被 -Xbootclasspath 参数所指定的路径中的,并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法直接被Java程序引用,如果需要把加载请求委派给引导类加载器,直接使用null代替即可。扩展类加载器(Extension ClassLoader):这个类加载器是由 ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的。它负责将 <JAVA_HOME>/lib/ext 或者被 java.ext.dir 系统变量所指定路径中的所有类库加载到内存中,开发者可以直接使用扩展类加载器。应用程序加载器(Application ClassLoader):这个类加载器是由 AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,因此一般称为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

工作过程:

一个类加载器首先将类加载请求转发到父类加载器,只有当父类加载器无法完成时才尝试自己加载。

//双亲委派模型的工作过程源码protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{ // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader //父类加载器无法完成类加载请求 } if (c == null) { // If still not found, then invoke findClass in order to find the class //子加载器进行类加载 c = findClass(name); } } if (resolve) { //判断是否需要链接过程,参数传入 resolveClass(c); } return c;}

(1)当前类加载器从自己已经加载的类中查询是否此类已经加载,如果已经加载则直接返回原来已经加载的类。

(2)如果没有找到,就去委托父类加载器去加载(如代码c = parent.loadClass(name, false)所示)。父类加载器也会采用同样的策略,查看自己已经加载过的类中是否包含这个类,有就返回,没有就委托父类的父类去加载,一直到启动类加载器。因为如果父加载器为空了,就代表使用启动类加载器作为父加载器去加载。

(3)如果启动类加载器加载失败(例如在$JAVA_HOME/jre/lib里未查找到该class),则会抛出一个异常ClassNotFoundException,然后再调用当前加载器的findClass()方法进行加载。

自定义类加载器

自定义类加载器的应用场景:

(1)加密:Java代码可以轻易的被反编译,如果你需要把自己的代码进行加密以防止反编译,可以先将编译后的代码用某种加密算法加密,类加密后就不能再用Java的ClassLoader去加载类了,这时就需要自定义ClassLoader在加载类的时候先解密类,然后再加载。

(2)从非标准的来源加载代码:如果你的字节码是放在数据库、甚至是在云端,就可以自定义类加载器,从指定的来源加载类。

(3)以上两种情况在实际中的综合运用:比如你的应用需要通过网络来传输 Java 类的字节码,为了安全性,这些字节码经过了加密处理。这个时候你就需要自定义类加载器来从某个网络地址上读取加密后的字节代码,接着进行解密和验证,最后定义出在Java虚拟机中运行的类。

自定义类加载器:

自定义一个People.java类做例子

public class People {//该类写在记事本里,在用javac命令行编译成class文件,放在d盘根目录下 private String name; public People() {} public People(String name) { 	this.name = name; } public String getName() { 	return name; } public void setName(String name) { 	this.name = name; } public String toString() { 	return "I am a people, my name is " + name; }}

自定义一个类加载器,需要继承ClassLoader类,并实现findClass方法。其中defineClass方法可以把二进制流字节组成的文件转换为一个java.lang.Class(只要二进制字节流的内容符合Class文件规范)。

import java.io.ByteArrayOutputStream;import java.io.File;import java.io.FileInputStream;import java.nio.ByteBuffer;import java.nio.channels.Channels;import java.nio.channels.FileChannel;import java.nio.channels.WritableByteChannel;public class MyClassLoader extends ClassLoader{ public MyClassLoader() { } public MyClassLoader(ClassLoader parent) { super(parent); } protected Class<?> findClass(String name) throws ClassNotFoundException { 	File file = new File("D:/People.class"); try{ byte[] bytes = getClassBytes(file); //defineClass方法可以把二进制流字节组成的文件转换为一个java.lang.Class Class<?> c = this.defineClass(name, bytes, 0, bytes.length); return c; } catch (Exception e) { e.printStackTrace(); } return super.findClass(name); } private byte[] getClassBytes(File file) throws Exception { // 这里要读入.class的字节,因此要使用字节流 FileInputStream fis = new FileInputStream(file); FileChannel fc = fis.getChannel(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); WritableByteChannel wbc = Channels.newChannel(baos); ByteBuffer by = ByteBuffer.allocate(1024); while (true){ int i = fc.read(by); if (i == 0 || i == -1) break; by.flip(); wbc.write(by); by.clear(); } fis.close(); return baos.toByteArray(); }}

在主函数里使用

MyClassLoader mcl = new MyClassLoader();Class<?> clazz = Class.forName("People", true, mcl);Object obj = clazz.newInstance();System.out.println(obj);System.out.println(obj.getClass().getClassLoader());//打印出我们的自定义类加载器

标签: #cmd中javac找不到文件