类加载的基本机制和过程
运行Java程序,就是执行java这个命令,指定包含main方法的完整类名,以及一个classpath,即类路径。类路径可以有多个,对于直接的class文件,路径是class文件的根目录,对于jar包,路径是jar包的完整名称(包括路径和jar包名)。
Java运行时,会根据类的完全限定名寻找并加载类,寻找的方式基本就是在系统类和指定的类路径中寻找,如果是class文件的根目录,则直接查看是否有对应的子目录及文件;如果是jar文件,则首先在内存中解压文件,然后再查看是否有对应的类。
负责加载类的类就是类加载器,它的输入是完全限定的类名,输出是Class对象。类加载器不是只有一个,一般程序运行时,都会有三个(适用于Java 9之前,Java 9引入了模块化,基本概念是类似的,但有一些变化,限于篇幅,就不探讨了)。
1)启动类加载器
(Bootstrap ClassLoader):这个加载器是Java虚拟机实现的一部分,不是Java语言实现的,一般是C++实现的,它负责加载Java的基础类,主要是<JAVA_HOME>/lib/rt.jar,我们日常用的Java类库比如String、ArrayList等都位于该包内。
2)扩展类加载器
(Extension ClassLoader):这个加载器的实现类是sun.misc.Laun-cher$ExtClassLoader,负责加载Java的一些扩展类,一般是<JAVA_HOME>/lib/ext目录中的jar包。
3)应用程序类加载器
(Application ClassLoader):这个加载器的实现类是sun.misc.Launcher$AppClassLoader,它负责加载应用程序的类,包括自己写的和引入的第三方法类库,即所有在类路径中指定的类。
这三个类加载器有一定的关系,可以认为是父子关系,Application ClassLoader的父亲是Extension ClassLoader,Extension的父亲是Bootstrap ClassLoader。注意不是父子继承关系,而是父子委派关系,子ClassLoader有一个变量parent指向父ClassLoader,在子Class-Loader加载类时,一般会首先通过父ClassLoader加载,具体来说,在加载一个类时,基本过程是:
1)判断是否已经加载过了,加载过了,直接返回Class对象,一个类只会被一个Class-Loader加载一次。
2)如果没有被加载,先让父ClassLoader去加载,如果加载成功,返回得到的Class对象。
3)在父ClassLoader没有加载成功的前提下,自己尝试加载类。
这个过程一般被称为“双亲委派” 模型,即优先让父ClassLoader去加载。为什么要先让父ClassLoader去加载呢?这样,可以避免Java类库被覆盖的问题。比如,用户程序也定义了一个类java.lang.String,通过双亲委派,java.lang.String只会被Bootstrap ClassLoader加载,避免自定义的String覆盖Java类库的定义。
需要了解的是,“双亲委派”虽然是一般模型,但也有一些例外,比如:
1)自定义的加载顺序:
尽管不被建议,自定义的ClassLoader可以不遵从“双亲委派”这个约定,不过,即使不遵从,以java开头的类也不能被自定义类加载器加载,这是由Java的安全机制保证的,以避免混乱。
2)网状加载顺序:
在OSGI框架和Java 9模块化系统中,类加载器之间的关系是一个网,每个模块有一个类加载器,不同模块之间可能有依赖关系,在一个模块加载一个类时,可能是从自己模块加载,也可能是委派给其他模块的类加载器加载。
3)父加载器委派给子加载器加载:
典型的例子有JNDI服务(Java Naming and Directory Interface),它是Java企业级应用中的一项服务,具体我们就不介绍了。
一个程序运行时,会创建一个Application ClassLoader,在程序中用到ClassLoader的地方,如果没有指定,一般用的都是这个ClassLoader,所以,这个ClassLoader也被称为系统类加载器
(System ClassLoader)。
本文暂时没有评论,来添加一个吧(●'◡'●)