Java类生命周期:
这样设计符合面向对象的开闭原则和封装特性,JVM将类加载内部复杂的实现封装起来,拒绝上层开发者修改,只提供了一个拓展接口用于class文件二进制流的读取,上层开发人员用这个接口实现了动态代理,热部署等功能。
1.类加载器的分类
类加载器的分类属于JVM规范,是一种抽象概念,各个jvm的实现方式是不一定一样的,JVM规范中类加载器分为两部分,分为启动类加载器和非启动类加载器,这里只讲最常见的hotstop虚拟机,在hotstop中分为BOOTstrap类加载器和非BOOTstrap类加载器。
简单介绍一下这三种类加载器的区别,他们都继承自Java.lang.ClassLoader类,都可以作为对象被引用。我们平时写的代码都是用APPlication ClassLoader加载的,上面两种类加载器都只能从本地文件中获取字节码进行加载,而User ClassLoader可以获取任何来源的字节码并进行加载,也就是说,在java类加载机制中允许类从各个渠道获取二进制流进行加载。
JVM中的类的加载器主要有三种:启动类加载器,拓展类加载器,应用类加载器。
启动类加载器(Bootstrap classLoader):又称为引导类加载器,由C++编写,无法通过程序得到。主要负责加载JAVA中的 一些核心类库,主要是位于<JAVA_HOME>/lib/rt.jar中。
拓展类加载器(Extension classLoader):主要加载JAVA中的一些拓展类,位于<JAVA_HOME>/lib/ext中,是URLClassLoader的子类。
应用类加载器(System classLoader): 又称为系统类加载器,主要用于加载CLASSPATH路径下我们自己写的类,是拓展类 。
比如我们自己写了一个类Student类,经过编译后会得到Student.class文件,然后经过类加载器得到Class实例,例如通过
Class.forName("com.***.Student"),通过全路径加载进来。然后我们用Student.class.getClassLoader()得到它的类加载器,得到的是AppClassLoader(即系统类加载器),如果用Student.class.getClassLoader().getParent()得到的是它的父加载器ExtClassLoader(即拓展类加载器),然后用Student.class.getClassLoader().getParent().getParent()得到将会是Null,因为启动类加载器是用C++写的,我们无法通过程序直接得到.
常见问题:
1.Object类是由哪个类加载器加载的?
BootStrap ClassLoader
2.我们自己写的类是由哪个类加载器加载的?
System ClassLoader
3.类加载器都是我们Java中的一个类ClassLoader的子类吗?
BootStrap ClassLoader不是的,另外两个是的。
类加载器的三大特性:委托性、可见性、单一性
委托性:每个类中都有一个自己的类加载器的属性,这也就是为什么可以通过Student.class.getClassLoader()来 获取自己的类加载器。当一个类加载器要加载一个类时,它会先委托自己的父类加载器来加载,只有当父加载器无法加载类时,才会自己去加载。例如我们写了一个类Student,它的类加载器是System ClassLoader,它首先会委托给它的父加载器即Extension ClassLoader,然后Extension ClassLoader又会委托给它的父加载器BootStrap ClassLoader,启动类加载器无法加载这个类,交给拓展类加载器,拓展类加载器也无法加载,然后才轮到系统类加载器进行加载。
可见性:可见性指的是父加载器无法利用子加载器加载的类,而子加载器可以利用父加载器加载的类。
单一性:一个类只会被一个类加载器加载一次,不会被重复加载。
我们自己也可以写自己的类加载器以满足自己特定的要求,只要实现ClassLoader这个类即可,但是要满足上面所说的类加载器的三种特性。
两个问题:
jvm规范中说:每个类加载器都有属于自己的命名空间。简单来说,即使用不同的类加载器加载了同一个限定名的类,JVM会认为这是两个不同的类,举个例子
首先使用匿名类的方式实现了UserClassLoader,重写了loadclass方法,(loadclass方法的内容就是直接从文件中读取class文件,然后调用父类的defineclass方法进行后续的加载操作,最后使用加载输出的class进行对象的实例化,并且对产生的对象进行类行判断)
这里可以看到对象的类行名是一样的,但结果输出的是false;因为我们自定义的类分别被APPlication类加载器和我们自定义的UserClassLoader加载了,JVM认为这是俩个完全不一样的类,这就验证了每个类加载器都有属于自己的命名空间。这就可能给程序的开发和维护带来很大的困扰,目前jvm有效的避免了这个问题,使用了双亲委派机制。
面对上述情况我们现在的需求是:在默认情况下~
解释:在被动情况下,当一个类收到一个加载请求,他不会主动去加载,而是交给自己的父类加载,这样所有的类都会首先传递到最上层的Bootstrap ClassLoader,只有父亲加载器无法完成加载,儿子加载器才会尝试加载,(什么叫无法加载?就是根据类的限定名,类加载器没有在自己负责的加载路径中找到该类,注意,这里说的是父亲加载器儿子加载器,不是父类子类加载,这里的传递不是继承关系,是通过组合的方式实现的)
2,双亲委派源码(双亲委派具体实现)
看java.lang.classloader中的findloaderclass方式,首先检车该类是否已经被加载了,如果没有就开启加载流程,如果有就直接读取缓存,parent变量代表当前Classloader的父亲加载器,如果parent==null,约定parent为bootstrap classloader,调用findbootstrapclassornull方法,让bootstrap classloader尝试加载,如果parent不为null,就让parent根据限定名尝试加载该类并返回class对象,如果返回的class对象是null,就说明parent没有能力加载这个类,就调用findclass,findclass表示如何去寻找该限定命名的class,需要各个类加载器自己实现。
开始的两个问题:
3.破坏双亲委派模型
3.1第一次破坏
双亲委派模型可以被破环,例如上图,可以重写java.lang.classloader中的loadclass方法,但双亲委派的逻辑就是存在这个方法里面的,这样双亲委派模型可以被破环。
JVM的开发者为什么不把这个方法设置成final,禁止程序员重写呢?
java.lang.classloader中的loadclass方法在jvm很早的版本就有了,双亲委派是jdk1.2引入的特性,java是向下兼容的,在引入双亲委派的时候,loadclass方法已经被重新很多次了,一点补救措施就是推荐使用findclass而不是直接重写loadclass方法。
3.2第二次破坏
举个例子:jdk想要提供操作数据库的功能,数据库有很多种,jdk不可能把操作所有数据库的代码都一一实现,(比较合理的是jdk提供一组规范(一组接口),各个不同的数据库厂商自己实现自己的类库,这里问题就出现了对jdk包中的加载肯定是使用的上层的类加载器,比如ootstrap ClassLoader,但当调用jdk的接口时候,接口所在的类将会引起第三方类库的加载,这就不符合自上而下的委派加载顺序了,会出现上层类加载器去调用下层类加载器的行为。
3.3 第三次破环
模块化热部署的关键是自定义类加载器机制,更换Bundle(程序模块)时,类加载器也会被换掉,然而类加载机制与双亲委派机制不同。