12.1 Java类加载器介绍
类加载器负责把类加载到Java虚拟机(JVM)中。指定类的名称,类加载器就会定位这个类的定义,每一个Java类必须由类加载器加载。
当启动JVM的时候,可以使用三个类加载器:引导(bootstrap)类加载器、扩展(extensions)类加载器、应用程序(application)类加载器。
1.引导类加载器仅仅负责加载核心的Java库,比如位于<JAVA_HOME>/jre/lib 目录下的vm.jar,core.jar。这个类加载器,是JVM核心部分,是用native代码写成的。
2. 扩展类加载器负责加载扩展路径下的代码,一般位于<JAVA_HOME>/jre/lib/ext 或者通过java.ext.dirs 这个系统属性指定的路径下的代码。这个类加载器是由sun.misc.Launcher$ExtClassLoader 实现的。
3.应用程序类加载器负责加载java.class.path(映射系统参数 CLASSPATH的值) 路径下面的代码,这个类加载器是由 sun.misc.Launcher$AppClassLoader 实现的。
当处理类加载器时,父委托模式是一个需要理解的关键概念。它规定:类加载器在加载自己的类之前,可以委托先加载父类。父类加载器可以是客户化的类加载器或者引导类加载器。但是有一点很重要,类加载器只能委托自己的父类加载器,而不能是子类加载器(只能向上不能向下)。
扩展类加载器是应用程序类加载器的父亲。类加载器的层次图见图12-1 。
图12-1 类加载器层次图
如果应用程序类加载器需要加载一个类,它首先委托扩展类加载器,扩展类加载器再委托引导类加载器。如果父类加载器不能加载类,子类加载器就回在自己的库中查找这个类。基于这个特性,类加载器只负责它的祖先无法加载的类。
如 果类加载器加载一个类,这个类不是在类加载器树上的叶子节点上,就会出现一些有趣的问题。比如例12-1,一个名为WhichClassLoader1 的类加载了一个名为WhichClassLoader2类,WhichClassLoader2又调用了名为WhichClassLoader3的类。
例12-1 WhichClassLoader1 和 WhichClassLoader2 源代码
public class WhichClassLoader1 {
public static void main(String[] args) throws javax.naming.NamingException
{
// Get classpath values
String bootClassPath = System.getProperty(“sun.boot.class.path”);
String extClassPath = System.getProperty(“java.ext.dirs”);
String appClassPath = System.getProperty(“java.class.path”);
// Print them out
System.out.println(“Bootstrap classpath =” + bootClassPath + “n”);
System.out.println(“Extensions classpath =” + extClassPath + “n”);
System.out.println(“Application classpath=” + appClassPath + “n”);
// Load classes
Object bj = new Object();
WhichClassLoader1 wcl1 = new WhichClassLoader1();
WhichClassLoader2 wcl2 = new WhichClassLoader2();
// Who loaded what?
System.out.println(“Object was loaded by “
+ obj.getClass().getClassLoader());
System.out.println(“WCL1 was loaded by “
+ wcl1.getClass().getClassLoader());
System.out.println(“WCL2 was loaded by “
+ wcl2.getClass().getClassLoader());
wcl2.getTheClass();
}
}
======================================================================
public class WhichClassLoader2 {
// This method is invoked from WhichClassLoader1
public void getTheClass() {
WhichClassLoader3 wcl3 = new WhichClassLoader3();
System.out.println(“WCL3 was loaded by “
+ wcl3.getClass().getClassLoader());
}
}
如 果所有的WhichClassLoaderX 类都放在应用程序的类路径下,三个类就会被应用程序类加载器加载,这个例子就会运行正常。现在假定把WhichClassLoader2 类文件打包成JAR文件放在<JAVA_HOME>/jre/lib/ext 目录下,运行WhichClassLoader1,就会看到例12-2的输出:
例12-2 NoClassDefFoundError 异常跟踪
Bootstrap classpath
=C:WebSphereAppServerjavajrelibvm.jar;C:WebSphereAppServerjavajrelib
core.jar;C:WebSphereAppServerjavajrelibcharsets.jar;C:WebSphereAppServ
erjavajrelibgraphics.jar;C:WebSphereAppServerjavajrelibsecurity.jar;C
:WebSphereAppServerjavajrelibibmpkcs.jar;C:WebSphereAppServerjavajre
libibmorb.jar;C:WebSphereAppServerjavajrelibibmcfw.jar;C:WebSphereAppS
erverjavajrelibibmorbapi.jar;C:WebSphereAppServerjavajrelibibmjcefw.j
ar;C:WebSphereAppServerjavajrelibibmjgssprovider.jar;C:WebSphereAppServ
erjavajrelibibmjsseprovider2.jar;C:WebSphereAppServerjavajrelibibmjaa
slm.jar;C:WebSphereAppServerjavajrelibibmjaasactivelm.jar;C:WebSphereAp
pServerjavajrelibibmcertpathprovider.jar;C:WebSphereAppServerjavajreli
bserver.jar;C:WebSphereAppServerjavajrelibxml.jar
Extensions classpath =C:WebSphereAppServerjavajrelibext
Application classpath=.
Exception in thread “main” java.lang.NoClassDefFoundError: WhichClassLoader3
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
at WhichClassLoader1.main(WhichClassLoader1.java:17)
正如所看到的,由于WhichClassLoader3 在应用程序类路径下,程序失败,收到一个NoClassDefFoundError 的异常,这看起来有些奇怪。问题在于:它现在在一个错误的类路径下面。当WhichClassLoader2被扩展类加载器加载的时候,发生了什么呢?实 际上,应用程序类加载器委托扩展类加载器加载WhichClassLoader2,扩展类加载器又委托引导类加载器。由于引导类加载器找不到这个类,类加 载的控制就会返回给扩展类加载器。扩展类加载器在自己的路径下找到了这个类将它加载。现在,当一个类已经被类加载器加载后,这个类需要的任何其他的新类都 必须用同一个类加载器加载他们(或者遵循父委托模式,由父类加载器加载)。所以当WhichClassLoader2 需要访问WhichClassLoader3 的时候,扩展类加载器就会获得这个请求去加载WhichClassLoader3,扩展类加载器先委托引导类加载器,但是引导类加载器找不到这个类,于是 扩展类加载器便试图装入自身但是也找不到这个类,原因是WhichClassLoader3不在扩展类路径而是在应用程序类路径。由于扩展类加载器无法委 托应用程序类加载器,所以就会出现NoClassDefFoundError 的异常。
注意:开发者通常会使用如下语法通过类加载器机制加载属性文件:
Properties p = new Properties();
p.load(MyClass.class.getClassLoader().getResourceAsStream(“myApp.properties”
));
这个意思是:如果MyClass 由扩展类加载器加载,而 myApp.properties 文件只能应用程序类加载器看到,则装入属性文件就会失败。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
Java性能优化的最差实践
关于Java性能优化的方法已经有很多文章讨论过,其中总有一些不值得提倡甚至应该杜绝的方法,需要让开发者时刻保持警觉。
-
JVM垃圾收集器使用调查:CMS最受欢迎
近日,Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究,研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中,并发收集器(CMS)使用次数最多。
-
为什么说Azul Systems是微软Azure云的最好选择?
当负责Azure云的微软朋友们决定,是时候慎重考虑拥抱企业Java社区时,他们知道他们需要做的第一步是,在他们的平台上引入世界级的Java运行时环境的实现。
-
如何让代码并发效率更高
开发人员正在利用多线程技术努力提高软件计算速度,本文介绍了如何让代码并发效率更高的实践经验。