深入分析Java ClassLoader原理Word格式文档下载.docx
《深入分析Java ClassLoader原理Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《深入分析Java ClassLoader原理Word格式文档下载.docx（17页珍藏版）》请在冰豆网上搜索。
以下内容是上述程序从本机JDK环境所获得的结果：
file:
/C:
/Program%20Files/Java/jdk1.6.0_22/jre/lib/resources.jar
/Program%20Files/Java/jdk1.6.0_22/jre/lib/rt.jar
/Program%20Files/Java/jdk1.6.0_22/jre/lib/sunrsasign.jar
/Program%20Files/Java/jdk1.6.0_22/jre/lib/jsse.jar
/Program%20Files/Java/jdk1.6.0_22/jre/lib/jce.jar
/Program%20Files/Java/jdk1.6.0_22/jre/lib/charsets.jar
/Program%20Files/Java/jdk1.6.0_22/jre/classes/
其实上述结果也是通过查找sun.boot.class.path这个系统属性所得知的。
1System.out.println（System.getProperty（"
sun.boot.class.path"
））;
2打印结果：
C:
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\resources.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\rt.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\sunrsasign.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\jsse.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\jce.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\charsets.jar;
\ProgramFiles\Java\jdk1.6.0_22\jre\classes
3ExtensionClassLoader：
称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的所有jar。
4AppClassLoader：
称为系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件。
注意：
除了Java默认提供的三个ClassLoader之外，用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类，也包括Java提供的另外二个ClassLoader（ExtensionClassLoader和AppClassLoader）在内，但是BootstrapClassLoader不继承自ClassLoader，因为它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，BootstrapClassLoader也随着启动，负责加载完核心类库后，并构造ExtensionClassLoader和AppClassLoader类加载器。
三、ClassLoader加载类的原理
1、原理介绍
ClassLoader使用的是双亲委托模型来搜索类的，每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（BootstrapClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。
当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器BootstrapClassLoader试图加载，如果没加载到，则把任务转交给ExtensionClassLoader试图加载，如果也没加载到，则转交给AppClassLoader进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。
如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。
否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。
2、为什么要使用双亲委托这种模型呢？
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（BootstrcpClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。
3、但是JVM在搜索类的时候，又是如何判定两个class是相同的呢？
JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。
只有两者同时满足的情况下，JVM才认为这两个class是相同的。
就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。
比如网络上的一个Java类org.classloader.simple.NetClassLoaderSimple，javac编译之后生成字节码文件NetClassLoaderSimple.class，ClassLoaderA和ClassLoaderB这两个类加载器并读取了NetClassLoaderSimple.class文件，并分别定义出了java.lang.Class实例来表示这个类，对于JVM来说，它们是两个不同的实例对象，但它们确实是同一份字节码文件，如果试图将这个Class实例生成具体的对象进行转换时，就会抛运行时异常java.lang.ClassCaseException，提示这是两个不同的类型。
现在通过实例来验证上述所描述的是否正确：
1）、在web服务器上建一个org.classloader.simple.NetClassLoaderSimple.java类
5packageorg.classloader.simple;
6
7publicclassNetClassLoaderSimple{
8
9privateNetClassLoaderSimpleinstance;
10
11publicvoidsetNetClassLoaderSimple（Objectobj）{
12this.instance=（NetClassLoaderSimple）obj;
13}
14}
org.classloader.simple.NetClassLoaderSimple类的setNetClassLoaderSimple方法接收一个Object类型参数，并将它强制转换成org.classloader.simple.NetClassLoaderSimple类型。
2）、测试两个class是否相同（NetWorkClassLoader.java）
15packageclassloader;
16
17publicclassNewworkClassLoaderTest{
18
19publicstaticvoidmain（String[]args）{
20try{
21//测试加载网络中的class文件
22StringrootUrl="
http:
//localhost:
8080/httpweb/classes"
;
23StringclassName="
org.classloader.simple.NetClassLoaderSimple"
24NetworkClassLoaderncl1=newNetworkClassLoader（rootUrl）;
25NetworkClassLoaderncl2=newNetworkClassLoader（rootUrl）;
26Class<
?
>
clazz1=ncl1.loadClass（className）;
27Class<
clazz2=ncl2.loadClass（className）;
28Objectobj1=clazz1.newInstance（）;
29Objectobj2=clazz2.newInstance（）;
30clazz1.getMethod（"
setNetClassLoaderSimple"
Object.class）.invoke（obj1,obj2）;
31}catch（Exceptione）{
32e.printStackTrace（）;
33}
34}
35
36}
首先获得网络上一个class文件的二进制名称，然后通过自定义的类加载器NetworkClassLoader创建两个实例，并根据网络地址分别加载这份class，并得到这两个ClassLoader实例加载后生成的Class实例clazz1和clazz2，最后将这两个Class实例分别生成具体的实例对象obj1和obj2，再通过反射调用clazz1中的setNetClassLoaderSimple方法。
3）、查看测试结果
结论：
从结果中可以看出，虽然是同一份class字节码文件，但是由于被两个不同的ClassLoader实例所加载，所以JVM认为它们就是两个不同的类。
4、ClassLoader的体系架构：
验证ClassLoader加载类的原理：
测试1：
打印ClassLoader类的层次结构，请看下面这段代码：
37ClassLoaderloader=ClassLoaderTest.class.getClassLoader（）;
//获得加载ClassLoaderTest.class这个类的类加载器
38while（loader!
=null）{
39System.out.println（loader）;
40loader=loader.getParent（）;
//获得父类加载器的引用
41}
42System.out.println（loader）;
打印结果：
第一行结果说明：
ClassLoaderTest的类加载器是AppClassLoader。
第二行结果说明：
AppClassLoader的类加器是ExtClassLoader，即parent=ExtClassLoader。
第三行结果说明：
ExtClassLoader的类加器是BootstrapClassLoader，因为BootstrapClassLoader不是一个普通的Java类，所以ExtClassLoader的parent=null，所以第三行的打印结果为null就是这个原因。
测试2：
将ClassLoaderTest.class打包成ClassLoaderTest.jar，放到ExtensionClassLoader的加载目录下（JAVA_HOME/jre/lib/ext），然后重新运行这个程序，得到的结果会是什么样呢？
打印结果分析：
为什么第一行的结果是ExtClassLoader呢？
因为ClassLoader的委托模型机制，当我们要用ClassLoaderTest.class这个类的时候，AppClassLoader在试图加载之前，先委托给BootstrcpClassLoader，BootstracpClassLoader发现自己没找到，它就告诉ExtClassLoader，兄弟，我这里没有这个类，你去加载看看，然后ExtensionClassLoader拿着这个类去它指定的类路径（JAVA_HOME/jre/lib/ext）试图加载，唉，它发现在ClassLoaderTest.jar这样一个文件中包含ClassLoaderTest.class这样的一个文件，然后它把找到的这个类加载到内存当中，并生成这个类的Class实例对象，最后把这个实例返回。
所以ClassLoaderTest.class的类加载器是ExtClassLoader。
第二行的结果为null，是因为ExtClassLoader的父类加载器是BootstrapClassLoader。
测试3：
用BootstrcpClassLoader来加载ClassLoaderTest.class，有两种方式：
1、在jvm中添加-Xbootclasspath参数，指定BootstrcpClassLoader加载类的路径，并追加我们自已的jar（ClassTestLoader.jar）
2、将class文件放到JAVA_HOME/jre/classes/目录下（上面有提到）
方式1：
（我用的是Eclipse开发工具，用命令行是在java命令后面添加-Xbootclasspath参数）
打开Run配置对话框：
配置好如图中所述的参数后，重新运行程序，产的结果如下所示：
（类加载的过程，只摘下了一部份）
43[Loadedjava.io.FileReaderfromC:
\ProgramFiles\Java\jdk1.6.0_22\jre\lib\rt.jar]
44[Loadedsun.nio.cs.StreamDecoderfromC:
45[Loadedjava.util.ArrayListfromC:
46[Loadedjava.lang.reflect.ArrayfromC:
47[Loadedjava.util.LocalefromC:
48[Loadedjava.util.concurrent.ConcurrentMapfromC:
49[Loadedjava.util.concurrent.ConcurrentHashMapfromC:
50[Loadedjava.util.concurrent.locks.LockfromC:
51[Loadedjava.util.concurrent.locks.ReentrantLockfromC:
52[Loadedjava.util.concurrent.ConcurrentHashMap$SegmentfromC:
53[Loadedjava.util.concurrent.locks.AbstractOwnableSynchronizerfromC:
54[Loadedjava.util.concurrent.locks.AbstractQueuedSynchronizerfromC:
55[Loadedjava.util.concurrent.locks.ReentrantLock$SyncfromC:
56[Loadedjava.util.concurrent.locks.ReentrantLock$NonfairSyncfromC:
57[Loadedjava.util.concurrent.locks.AbstractQueuedSynchronizer$NodefromC:
58[Loadedjava.util.concurrent.ConcurrentHashMap$HashEntryfromC:
59[Loadedjava.lang.CharacterDataLatin1fromC:
60[Loadedjava.io.ObjectStreamClassfromC:
61[Loaded.www.ParseUtilfromC:
62[Loadedjava.util.BitSetfromC:
63[Loaded.PartsfromC:
64[Loaded.URLStreamHandlerfromC:
65[Loaded.www.protocol.file.HandlerfromC:
66[Loadedjava.util.HashSetfromC:
67[Loaded.www.protocol.jar.HandlerfromC:
68[Loadedsun.misc.Launcher$AppClassLoaderfromC:
69[Loadedsun.misc.Launcher$AppClassLoader$1fromC:
70[Loadedjava.lang.SystemClassLoaderActionfromC:
71[PathC:
\ProgramFiles\Java\jdk1.6.0_22\jre\classes]
72[Loadedclassloader.ClassLoaderTestfromC:
73null//这是打印的结果
74C:
75C:
\ProgramFiles\Java\jdk1.6.0_
升级会员 