Java高级之虚拟机加载机制

更新时间:2017-11-28 10:12:12 点击次数:1410次

都知道Jvm要加载的是二进制流,可以是.class文件形式,也可以是其他形式,总之按照它加载的标准来设计就不会有太大问题,以下主要就机制和标准两个问题分析一番

首先来说 Java类文件的加载机制 ,跟变量的加载机制类似,它先把Class文件加载入内存,再对数据进行验证、解析和初始化,终形成虚拟机可以直接使用的Java类型。由于Java是采用JIT机制,所以加载时会比较慢,但优点也明显,具有高度灵活性,支持动态加载和动态连接。接下来就讲讲类的加载过程:

一个 类加载的基本过程是按照下面的顺序 来,但也有不严格按照这个顺序来的,也有打乱顺序来的,如动态加载就得先初始化再解析。

1、加载- 由虚拟机自行决定,但也有由于下面的阶段要执行而执行上面阶段的情况。这时虚拟机会做三件事,、通过全限定名读取文件的二进制流,第二、把文件里的静态方法和变量放到方法区中,第三、生成一个对象放入堆中,作为访问入口。注意条,仅是读取二进制流,没说具体从什么文件中读,也没说从哪里读,所以造就Java很强的扩展性,可以从Jar、Zip中,也可以从网络层、数据库层等 。主要是对象和方法区的声明。

2、验证 确保二进制流符合虚拟机的要求, 不符合会报VerifyError。 、文件格式验证,是否有魔数,是否符合Java文件的要求,详见: Java高级之类结构的认识 ;第二、元数据验证,是否符合Java代码规范,如abstract类是否直接被实例化,普通类有无间接或直接父类Object等;第三、字节码验证,对数据流和控制流进行分析,保证不会做出危害虚拟机的行为,如 是否调用不存在的指令,是否把父类赋值给子类,是否把对象赋值给一个非此类型的对象等;第四、符号引用验证,主要是类、变量、方法描述是否能找的到,如全限定名是否能找到该文件,是否具有可访问性等。主要对内部结构的判定

3、准备 为类变量赋初值,通常为0值如静态变量,而不会为实例变量赋值。

4、解析 将常量池中的符号引用转化为直接引用的过程。这里说的符号引用指变量类型,直接引用指可以直接定位到对象的句柄。类、方法、字段、接口解析,根据全限定名获得相关对象,拿到它的类型,若无对所在类访问权会抛出IllegalAccessError,无字段NoSuchFieldError,无方法NoSuchMethodError,是类不是接口会抛出IncompatibleClassChangeError

5、初始化 根据程序要求加载类和必要的资源。有且仅有四种情况,需要主动初始化后才能执行接下来的操作 ,所以要先执行上面的四步。、有new或static关键字的类,new生成对象,static静态加载,这两个很明显要执行初始化了;第二、使用类有父类,这没办法了;第三、反射类里的方法,那肯定要初始化了对不对;第四、执行的主类,用main方法的类。其他被动初始化的情况不需要考虑。

小例子:

public class SuperClass {

static {

System.out.println(“SuperClass!!”);

}

public static int value = 1;

}

public class SubClass extends SuperClass {

static {

System.out.println(“SubClass!!”);

}

}

public class TestClassLoad {

public static void main(String[] args) {

System.out.println(SubClass.value);

SuperClass superClass = new SubClass();

}

}

SuperClass!!

1

SubClass!!

执行结果说明一个问题: 子类调用父类变量的时候 ,子类没有初始化,因为 此时的代码关系跟子类无关 ;子类初始化的时候,父类也没有再初始化,因为 父类在当前方法体中已经初始化 过了。接口与父类的区别在于, 接口初始化不会要求父接口,只有用到父接口才会初始化 ,同样的都会生成类构造器。

这个时候加载类构造器,会初始化类中所有变量,当然父类先于子类初始化

6、使用 加载完之后,该怎么样调用怎么样调用,绘图啊,计算啊等等

7、卸载 类不再被调用

两个类是否相等,主要在于使用同一个加载器加载,第二全限定名地址一致

为什么要提出上面的问题呢?接下来要讲讲虚拟机的一个加载机制。

在虚拟机的角度来看,有两种类加载器,一种叫系统加载器(Bootstrap ClassLoader),一种叫自定义加载器(extends ClassLoader),这种呢又分为两个,一种叫应用加载器,一种叫扩展类加载器,一般默认为前者;而我们的应用程序加载主要由上面三个加载器相互配合完成的。三者的关系如Application–>Extension–>Bootsrap,双亲委派机制是指两两以组合的方式,子加载器先去调用父加载器的方法,没找到目标对象再去用子加载器

伪代码如下:

loadClass(String name,boolean resolve){

Class c=findLoadedClass()

if(c==null){

if(parent !=null)

c=parent.loadClass(name,false);

c=findBootstrapClassOrNull(name);

}catch(ClassNotFoundException e){ }

if(c==null)

c=findClass(name);

}

Java提倡我们去把自己调用类的逻辑写在findClass里,这样有助于双亲委派机制的正常使用。

破坏1、重写loadClass

破坏2、使用线程上下文加载器去让父加载器去调用子加载器的方法

破坏3、热加载 现在常用的做法是 自定义类加载器并 将原bug模块覆盖-OSGI

但由于自定义加载器之间的规则如果混乱,出现同时互相引用的问题,那么会终找不到类,而出现线程死锁和内存泄露的问题。

关于热修复,也被称为插件,目前比较流行的有HotFix、Nuwa、DroidFix、AndFix等,这些框架均可以在github或其他地方找到,原理如上,方法多样,有覆盖的、有重定向的等等,通过配置、设置action等方式;而作为插件需要满足以下条件:

1、可以独立安装,但不可独立运行

2、具有向下兼容性,即可拓展性

3、只能运行在宿主程序中,而且可以被禁用、替换

使用场景包括修复线上bug、做手机皮肤、开发应用商店等系统提供的接口 

本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是一个个人学习交流的平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽,造成漏登,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

回到顶部
嘿,我来帮您!