JVM内部主要包括内存理?/span>Class LoaderQ类加蝲器）两个部分。熟悉了内存理Q我们就会清楚程序在内存中是怎么分配和执行的Q就能解x有和对象相关的问题（比如Memory LeakQ。理解了Class LoaderQ就能解x有类找不刎ͼ比如遇到NoClassDefFoundError?/span>ClassNotFoundExceptionQ或配置文g找不到问题?/span>
q次我们只讨?/span>JVM?/span>Class LoaderQ下ơ再讨论JVM的内存管理?/span>
Class Loader的主要作用就是负责查扄q将其加载到内存中。有的是，Java中的Class Loader也是?/span>Java所写，和普通的class一栗这׃生了一个是鸡生蛋还是蛋生鸡的问题，到底W一?/span>classp来加载呢Q我们稍后会来讨个问题?/span>
先来看一?/span>Class Loader所h的特炏V?/span>
1. l承关系
虽然Class Loader也是一?/span>Java classQ但q里的承不是指定义class时用的extends关键字来实现的承，而是指由属性来l持的承关pR即通过Class Loader的构造方法或其它Ҏ昑ּ的设|一个父Class Loader?/span>
2. 代理关系
每一?/span>Class Loader在接到请求去加蝲一个类之前Q默认，讉K一个类的时候，׃由加载当前类?/span>Class Loaderd载被讉K的类Q，它会首先h它的?/span>Class Loader来尝试加载，依次往上，如果?/span>Class Loader加蝲成功Q则直接q回Q子Class Loader不再查找?/span>
否则依次往下查扑ƈ加蝲。如果直到被h?/span>Class Loader也没有找到要加蝲的类Q则会出?/span>NoClassDefFoundError?/span>ClassNotFoundException
当然如果被请求的cdl加载到了内存中Q就不会触发q个查找q程了，而是直接q回已经加蝲的类?/span>
我们来看一个例子，假设有图1中的Class Loader层次Q?/span>
如果我们hClass Loader Ed?/span>Test.classQ首先它会请求父Class Loader Dd试加载。同?/span>Class Loader D会先h它的?/span>Class Loader Cd试加?/span>Test.class。当然这?/span>Class Loader C找不?/span>Test.classQ于是{回由Class Loader Dd载。最l?/span>Class Loader D成功扑ֈ?/span>D:"Test.classQƈ其加蝲到内存中?/span>
同样Q如果我们请?/span>Class Loader Fd?/span>Test3.class?/span>Class Loader C?/span>Class Loader D在各自的搜烦范围内都找不?/span>Test3.class。最l会?/span>Class Loader F自己加蝲F:"Test3.class到内存中?/span>
如果我们hClass Loader Dd?/span>Test3.classQ最l就会出?/span>NoClassDefFoundError?/span>ClassNotFoundException
3. 同一l承铑֏见?/span>
在同一?/span>Class Loader对象的扉K中，下面被加载的cd以访问上面被加蝲的类Q反之则不可以?/span>
同样以图1ZQ?/span>Test4.class可以讉K?/span>D:"Test.class?/span>C:"Test2.class
而如?/span>D:"Test.class?/span>C:"Test2.class试讉KTest4.classQ就会出?/span>NoClassDefFoundError?/span>ClassNotFoundException
4. 多个l承链不可见?/span>
多个l承链之间彼此看不到ҎQ不能相互访问?/span>
q以?/span>1ZQ如?/span>Test4.class讉KTest3.classQ或反过?/span>Test3.class讉KTest4.classQ都会引?/span>NoClassDefFoundError?/span>ClassNotFoundException
理解?/span>Class Loader所h的特点，我们来看?/span>JDK中都预置了哪?/span>Class Loader。也?/span>JVM启动旉认创建的Class Loader。如?/span>2
通过?/span>2Q我们可以看?/span>Bootstrap Class Loader?/span>JVM中的先Class Loader。它?/span>JDK中唯一一个由C++所写的Class LoaderQ它负责加蝲JDK的核心类?/span>(rt.jar)以及另外两个?/span>Java所写的Class LoaderQ?/span>Ext Class Loader?/span>App Class LoaderQ。之后就功成w退Q{?/span>Ext Class Loader?/span>App Class Loader加蝲所有应用中用到的类?/span>
一般我们的应用都是通过讄CLASSPATHQ最l由App Class Loader来加载。根?/span>Class Loader的承关p，我们应用中的cd以访?/span>JDK的核心类库。反之则会出错?/span>
我们再来看看WebLogic?/span>Class Loader的层ơ关p（如图4Q。如果需要，大家可以参考一?/span>WebLogic?/span>WAR?/span>EAR的文件结构（如图3Q?/span>
WLS中自定义了很多新?/span>Class LoaderQ当然他们的先Class Loader都是JDK中的App (or System) Class Loader。我们来看一下每?/span>Class Loader的职责?/span>
1. JDK App (or System) Class Loader
l 负责加蝲WLS启动脚本?/span>CLASSPATH中设|的c?/span>
l 所有的c都会最先由它尝试加?/span>
l 因ؓCLASSPATH的值在q行期不允许修改Q所以由?/span>Class Loader加蝲的类在运行期不能被动态卸载（替换Q?/span>
2. EJB Class Loader (1)
l 负责加蝲单独?/span>EJB jar里的cR?/span>
l 不同?/span>EJB jar文g会被不同实例?/span>Class Loader加蝲Q因?/span>EJB jar彼此之间互相看不到对?/span>
3. WAR Class Loader (1)
l 负责加蝲单独?/span>WAR里的c?/span>
l 不同?/span>WAR文g会被不同实例?/span>Class Loader加蝲Q因?/span>WAR彼此之间互相看不到对?/span>
4. EAR Class Loader
l 负责加蝲EAR里面?/span>APP-INF下的c?/span>
l 不同?/span>EAR文g会被不同实例?/span>EAR Class Loader加蝲Q因?/span>EAR彼此之间互相看不到对?/span>
l 它下面有一?/span>EJB Class Loader (2) 实例,负责加蝲EAR里面所有的EJB jar。因此，EAR中的EJB彼此之间可以看到Ҏ
l EJB Class Loader (2) 下有多个WAR Class Loader (2) 实例。每个实例负责加?/span>EAR里面的一?/span>WAR。所以，EAR中的WAR彼此之间看不到对?/span>
l Ҏl承链规则，WAR可以看到所有的EJB?/span>APP-INF下的所有类?/span> EJB可以看到APP-INF下的所有类Q但反之则不可以
Class Loader虽然UCؓcd载器Q但q不意味着只能用来加蝲ClassQ我们还可以利用它来查找囄和配|文件等资源。比如，我们l常使用getClass().getResourceAsStream(name)来查N|文件。同P查找其它资源文g的方式和上面一P也会先请求父Class Loader来负责查找?/span>
q里Q我们只单介l了Class Loader对于cȝ查找Q而关?/span>Class Loader的具体加载、校验和初始化的q程Q感兴趣的朋友可以参考《深?/span>Java虚拟机?/span>
]]>