Java类加载器介绍

lvwenwen

浏览: 955500 次
性别:
来自: 魔都

最近访客更多访客>>

u012363178

林祥纤

pizilike

JimYip

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

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:/WebSphere/AppServer/java/jre/lib/vm.jar;C:/WebSphere/AppServer/java/jre/lib

/core.jar;C:/WebSphere/AppServer/java/jre/lib/charsets.jar;C:/WebSphere/AppServ

er/java/jre/lib/graphics.jar;C:/WebSphere/AppServer/java/jre/lib/security.jar;C

:/WebSphere/AppServer/java/jre/lib/ibmpkcs.jar;C:/WebSphere/AppServer/java/jre/

lib/ibmorb.jar;C:/WebSphere/AppServer/java/jre/lib/ibmcfw.jar;C:/WebSphere/AppS

erver/java/jre/lib/ibmorbapi.jar;C:/WebSphere/AppServer/java/jre/lib/ibmjcefw.j

ar;C:/WebSphere/AppServer/java/jre/lib/ibmjgssprovider.jar;C:/WebSphere/AppServ

er/java/jre/lib/ibmjsseprovider2.jar;C:/WebSphere/AppServer/java/jre/lib/ibmjaa

slm.jar;C:/WebSphere/AppServer/java/jre/lib/ibmjaasactivelm.jar;C:/WebSphere/Ap

pServer/java/jre/lib/ibmcertpathprovider.jar;C:/WebSphere/AppServer/java/jre/li

b/server.jar;C:/WebSphere/AppServer/java/jre/lib/xml.jar

Extensions classpath =C:/WebSphere/AppServer/java/jre/lib/ext

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 文件只能应用程序类加载器看到，则装入属性文件就会失败。

分享到：