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）等。