理解WAS 6.1的类加载(1)

日期: 2008-12-03 作者:zhanghs 来源:TechTarget中国 英文

  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

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

zhanghs
zhanghs

相关推荐

  • Java性能优化的最差实践

    关于Java性能优化的方法已经有很多文章讨论过,其中总有一些不值得提倡甚至应该杜绝的方法,需要让开发者时刻保持警觉。

  • JVM垃圾收集器使用调查:CMS最受欢迎

    近日,Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究,研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中,并发收集器(CMS)使用次数最多。

  • 为什么说Azul Systems是微软Azure云的最好选择?

    当负责Azure云的微软朋友们决定,是时候慎重考虑拥抱企业Java社区时,他们知道他们需要做的第一步是,在他们的平台上引入世界级的Java运行时环境的实现。

  • 如何让代码并发效率更高

    开发人员正在利用多线程技术努力提高软件计算速度,本文介绍了如何让代码并发效率更高的实践经验。