2006年10月11日
Spring的任务调度服务实例讲解
记的以前在做一家人才招聘网站时遇到的一个问题，因为白天的流量非常大为了减轻网站的压力所以客户要求一些不是太急手的任务（如，给注册用户发送邮件、清理日常垃圾信息等等）都放在凌晨流量最小的时间段去执行，当时我们借助java.util.Timer来实现的。但是对于更加复杂的任务调度Timer就不太容易了，后来了解了Quartz（OpenSymphony的提供任务调务类库）可以大大弥补Timer的不足可以使开发者能够完成各种复杂的任务调度。Spring又对其提供了很好的支持使得开发者不用另外去学习这套全新的类库就能很方便的使用。
下面提供一个实例来讲解：
1. 首先把spring.jar包放到classpath下
2. 编辑spring配制文件，ApplicationContext.xml内容如下：
代码
<
?x
ml
version
="
1.0
"
encoding
="
UTF-8
"
?>
<!
DOCTYPE
beans
PUBLIC
"
-//SPRING//DTD BEAN//EN
"
"
spring-beans.dtd
"
>
<
beans
>
<!—要调度的对象-->
<
bean
id
="
testQuarz
"
class
="
springtimer.TestQuarz
"
/>
<!--定义定时执行
testQuarz 这个bean中的sayHello()方法-->
<beanid="helloworldTask"class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
<propertyname="targetObject">
<refbean="testQuarz"/>
</property>
<property name="targetMethod">
<value>sayHello</value>
</property>
</bean>
<!--触发器的
bean的设置，在这里我们设置了我们要触发的jobDetail是哪个。这里我们定义了要触发的jobDetail是helloworldTask，即触发器去触发哪个bean
..并且我们还定义了触发的时间:每天
5
:
17
pm
-->
<
bean
id
="
cronTrigger
"
class
="
org.springframework.scheduling.quartz.CronTriggerBean
">
<
property
name
="
jobDetail
">
<
ref
bean
="
helloworldTask
"
/>
</
property>
<property name="cronExpression">
<!-- 关键在配置此表达式 -->
<value>0 17 17 * * ?<
/
value
>
</
property>
<
/
bean
>
<!--管理触发器的总设置,管理我们的触发器列表,可以在
bean的list中放置多个触发器。
-->
<
bean
autowire
="
no
"
class
="
org.springframework.scheduling.quartz.SchedulerFactoryBean
">
<
property
name
="
triggers
">
<
list
>
<
ref
local
="
cronTrigger
"
/>
</
list>
<
/
property
>
</
bean>
<
/
beans
>
3.以下是被调度的类代码
代码
package
springtimer
;
public
class
TestQuarz
{
public
void
sayHello
()
{
System
.
out
.
println
("
HelloWorld!
");
}
}
4,提供测试类
代码
public
class
TestHello
{
public
static
void
main
(
String
[]
args
)
{
/
/ 只要加载配置文件就可以了,
ApplicationContextcontext=newClassPathXmlApplicationContext("ApplicationContext.xml");
System.out.println("*****完毕******");
}
5,Ok自已可以设置sping-config文件中<value>0 17 17 * * ?</value>的调度表达式,可以测试啦!
6, 下面简单的介绍一下cron expressions（调度表达式）
格式列表：
代码
Field
Name
|
Mandatory
?
|
Allowed
Values
|
Allowed
Special
Characters
Seconds
|
YES
|
0
-
59
|
,
-
*
/
Minutes | YES | 0-59 | , - *
/
Hours
|
YES
|
0
-
23
|
,
-
*
/
Day of month | YES | 1-31 | , - * ?
/
L
W
C
Month
|
YES
|
1
-
12
or
JAN
-
DEC
|
,
-
*
/
Day of week | YES | 1-7 or SUN-SAT | , - * ?
/
L
C
Year
|
NO
|
empty
,
1970
-
2099
|
,
-
*
/
至于详细的解释你一看例子就会明白
例子列表如下：
表达式 解释
0 0 12 * * ? 在每天中午12：00触发
0 15 10 ? * * 每天上午10:15 触发
0 15 10 * * ? 每天上午10:15 触发
0 15 10 * * ? * 每天上午10:15 触发
0 15 10 * * ? 2005 在2005年中的每天上午10:15 触发
0 * 14 * * ? 每天在下午2：00至2：59之间每分钟触发一次
0 0/5 14 * * ? 每天在下午2：00至2：59之间每5分钟触发一次
0 0/5 14,18 * * ? 每天在下午2：00至2：59和6：00至6：59之间的每5分钟触发一次
0 0-5 14 * * ? 每天在下午2：00至2：05之间每分钟触发一次
0 10,44 14 ? 3 WED 每三月份的星期三在下午2：00和2：44时触发
0 15 10 ? * MON-FRI 从星期一至星期五的每天上午10：15触发
0 15 10 15 * ? 在每个月的每15天的上午10：15触发
0 15 10 L * ? 在每个月的最后一天的上午10：15触发
0 15 10 ? * 6L 在每个月的最后一个星期五的上午10：15触发
0 15 10 ? * 6L 2002-2005 在2002, 2003, 2004 and 2005年的每个月的最后一个星期五的上午10：15触发
0 15 10 ? * 6#3 在每个月的第三个星期五的上午10：15触发
0 0 12 1/5 * ? 从每月的第一天起每过5天的中午12：00时触发
0 11 11 11 11 ? 在每个11月11日的上午11：11时触发.
1.关于“==”和“equals”,其中对引用型变量和简单类型是不同的
(1) "==" 对简单类型来说，是比较值是否相等； 对于引用来说，是看二者是否指向同一个地址。
(2) equals 不管对于什么类型都是比较值是否相等。
还要注意的是：当引用型变量没有通过关键字new 来申请变量时，它可能不会在堆里生成一个新的变量，而是到栈中找一个是否相等的值，然后把这个引用指向它，比如：在栈中有“asdfg”这个一个字符串，然后我们String str1 = "asdfg" ;这样的话，str1并没有在堆中生成新的字符串，而是将引用指向了栈中的“asdfg”。
2.关于“synchronized”的使用 ，线程同步问题，并发问题，线程安全。
线程安全：指的是在多线程并发执行的程序中，怎么保证各自的线程是安全的，比如说：多个请求线程要请求某个公共资源（可以使一个对象，一个程序，一个方法，一段代码段），怎么来保证各自的请求线程中没有冲突，对请求服务的某些临界资源没有冲突。通过某种形式的互斥而实现对并发访问的保护，则代码是线程安全的。
http://en.wikipedia.org/wiki/Thread-safe http://pialion.blogchina.com/2531546.html（
开发线程安全的Spring Web应用）
而synchronized关键字往往是Java应用中实现线程安全最重要的因素。
对于synchronized，它的使用可以对代码，也可以针对某个方法。
（1）.对于方法，它只对某个对象来说是线程安全的，就是说
Object o = new **Object()；对于所有操作o对象的线程是安全，并不能保证 o2,o3等等对象也是线程安全的
（2）.对于代码来说，在synchronized内的代码，对于所有的线程都是安全的。
比如：
在sychronized内的代码，对有SynClass 的所有对象都是线程同步的，换句话说就是，此处代码对所有的线程来说，在某一时刻只有一个线程拥有这个对象锁o,只有等这个线程执行完了以后，才释放对象锁o,这样其他的线程才能去争取这个锁O来获得代码的执行权。
2006年10月10日
摘要: 本文首先介绍一下
Java
虚拟机的生存周期，然后大致介绍
JVM
的体系结构，最后对体系结构中的各个部分进行详细介绍。（
首先这里澄清两个概念：
JVM
实例和
JVM
执行引擎实例，
JVM
实例对应了一个独立运行的
java
程序，而
JVM
执行引擎实例则对应了属于用户运行程序的线程；也就...
阅读全文
Java虚拟机(JVM)是可运行Java代码的假想计算机。只要根据JVM规格描述将解释器移植到特定的计算机上，就能保证经过编译的任何Java代码能够在该系统上运行。
Java源文件的编译、下载、解释和执行
Java应用程序的开发周期包括编译、下载、解释和执行几个部分。Java编译程序将Java源程序翻译为JVM可执行代码—字节码。这一编译过程同C/C++的编译有些不同。当C编译器编译生成一个对象的代码时，该代码是为在某一特定硬件平台运行而产生的。因此，在编译过程中，编译程序通过查表将所有对符号的引用转换为特定的内存偏移量，以保证程序运行。Java
编译器却不将对变量和方法的引用编译为数值引用，也不确定程序执行过程中的内存布局，而是将这些符号引用信息保留在字节码中，由解释器在运行过程中创立内存布局，然后再通过查表来确定一个方法所在的地址。这样就有效的保证了Java的
可移植性和安全性。
运行JVM字节码的工作是由解释器来完成的。解释执行过程分三部进行：代码的装入、代码的校验和代码的执行。装入代码的工作由"类装载器"（class loader）完成。类装载器负责装入运行一个程序需要的所有代码，这也包括程序代码中的类所继承的类和被其调用的类。当类装载器装入一个类时，该类被放在自己的名字空间中。除了通过符号引用自己名字空间以外的类，类之间没有其他办法可以影响其他类。在本台计算机上的所有类都在同一地址空间内，而所有从外部引进的类，都有一个自己独立的名字空间。这使得本地类通过共享相同的名字空间获得较高的运行效率，同时又保证它们与从外部引进的类不会相互影响。当装入了运行程序需要的所有类后，解释器便可确定整个可执行程序的内存布局。解释器为符号引用同特定的地址空间建立对应关系及查询表。通过在这一阶段确定代码的内存布局，Java很好地解决了由超类改变而使子类崩溃的问题，同时也防止了代码对地址的非法访问。
随后，被装入的代码由字节码校验器进行检查。校验器可发现操作数栈溢出，非法数据类型转化等多种错误。通过校验后，代码便开始执行了。
Java字节码的执行有两种方式：
- 即时编译方式：解释器先将字节码编译成机器码，然后再执行该机器码。
- 解释执行方式：解释器通过每次解释并执行一小段代码来完成Java字节码程 序的所有操作。
通常采用的是第二种方法。由于JVM规格描述具有足够的灵活性，这使得将字节码翻译为机器代码的工作
具有较高的效率。对于那些对运行速度要求较高的应用程序，解释器可将Java字节码即时编译为机器码，从而很好地保证了Java代码的可移植性和高性能。
JVM规格描述
JVM的设计目标是提供一个基于抽象规格描述的计算机模型，为解释程序开发人员提很好的灵活性，同时也确保Java代码可在符合该规范的任何系统上运行。JVM对其实现的某些方面给出了具体的定义，特别是对Java可执行代码，即
字节码(
Bytecode)的格式给出了明确的规格。这一规格包括操作码和操作数的语法和数值、标识符的数值表示方式、以及Java类文件中的Java对象、常量缓冲池在JVM的存储映象。这些定义为JVM解释器开发人员提供了所需的信息和开发环境。Java的设计者希望给开发人员以随心所欲使用Java的自由。 JVM定义了控制Java代码解释执行和具体实现的五种规格，它们是： *JVM指令系统 *JVM寄存器 *JVM栈结构 *JVM碎片回收堆 *JVM存储区
JVM指令系统
JVM指令系统同其他计算机的指令系统极其相似。Java指令也是由 操作码和操作数两部分组成。操作码为8位二进制数，操作数进紧随在操作码的后面，其长度根据需要而不同。操作码用于指定一条指令操作的性质（在这里我们采用汇编符号的形式进行说明），如iload表示从存储器中装入一个整数，anewarray表示为一个新数组分配空间，iand表示两个整数的"与"，ret用于流程控制，表示从对某一方法的调用中返回。当长度大于8位时，操作数被分为两个以上字节存放。JVM采用了"big endian"的编码方式来处理这种情况，即高位bits存放在低字节中。这同
Motorola及其他的RISC CPU采用的编码方式是一致的，而与
Intel采用的"little endian "的编码方式即低位bits存放在低位字节的方法不同。 Java指令系统是以Java语言的实现为目的设计的，其中包含了用于调用方法和监视多先程系统的指令。Java的8位操作码的长度使得JVM最多有256种指令，目前已使用了160多种操作码。
所有的CPU均包含用于保存系统状态和处理器所需信息的寄存器组。如果虚拟机定义较多的寄存器，便可以从中得到更多的信息而不必对栈或内存进行访问，这有利于提高运行速度。然而，如果虚拟机中的寄存器比实际CPU的寄存器多，在实现虚拟机时就会占用处理器大量的时间来用常规存储器模拟寄存器，这反而会降低虚拟机的效率。针对这种情况，JVM只设置了4个最为常用的寄存器。它们是：
- pc程序计数器
- optop操作数栈顶指针
- frame当前执行环境指针
- vars指向当前执行环境中第一个局部变量的指针
所有寄存器均为32位。pc用于记录程序的执行。optop,frame和vars用于记录指向Java栈区的指针。
JVM栈结构
作为基于栈结构的计算机，Java栈是JVM存储信息的主要方法。当JVM得到一个Java字节码应用程序后，便为该代码中一个类的每一个方法创建一个栈框架，以保存该方法的状态信息。每个栈框架包括以下三类信息：
局部变量用于存储一个类的方法中所用到的局部变量。vars寄存器指向该变量表中的第一个局部变量。 执行环境用于保存解释器对Java字节码进行解释过程中所需的信息。它们是：上次调用的方法、局部变量指针和操作数栈的栈顶和栈底指针。执行环境是一个执行一个方法的控制中心。例如：如果解释器要执行iadd(整数加法)，首先要从frame寄存器中找到当前执行环境，而后便从执行环境中找到操作数栈，从栈顶弹出两个整数进行加法运算，最后将结果压入栈顶。 操作数栈用于存储运算所需操作数及运算的结果。
JVM碎片回收堆
Java类的实例所需的存储空间是在堆上分配的。解释器具体承担为类实例分配空间的工作。解释器在为一个实例分配完存储空间后，便开始记录对该实例所占用的内存区域的使用。一旦对象使用完毕，便将其回收到堆中。在Java语言中，除了new语句外没有其他方法为一对象申请和释放内存。对内存进行释放和回收的工作是由Java运行系统承担的。这允许Java运行系统的设计者自己决定碎片回收的方法。在SUN公司开发的Java解释器和
Hot Java环境中，碎片回收用后台线程的方式来执行。这不但为运行系统提供了良好的性能，而且使程序设计人员摆脱了自己控制内存使用的风险。
JVM存储区
JVM有两类存储区：常量缓冲池和方法区。常量缓冲池用于存储类名称、方法和字段名称以及串常量。方法区则用于存储Java方法的字节码。对于这两种存储区域具体实现方式在JVM规格中没有明确规定。这使得Java应用程序的存储布局必须在运行过程中确定，依赖于具体平台的实现方式。 JVM是为Java字节码定义的一种独立于具体平台的规格描述，是Java平台独立性的基础。目前的JVM还存在一些限制和不足，有待于进一步的完善，但无论如何，JVM的思想是成功的。
对比分析：如果把Java原程序想象成我们的C++原程序，Java原程序编译后生成的字节码就相当于C++原程序编译后的80x86的机器码（二进制程序文件），JVM虚拟机相当于80x86计算机系统,Java解释器相当于80x86CPU。在80x86CPU上运行的是机器码，在Java解释器上运行的是Java字节码。 Java解释器相当于运行Java字节码的“CPU”,但该“CPU”不是通过硬件实现的，而是用软件实现的。Java解释器实际上就是特定的平台下的一个应用程序。只要实现了特定平台下的解释器程序，Java字节码就能通过解释器程序在该平台下运行，这是Java跨平台的根本。当前，并不是在所有的平台下都有相应Java解释器程序，这也是Java并不能在所有的平台下都能运行的原因，它只能在已实现了Java解释器程序的平台下运行。
当JVM（Java虚拟机）启动时，会形成由三个类加载器组成的初始类加载器层次结构：
bootstrap classloader
extension classloader
system classloader
bootstrap classloader － 引导（也称为原始）类加载器，它负责加载Java的核心类。在Sun的JVM中，在执行java的命令中使用-
Xbootclasspath选项或使用-D选项指定sun.boot.class.path系统属性值可以指定附加的类。这个加载器的是非常特殊的，它实际上不是
java.lang.ClassLoader的子类，而是由JVM自身实现的。大家可以通过执行以下代码来获得bootstrap classloader加载了那些核心类库：
URL[] urls=sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls.toExternalForm());
}
在我的计算机上的结果为：
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/dom.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/sax.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xalan-2.3.1.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xercesImpl-2.0.0.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xml-apis.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xsltc.jar
file:/C:/j2sdk1.4.1_01/jre/lib/rt.jar
file:/C:/j2sdk1.4.1_01/jre/lib/i18n.jar
file:/C:/j2sdk1.4.1_01/jre/lib/sunrsasign.jar
file:/C:/j2sdk1.4.1_01/jre/lib/jsse.jar
file:/C:/j2sdk1.4.1_01/jre/lib/jce.jar
file:/C:/j2sdk1.4.1_01/jre/lib/charsets.jar
file:/C:/j2sdk1.4.1_01/jre/classes
这时大家知道了为什么我们不需要在系统属性CLASSPATH中指定这些类库了吧，因为JVM在启动的时候就自动加载它们了。
extension classloader － 扩展类加载器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系统属性指定的）中JAR
的类包。这为引入除Java核心类以外的新功能提供了一个标准机制。因为默认的扩展目录对所有从同一个JRE中启动的JVM都是通用的，所以放
入这个目录的JAR类包对所有的JVM和system classloader都是可见的。在这个实例上调用方法getParent()总是返回空值null，因为引导加载器
bootstrap classloader不是一个真正的ClassLoader实例。所以当大家执行以下代码时：
System.out.println(System.getProperty("java.ext.dirs"));
ClassLoader extensionClassloader=ClassLoader.getSystemClassLoader().getParent();
System.out.println("the parent of extension classloader : "+extensionClassloader.getParent());
结果为：
C:\j2sdk1.4.1_01\jre\lib\ext
the parent of extension classloader : null
extension classloader是system classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一个实际的
classloader，所以为null。
system classloader － 系统（也称为应用）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系
统属性或者CLASSPATH操作系统属性所指定的JAR类包和类路径。总能通过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。如
果没有特别指定，则用户自定义的任何类加载器都将该类加载器作为它的父加载器。执行以下代码即可获得：
System.out.println(System.getProperty("java.class.path"));
输出结果则为用户在系统属性里面设置的CLASSPATH。
classloader加载类用的是全盘负责委托机制。所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所
有Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入；委托机制则是先让parent（父）类加载器(而不是super
，它与parent classloader类不是继承关系)寻找，只有在parent找不到的时候才从自己的类路径中去寻找。此外类加载还采用了cache机制，
也就是如果cache中保存了这个Class就直接返回它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么我们修改了Class但
是必须重新启动JVM才能生效的原因。
每个ClassLoader加载Class的过程是：
1.检测此Class是否载入过（即在cache中是否有此Class），如果有到8,如果没有到2
2.如果parent classloader不存在（没有parent，那parent一定是bootstrap classloader了），到4
3.请求parent classloader载入，如果成功到8，不成功到5
4.请求jvm从bootstrap classloader中载入，如果成功到8
5.寻找Class文件（从与此classloader相关的类路径中寻找）。如果找不到则到7.
6.从文件中载入Class，到8.
7.抛出ClassNotFoundException.
8.返回Class.
其中5.6步我们可以通过覆盖ClassLoader的findClass方法来实现自己的载入策略。甚至覆盖loadClass方法来实现自己的载入过程。
类加载器的顺序是：
先是bootstrap classloader，然后是extension classloader，最后才是system classloader。大家会发现加载的Class越是重要的越在靠前面
。这样做的原因是出于安全性的考虑，试想如果system classloader“亲自”加载了一个具有破坏性的“java.lang.System”类的后果吧。这
种委托机制保证了用户即使具有一个这样的类，也把它加入到了类路径中，但是它永远不会被载入，因为这个类总是由bootstrap classloader
来加载的。大家可以执行一下以下的代码：
System.out.println(System.class.getClassLoader());
将会看到结果是null，这就表明java.lang.System是由bootstrap classloader加载的，因为bootstrap classloader不是一个真正的
ClassLoader实例，而是由JVM实现的，正如前面已经说过的。
下面就让我们来看看JVM是如何来为我们来建立类加载器的结构的：
sun.misc.Launcher，顾名思义，当你执行java命令的时候，JVM会先使用bootstrap classloader载入并初始化一个Launcher，执行下来代码：
System.out.println("the Launcher's classloader is "+sun.misc.Launcher.getLauncher().getClass().getClassLoader());
结果为：
the Launcher's classloader is null (因为是用bootstrap classloader加载,所以class loader为null)
Launcher会根据系统和命令设定初始化好class loader结构，JVM就用它来获得extension classloader和system classloader,并载入所有的需
要载入的Class，最后执行java命令指定的带有静态的main方法的Class。extension classloader实际上是sun.misc.Launcher$ExtClassLoader
类的一个实例，system classloader实际上是sun.misc.Launcher$AppClassLoader类的一个实例。并且都是java.net.URLClassLoader的子类。
让我们来看看Launcher初试化的过程的部分代码。
Launcher的部分代码：
public class Launcher {
public Launcher() {
ExtClassLoader extclassloader;
try {
//初始化extension classloader
extclassloader = ExtClassLoader.getExtClassLoader();
} catch(IOException ioexception) {
throw new InternalError("Could not create extension class loader");
}
try {
//初始化system classloader，parent是extension classloader
loader = AppClassLoader.getAppClassLoader(extclassloader);
} catch(IOException ioexception1) {
throw new InternalError("Could not create application class loader");
}
//将system classloader设置成当前线程的context classloader（将在后面加以介绍）
Thread.currentThread().setContextClassLoader(loader);
......
}
public ClassLoader getClassLoader() {
//返回system classloader
return loader;
}
}
extension classloader的部分代码：
static class Launcher$ExtClassLoader extends URLClassLoader {
public static Launcher$ExtClassLoader getExtClassLoader()
throws IOException
{
File afile[] = getExtDirs();
return (Launcher$ExtClassLoader)AccessController.doPrivileged(new Launcher$1(afile));
}
private static File[] getExtDirs() {
//获得系统属性“java.ext.dirs”
String s = System.getProperty("java.ext.dirs");
File afile[];
if(s != null) {
StringTokenizer stringtokenizer = new StringTokenizer(s, File.pathSeparator);
int i = stringtokenizer.countTokens();
afile = new File;
for(int j = 0; j < i; j++)
afile[j] = new File(stringtokenizer.nextToken());
} else {
afile = new File[0];
}
return afile;
}
}
system classloader的部分代码：
static class Launcher$AppClassLoader extends URLClassLoader
{
public static ClassLoader getAppClassLoader(ClassLoader classloader)
throws IOException
{
//获得系统属性“java.class.path”
String s = System.getProperty("java.class.path");
File afile[] = s != null Launcher.access$200(s) : new File[0];
return (Launcher$AppClassLoader)AccessController.doPrivileged(new Launcher$2(s, afile, classloader));
}
}
看了源代码大家就清楚了吧，extension classloader是使用系统属性“java.ext.dirs”设置类搜索路径的，并且没有parent。system
classloader是使用系统属性“java.class.path”设置类搜索路径的，并且有一个parent classloader。Launcher初始化extension
classloader，system classloader，并将system classloader设置成为context classloader，但是仅仅返回system classloader给JVM。
这里怎么又出来一个context classloader呢？它有什么用呢？我们在建立一个线程Thread的时候，可以为这个线程通过
setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader，当此线程运行的时候，我们可以通过
getContextClassLoader方法来获得此context classloader，就可以用它来载入我们所需要的Class。默认的是system classloader。利用这个
特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前线程的context classloader，而这个context classloader可
以是它的子classloader或者其他的classloader，那么父classloader就可以从其获得所需的Class，这就打破了只能向父classloader请求的限
制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的classloader加载的时候,由system classloader(即在jvm
classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的
classloader中是其实现),例如web应用中的servlet就是用这种机制加载的.
好了，现在我们了解了classloader的结构和工作原理，那么我们如何实现在运行时的动态载入和更新呢？只要我们能够动态改变类搜索路径和
清除classloader的cache中已经载入的Class就行了，有两个方案，一是我们继承一个classloader，覆盖loadclass方法，动态的寻找Class文
件并使用defineClass方法来；另一个则非常简单实用，只要重新使用一个新的类搜索路径来new一个classloader就行了，这样即更新了类搜索
路径以便来载入新的Class，也重新生成了一个空白的cache(当然,类搜索路径不一定必须更改)。噢，太好了，我们几乎不用做什么工作，
java.netURLClassLoader正是一个符合我们要求的classloader！我们可以直接使用或者继承它就可以了！
这是j2se1.4 API的doc中URLClassLoader的两个构造器的描述：
URLClassLoader(URL[] urls)
Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader.
URLClassLoader(URL[] urls, ClassLoader parent)
Constructs a new URLClassLoader for the given URLs.
其中URL[] urls就是我们要设置的类搜索路径，parent就是这个classloader的parent classloader，默认的是system classloader。
好，现在我们能够动态的载入Class了，这样我们就可以利用newInstance方法来获得一个Object。但我们如何将此Object造型呢？可以将此
Object造型成它本身的Class吗？
首先让我们来分析一下java源文件的编译，运行吧！javac命令是调用“JAVA_HOME/lib/tools.jar”中的“com.sun.tools.javac.Main”的
compile方法来编译：
public static int compile(String as[]);
public static int compile(String as[], PrintWriter printwriter);
返回0表示编译成功，字符串数组as则是我们用javac命令编译时的参数，以空格划分。例如：
javac -classpath c:\foo\bar.jar;. -d c:\ c:\Some.java
则字符串数组as为{"-classpath","c:\\foo\\bar.jar;.","-d","c:\\","c:\\Some.java"}，如果带有PrintWriter参数，则会把编译信息出到
这个指定的printWriter中。默认的输出是System.err。
其中Main是由JVM使用Launcher初始化的system classloader载入的，根据全盘负责原则，编译器在解析这个java源文件时所发现的它所依赖和
引用的所有Class也将由system classloader载入，如果system classloader不能载入某个Class时，编译器将抛出一个“cannot resolve
symbol”错误。
所以首先编译就通不过，也就是编译器无法编译一个引用了不在CLASSPATH中的未知Class的java源文件，而由于拼写错误或者没有把所需类库
放到CLASSPATH中，大家一定经常看到这个“cannot resolve symbol”这个编译错误吧！
其次，就是我们把这个Class放到编译路径中，成功的进行了编译，然后在运行的时候不把它放入到CLASSPATH中而利用我们自己的classloader
来动态载入这个Class，这时候也会出现“java.lang.NoClassDefFoundError”的违例，为什么呢？
我们再来分析一下，首先调用这个造型语句的可执行的Class一定是由JVM使用Launcher初始化的system classloader载入的，根据全盘负责原
则，当我们进行造型的时候，JVM也会使用system classloader来尝试载入这个Class来对实例进行造型，自然在system classloader寻找不到
这个Class时就会抛出“java.lang.NoClassDefFoundError”的违例。
OK，现在让我们来总结一下，java文件的编译和Class的载入执行，都是使用Launcher初始化的system classloader作为类载入器的，我们无法
动态的改变system classloader，更无法让JVM使用我们自己的classloader来替换system classloader，根据全盘负责原则，就限制了编译和
运行时，我们无法直接显式的使用一个system classloader寻找不到的Class，即我们只能使用Java核心类库，扩展类库和CLASSPATH中的类库
中的Class。
还不死心！再尝试一下这种情况，我们把这个Class也放入到CLASSPATH中，让system classloader能够识别和载入。然后我们通过自己的
classloader来从指定的class文件中载入这个Class（不能够委托parent载入，因为这样会被system classloader从CLASSPATH中将其载入），
然后实例化一个Object，并造型成这个Class，这样JVM也识别这个Class（因为system classloader能够定位和载入这个Class从CLASSPATH中）
，载入的也不是CLASSPATH中的这个Class，而是从CLASSPATH外动态载入的，这样总行了吧！十分不幸的是，这时会出现
“java.lang.ClassCastException”违例。
为什么呢？我们也来分析一下，不错，我们虽然从CLASSPATH外使用我们自己的classloader动态载入了这个Class，但将它的实例造型的时候是
JVM会使用system classloader来再次载入这个Class，并尝试将使用我们的自己的classloader载入的Class的一个实例造型为system
classloader载入的这个Class（另外的一个）。大家发现什么问题了吗？也就是我们尝试将从一个classloader载入的Class的一个实例造型为
另外一个classloader载入的Class，虽然这两个Class的名字一样，甚至是从同一个class文件中载入。但不幸的是JVM却认为这个两个Class是
不同的，即JVM认为不同的classloader载入的相同的名字的Class（即使是从同一个class文件中载入的）是不同的！这样做的原因我想大概也
是主要出于安全性考虑，这样就保证所有的核心Java类都是system classloader载入的，我们无法用自己的classloader载入的相同名字的
Class的实例来替换它们的实例。
看到这里，聪明的读者一定想到了该如何动态载入我们的Class，实例化，造型并调用了吧！
那就是利用面向对象的基本特性之一的多形性。我们把我们动态载入的Class的实例造型成它的一个system classloader所能识别的父类就行了
！这是为什么呢？我们还是要再来分析一次。当我们用我们自己的classloader来动态载入这我们只要把这个Class的时候，发现它有一个父类
Class，在载入它之前JVM先会载入这个父类Class，这个父类Class是system classloader所能识别的，根据委托机制，它将由system
classloader载入，然后我们的classloader再载入这个Class，创建一个实例，造型为这个父类Class，注意了，造型成这个父类Class的时候（
也就是上溯）是面向对象的java语言所允许的并且JVM也支持的，JVM就使用system classloader再次载入这个父类Class，然后将此实例造型为
这个父类Class。大家可以从这个过程发现这个父类Class都是由system classloader载入的，也就是同一个class loader载入的同一个Class，
所以造型的时候不会出现任何异常。而根据多形性，调用这个父类的方法时，真正执行的是这个Class（非父类Class）的覆盖了父类方法的方
法。这些方法中也可以引用system classloader不能识别的Class，因为根据全盘负责原则，只要载入这个Class的classloader即我们自己定义
的classloader能够定位和载入这些Class就行了。
这样我们就可以事先定义好一组接口或者基类并放入CLASSPATH中，然后在执行的时候动态的载入实现或者继承了这些接口或基类的子类。还不
明白吗？让我们来想一想Servlet吧，web application server能够载入任何继承了Servlet的Class并正确的执行它们，不管它实际的Class是
什么，就是都把它们实例化成为一个Servlet Class，然后执行Servlet的init，doPost，doGet和destroy等方法的,而不管这个Servlet是从
web-inf/lib和web-inf/classes下由system classloader的子classloader(即定制的classloader)动态载入。说了这么多希望大家都明白了。
在applet,ejb等容器中,都是采用了这种机制.
对于以上各种情况，希望大家实际编写一些example来实验一下。
最后我再说点别的，classloader虽然称为类加载器，但并不意味着只能用来加载Class，我们还可以利用它也获得图片，音频文件等资源的URL
，当然，这些资源必须在CLASSPATH中的jar类库中或目录下。我们来看API的doc中关于ClassLoader的两个寻找资源和Class的方法描述吧：
public URL getResource(String name)
用指定的名字来查找资源，一个资源是一些能够被class代码访问的在某种程度上依赖于代码位置的数据（图片，音频，文本
等等）。
一个资源的名字是以'/'号分隔确定资源的路径名的。
这个方法将先请求parent classloader搜索资源，如果没有parent，则会在内置在虚拟机中的classloader（即bootstrap classloader）的路
径中搜索。如果失败，这个方法将调用findResource(String)来寻找资源。
public static URL getSystemResource(String name)
从用来载入类的搜索路径中查找一个指定名字的资源。这个方法使用system class loader来定位资源。即相当于
ClassLoader.getSystemClassLoader().getResource(name)。
例如：
System.out.println(ClassLoader.getSystemResource("java/lang/String.class"));
的结果为：
jar:file:/C:/j2sdk1.4.1_01/jre/lib/rt.jar!/java/lang/String.class
表明String.class文件在rt.jar的java/lang目录中。
因此我们可以将图片等资源随同Class一同打包到jar类库中（当然，也可单独打包这些资源）并添加它们到class loader的搜索路径中，我们
就可以无需关心这些资源的具体位置，让class loader来帮我们寻找了！
Java本身是一种设计的非常简单，非常精巧的语言，所以Java背后的原理也很简单，归结起来就是两点：
1、JVM的内存管理
理解了这一点，所有和对象相关的问题统统都能解决
2、JVM Class Loader
理解了这一点，所有和Java相关的配置问题，包括各种App Server的配置，应用的发布问题统统都能解决
App Class Loader
|----- EJB Class Loader
|----- Web App Class Loader
如果在App Class Loader级别配置，是全局可见的。如果打包在EJB里面，那么就不会影响到Web Application，反之亦然，如果你在WEB-INF下面放置Hibernate，也不会影响到EJB。放在EJB Class Loader或者放在Web App Class Loader级别主要就是在局部范围内有效，不影响到其它的应用。
试想，如果在一个Weblogic上面配置多个虚拟域，你使用www.bruce.com域名，开发你的网站，我使用www.fankai.com开发我的网站，那么当然不希望我们的Hibernate相互干扰，所以就可以放在 EJB Class Loader级别来配置Hibernate。
进一步阐述一下EJB Class Loader的问题：
先再次强调一下，Hibernate和EJB，和App Server不存在兼容性问题，他们本来就是不相关的东西，就好像JDBC，相信没有人会认为JDBC和EJB不兼容吧，Hibernate也是一样，它只和JDBC驱动，和数据库有兼容性问题，而和EJB，和App Server完全是不搭界的两回事。凡是认为Hibernate和EJB不兼容的人，其实是都是因为对EJB学习的不到家，把责任推到Hibernate身上了。
我前面提到过Class Loader的层次，这里不重复了，总之我们先来看看Class Loader的作用范围：
((Boot Strap)) Class Loader:
load JRE\lib\rt.jar, sunrsasign.jar, charsets.jar, jce.jar, jsse.jar, plugin.jar
Ext Class Loader:
load JRE\lib\ext目录下的库文件, load JRE\classes目录下的类
App Class Loader:
load CLASSPATH变量指定路径下的类
以上的load路径都是写死在JVM的C++源代码里面的，不能改变，详细请见王森的《Java深度历险》
在一个特定的App Server上，Class Loader会继续向下继承，继承的层次会根据不同的App Server有所不同，但是肯定不会变的就是：
EJB Class Loader:
继承自App Class Loader，继承层次根据App Server有所不同，一个EJB Class Loader它的load Class的范围仅限于JAR或者EAR范围之内。
Web App Class Loader:
继承自App Class Loader，继承层次根据App Server有所不同，一个Web App Class Loader:它的load Class的范围在 WEB-INF\lib下的库文件和WEB-INF\classes目录下的class文件。
Web App Class Loader很好理解，大家毕竟用的很多，App Server上的一个Web Application会创建一个Web App Class Loader的实例去负责load class，所以如果你想让Hibernate只在这个Web Application内生效，把它放到WEB-INF\lib下去就好了。
如果你把Hibernate放到了CLASSPATH变量指定的路径下，而你在WEB-INF\lib也放了一份，那么Web App Class Loader由于load范围所限，它会首先找到WEB-INF\lib下的那份Hibernate，按照它的配置来初始化Hibernate。
如果你把Hibernate放到了CLASSPATH变量指定的路径下，但你在WEB-INF\lib什么都没有放，那么Web App Class Loader由于load范围所限，它根本什么都找不到，于是它把load Hibernate的责任交给上一级的Class Loader，这样直到App Class Loader，它找到了Hibernate，按照它的配置来初始化Hibernate。
EJB Class Loader稍微复杂一点，不那么容易理解。App Server会针对每一个EJB包文件创建一个EJB Class Loader的实例，例如：
((Hello Robbin)).jar
((Hello Bruce)).jar
当你把这两个jar发布到App Server上以后，会创建两个EJB Class Loader的实例，分别去load这两个EJB包，比如说：
CLEJB_Robbin是load ((Hello Robbin)).jar的
CLEJB_Bruce是load ((Hello Bruce)).jar的
那么CLEJB_Robbin的load范围就仅仅限于HelloRobbin.jar之内，它load不到HelloRobbin.jar之外的任何文件，当然它也load不到HelloBruce.jar。
说到这里，我相信大家应该已经明白为什么EJB规范不允许EJB有IO操作了吧？因为EJB Class Loader根本找不到jar包之外的文件！！！
如果现在你想实现HelloRobbin.jar和HelloBruce.jar的互相调用，那么该怎么办？他们使用了不同的EJB Class Loader，相互之间是找不到对方的。解决办法就是使用EAR。
现在假设HelloRobbin.jar和HelloBruce.jar都使用了Hibernate，看看该怎么打包和发布：
HelloEJB.ear
|------ ((Hello Robbin)).jar
|------ ((Hello Bruce)).jar
|------ Hibernate2.jar
|------ pojo.jar (定义所有的持久对象和hbm文件的jar包)
|------ cglib-asm.jar
|------ commons-beanutils.jar
|------ commons-collections.jar
|------ commons-lang.jar
|------ commons-logging.jar
|------ dom4j.jar
|------ odmg.jar
|------ log4j.jar
|------ jcs.jar
|------ Hibernate.properties
|------ log4j.properties
|------ cache.ccf
|------ META-INF\application.xml (J2EE规范的要求，定义EAR包里面包括了哪几个EJB)
除此之外，按照EJB规范要求，HelloRobbin.jar和HelloBruce.jar还必须指出调用jar包之外的类库的名称，这需要在jar包的manifest文件中定义：
((Hello Robbin)).jar
|------ META-INF\MANIFEST.MF
MANIFEST.MF中必须包括如下一行：
Class-Path: log4j.jar hibernate2.jar cglib-asm.jar commons-beanutils.jar commons-collections.jar commons-lang.jar
commons-logging.jar dom4j.jar jcs.jar odmg.jar jcs.jar pojo.jar
这样就OK了，当把HelloEJB.ear发布到App Server上以后，App Server创建一个EJB Class Loader实例load EAR包里面的EJB，再根据EJB的jar包里面的MANIFEST.MF指出的Class-Path去寻找相应的jar包之外的类库。
所以一个EAR包有点类似一个Web Application，EJB Class Loader的load范围也就是EAR范围之内，它load不到EAR之外的文件。除非把Hibernate定义到CLASSPATH指定的路径下，在这种情况下，EJB Class Loader找不到Hibernate，只能交给上一级的Class Loader，最后由App Class Loader找到Hibernate，进行初始化。
由于EAR这样load Class规则，假设Robbin和Bruce都在同一个Weblogic上运行自己的网站，而我们都不希望自己的程序里面的Hibernate配置被对方的搞乱掉，那么我们就可以这样来做：
Robbin's Website:
Robbin.ear
|-------- robbin.war (把Web Application打包)
|-------- robbin.jar (把开发的EJB打包）
|-------- Hibernate2.jar
..........................
|-------- META-INF\application.xml
Bruce's Website:
Bruce.ear
|-------- bruce.war (把Web Application打包)
|-------- bruce.jar (把开发的EJB打包）
|-------- Hibernate2.jar
..........................
|-------- META-INF\application.xml
这样在同一个App Server上运行，就可以互相不干扰。
#################################################
richardluo 发表自dev2dev@bea
了解ClassLoader
1， 什么是 ClassLoader?
Java 程序并不是一个可执行文件，是需要的时候，才把装载到 JVM中。ClassLoader 做的工作就是 JVM 中将类装入内存。 而且，Java ClassLoader 就是用 Java 语言编写的。这意味着您可以创建自己的 ClassLoader
ClassLoader 的基本目标是对类的请求提供服务。当 JVM 需要使用类时，它根据名称向 ClassLoader 请求这个类，然后 ClassLoader 试图返回一个表示这个类的 Class 对象。 通过覆盖对应于这个过程不同阶段的方法，可以创建定制的 ClassLoader。
2， 一些重要的方法
A) 方法 loadClass
ClassLoader.loadClass() 是 ClassLoader 的入口点。该方法的定义如下：
Class loadClass( String name, boolean resolve
;
name JVM 需要的类的名称，如 Foo 或 java.lang.Object。
resolve 参数告诉方法是否需要解析类。在准备执行类之前，应考虑类解析。并不总是需要解析。如果 JVM 只需要知道该类是否存在或找出该类的超类，那么就不需要解析。
B) 方法 defineClass
defineClass 方法是 ClassLoader 的主要诀窍。该方法接受由原始字节组成的数组并把它转换成 Class 对象。原始数组包含如从文件系统或网络装入的数据。defineClass 管理 JVM 的许多复杂、神秘和倚赖于实现的方面 -- 它把字节码分析成运行时数据结构、校验有效性等等。不必担心，您无需亲自编写它。事实上，即使您想要这么做也不能覆盖它，因为它已被标记成final的。
C) 方法 findSystemClass
findSystemClass 方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用 defineClass 将原始字节转换成 Class 对象，以将该文件转换成类。当运行 Java 应用程序时，这是 JVM 正常装入类的缺省机制。（Java 2 中 ClassLoader 的变动提供了关于 Java 版本 1.2 这个过程变动的详细信息。） 对于定制的 ClassLoader，只有在尝试其它方法装入类之后，再使用 findSystemClass。原因很简单：ClassLoader 是负责执行装入类的特殊步骤，不是负责所有类。例如，即使 ClassLoader 从远程的 Web 站点装入了某些类，仍然需要在本地机器上装入大量的基本 Java 库。而这些类不是我们所关心的，所以要 JVM 以缺省方式装入它们：从本地文件系统。这就是 findSystemClass 的用途。
D) 方法 resolveClass
正如前面所提到的，可以不完全地（不带解析）装入类，也可以完全地（带解析）装入类。当编写我们自己的 loadClass 时，可以调用 resolveClass，这取决于 loadClass 的 resolve 参数的值。
E) 方法 findLoadedClass
findLoadedClass 充当一个缓存：当请求 loadClass 装入类时，它调用该方法来查看 ClassLoader 是否已装入这个类，这样可以避免重新装入已存在类所造成的麻烦。应首先调用该方法。
3， 怎么组装这些方法
1） 调用 findLoadedClass 来查看是否存在已装入的类。
2） 如果没有，那么采用那种特殊的神奇方式来获取原始字节。
3） 如果已有原始字节，调用 defineClass 将它们转换成 Class 对象。
4） 如果没有原始字节，然后调用 findSystemClass 查看是否从本地文件系统获取类。
5） 如果 resolve 参数是 true，那么调用 resolveClass 解析 Class 对象。
6） 如果还没有类，返回 ClassNotFoundException。
4，Java 2 中 ClassLoader 的变动
1）loadClass 的缺省实现
定制编写的 loadClass 方法一般尝试几种方式来装入所请求的类，如果您编写许多类，会发现一次次地在相同的、很复杂的方法上编写变量。 在 Java 1.2 中 loadClass 的实现嵌入了大多数查找类的一般方法，并使您通过覆盖 findClass 方法来定制它，在适当的时候 findClass 会调用 loadClass。 这种方式的好处是您可能不一定要覆盖 loadClass；只要覆盖 findClass 就行了，这减少了工作量。
2）新方法：findClass
loadClass 的缺省实现调用这个新方法。findClass 的用途包含您的 ClassLoader 的所有特殊代码，而无需要复制其它代码（例如，当专门的方法失败时，调用系统 ClassLoader）。
3） 新方法：getSystemClassLoader
如果覆盖 findClass 或 loadClass，getSystemClassLoader 使您能以实际 ClassLoader 对象来访问系统 ClassLoader（而不是固定的从 findSystemClass 调用它）。
4） 新方法：getParent
为了将类请求委托给父代 ClassLoader，这个新方法允许 ClassLoader 获取它的父代 ClassLoader。当使用特殊方法，定制的 ClassLoader 不能找到类时，可以使用这种方法。
父代 ClassLoader 被定义成创建该 ClassLoader 所包含代码的对象的 ClassLoader。
*****************************************************************
Java虚拟机（JVM）的动态类加载（Class Loading
1．介绍
Class Loaders是动态加载Java类与Resource的一种机制。它支持Laziness，type-safe linkage，user-defined extensibility和multiple communicating namespaces这4种特性。
l Lazy loading：Class只有在需要的时候才加载。这样减少了内存使用量，能提高系统反映速度；
l Type-safe linkage：动态类加载不会破坏JVM的类型安全；
l User-definable class loading policy：开发者可以自定义的类加载器，控制动态类加载过程；
l Multiple namespaces：JVM允许使用不同的类加载器加载相同的Class名称，但不同内容的类。
Class Loaders早在JDK1.0时就已存在，最开始的目的是使HotJava浏览器能加载Applet。从那以后，动态类加载机制被广泛应用到其他方面，例如web application server中Servlets的加载。class loader在JDK 1.0，1.1版本存在的缺陷，已经在JDK 1.2解决，其缺陷主要是编写不正确的Class Loader会造成类型安全问题。
2．Class Loaders
Class Loader的目的是动态加载Java类和Resource。Java类是平台无关的，标准的，具有规范二进制文件格式的。class文件有编译器生成，可以被任何一中JVM加载。Java类的表现形式不仅只有.class文件，还可以为内存buffer，或是网络数据流。
JVM执行class文件内的Byte code。但是Byte code不是class文件的全部内容，class文件内还包含符号表，表示类，属性和方法名，以及类内引用到其他类，属性，和方法名。例如下面的类
class C{
void f(){
D d=new D();
}
}
类文件内类C引用D。为了能让JVM知道D类是什么，JVM必须要先load D的class file并创建D class对象。
JVM使用类加载器加载类文件，并创建Class对象。类加载器都是ClassLoader的子类实例。ClassLoader.loadClass方法通过获得一个类名，返回一个Class对象，表示该类的类型。上面的代码里，假设C被类加载器L加载，则L是C的加载器。JVM将使用L加载所有被C引用到的其他Java类。
如果D还没有被加载，L将加载D：
L.loadClass(“D”)
当D已经被加载，JVM就可以创建D的一个对象实例。
一个Java应用程序可以使用不同类型的类加载器。例如Web Application Server中，Servlet的加载使用开发商自定义的类加载器， java.lang.String在使用JVM系统加载器,Bootstrap Class Loader，开发商定义的其他类则由AppClassLoader加载。在JVM里由类名和类加载器区别不同的Java类型。因此，JVM允许我们使用不同的加载器加载相同namespace的java类，而实际上这些相同namespace的java类可以是完全不同的类。这种机制可以保证JDK自带的java.lang.String是唯一的。
ClassLoader子类需要重载loadClass方法以实现用户自己的类加载方式，下面是自定义一个类加载器例子：
package org.colimas.webapp;
import java.io.File;
import java.io.IOException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.StringTokenizer;
/**
*类加载器加载Servlet，URLClassLoader是ClassLoader的一个子类，可以通过URL加载Java类或其它资源。
* @author 趙磊
*
*/
public class WebAppClassLoader extends URLClassLoader {
private ClassLoader _parent;
public WebAppClassLoader(ClassLoader parent) {
super(new URL[0], parent);
_parent=parent;
if (parent==null)
throw new IllegalArgumentException("no parent classloader!");
}
//追加一个Class Path。
public void addClassPath(String classPath) throws IOException{
if (classPath == null)
return;
StringTokenizer tokenizer= new StringTokenizer(classPath, ",;");
while (tokenizer.hasMoreTokens())
{
URL url=null;
File file=new File(tokenizer.nextToken()).getCanonicalFile();
url=file.toURI().toURL();
addURL(url);
}
}
//加载类
public synchronized Class loadClass(String name)
throws ClassNotFoundException {
return loadClass(name,false);
}
protected synchronized Class loadClass(String name, boolean resolve)
throws ClassNotFoundException {
Class c= findLoadedClass(name);
ClassNotFoundException ex= null;
if (c == null && _parent!=null ){
try{
c= _parent.loadClass(name);
}catch (ClassNotFoundException e){
ex= e;
}
}
if (c == null){
try{
c= this.findSystemClass(name);
}catch (ClassNotFoundException e){
ex= e;
}
}
if (c == null)
throw ex;
if (resolve)
resolveClass(c);
return c;
}
}
loadClass方法中使用findLoadedClass方法检查类是否已经被加载。该方法是Native方法，实现在JVM的ClassLoader.c文件内的Java_java_lang_ClassLoader_findLoadedClass函数。如果返回为null，则表示类还没有被加载，于是在其Parent类加载器重寻找_parent.loadClass，如果仍然返回null，则要在系统中查找，findSystemClass，如果仍然没有，则抛出异常。我们要确保多线程在同一时间只能加载一次，因此需要synchronized。
通常我们需要动态更新一个Class。例如一个Servlet实现发生变化时，我们希望不是重启服务器而是Reload。下面的类ServletWrapper提供了一个Servlet Reload的实现方法：
package org.colimas.webapp;
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
/**
* @author 趙磊
*
*/
public class ServletWrapper {
private Servlet theServlet;
private Class servletClass;
private ServletConfig config;
private String _servletname;
public ServletWrapper(ServletConfig config){
this.config=config;
}
public Servlet getServlet() throws ServletException{
synchronized (this) {
destroy();
try {
WebAppClassLoader loader=new WebAppClassLoader(this.getClass().getClassLoader());
String name=getServletName();
servletClass = loader.loadClass(name);
theServlet = (Servlet) servletClass.newInstance();
} catch( ClassNotFoundException ex1 ) {
} catch( InstantiationException ex ) {
}catch(IllegalAccessException ex2){
}
theServlet.init(config);
}
return theServlet;
}
public void destroy() {
if (theServlet != null) {
theServlet.destroy();
}
}
protected String getServletName(){
return _servletname;
}
}
getServlet()获得一个Servlet对象。首先创建一个新的Servlet类加载器。loader.loadClass加载最新的Servlet，servletClass.newInstance()实例化新的Servlet对象，并theServlet.init(config);让它运行起来。这种方法只有在不改变Servlet的接口时有效的。如果你要加载的类不实现任何接口，那么就不能在ServletWrapper直接使用该类名。而是定义为Object theServlet，并且theServlet = servletClass.newInstance();，而theServlet.init(config);也不得不改写为：
Method m= servletClass.getMethod(“init”,…);
m.invoke(theServlet,…);
3. Type-safe Linkage和Namespace一致性
JVM使用loaded class cache保存class名和加载该class的类加载器。当JVM通过loadClass获得class之后，它执行以下操作：
l 检查传给loadClass的类名是否和真实类名一致；
l 如果一致，则保存到loaded class cache里。
ClassLoader.findLoadedClass就是在loaded class cache查找class是否存在的。
为了保证Type-safe，Sun公司做了很多工作，目前也有不止一个解决方案。例如，增加约束规则（Contraint Rule）等。
2006年9月25日
亲爱的，看到你哭，我真的很伤心，我不想让你哪怕一点点地伤害，你真的太脆弱了，
工作是有点苦，但是在苦我也不想看到你的眼泪。
以后，我会努力的，让你不哭，让你高兴！
答应我，别哭
我的宝贝！