Java和Tomcat类加载机制

神甫

　　阿里的面试题，当场晕了
　　http://blog.csdn.net/codolio/archive/2009/12/17/5027423.aspx
　　加载类是运行程序的基础，了解Java和Tomcat的类加载机制对更有效地开发、调试Web应用程序有一定的积极作用。本文简单介绍Java和Tomcat的类加载机制，希望对大家有所帮助。
　　·JDK/JRE文件结构
在安装JDK后，其典型的目录层次如下所示（JDK 1.6.0）：
　　
 　　

　　主要的目录和JAR简述如下：
　　·<JAVA_HOME>\bin: 包含在JDK中的开发工具的可执行文件，一般而言，PATH环境变量应包含该目录。
·<JAVA_HOME>\lib: 开发工具使用的文件，其中包括（1）tools.jar：该JAR包包含支持JDK中工具类和实用类的非核心类。同时也包含（2）dt.jar：BeanInfo使用的设计时（DesignTime）归档文件，该JAR包告诉IDE如何显示Java组件和如何让开发者定制它们。其中主要包含Swing的相关类。
·<JAVA_HOME>\jre\lib：包含Java运行时环境使用的核心类、属性设置和资源文件等。例如：（1）rt.jar：引导类（组成Java平台核心API的运行时类）；（2）charsets.jar：字符转换类。
在一个典型的Web应用环境中，在设置CLASSPATH环境变量是，通常需要包含以下条目：
　　
·设置好path变量，使得我们能够在系统中的任何地方运行java应用程序，比如javac、java、javah等等，变量值: C:\jdk1.6.0\bin;
　　·classpath环境变量，是当我们在开发java程序时需要引用别人写好的类时，要让java解释器知道到哪里去找这个类。C:\jdk1.6.0\lib\tools.jar;C:\jdk1.6.0\lib\dt.jar。
　　·设置JAVA_HOME: 了方便引用。C:\jdk1.6.0　　

注：在使用Tomcat作为Servlet/JSP容器的Web环境中，Tomcat在启动过程中清除了原有CLASSPATH的内容，并对其进行了重新定义。细节见下文。

　　·Java类加载机制
Java启动器（java）初始化Java虚拟机。虚拟机按照如下顺序搜索加载类：
　　1.引导类：组成Java平台的类，包括rt.jar和一些别的重要的jar文件；
2.扩展类：使用Java扩展机制的类，这些类捆绑成JAR文件，并被放置在扩展目录中；每一个在jre/lib/ext扩展目录下的JAR文件均被设定为一个扩展并使用Java扩展架构加载；
3.用户类：由开发者定义的类和没有利用扩展机制的第三方类，这些类的位置由用户指定，一般通过使用-classpath命令行选项或者使用CLASSPATH环境变量来指定其位置。
与之相对应，自从J2SE 1.2规范起，JVM就已经利用了三种不同的类加载器：
　　
·引导类（Bootstrap）加载器（也称为初始类加载器）；
·扩展类加载器；
·系统类加载器。
这些类加载器是有层次的，系统类加载器位于底层，而引导类加载器位于上层，它们之间的关系为父-子关系。
　　·引导类加载器：引导类加载器用于JVM加载那些它运行所需的Java类。实际上，引导类加载器负责加载所有核心的Java类（如java.lang.*和java.io.*）。一般各种JVM厂商（包括Sun）使用本地代码实现引导类加载器。
·扩展类加载器：Java 1.2引入了标准扩展机制。可以将JAR文件放置在标准扩展目录，JVM将能自动地找到它们。扩展类加载器负责加载一个或者多个扩展目录中的所有类。一般情况下，只要安装了Java运行环境（JRE），那么扩展目录为<JRE>/lib/ext。扩展类加载器可以不是独立的类加载器，一些实现也许甚至允许引导类加载器从扩展目录加载类。
·系统类加载器：系统类加载器在CLASSPATH环境变量指定的JAR文件中查找自己的类，或通过-classpath命令行选项传递该类，如果没有指定，则默认使用当前目录。系统加载器也用于加载应用程序的entry point类（即含有main()方法的类），对于那些其他任何没有涵盖在以上两类加载器中的类，都默认使用系统类加载器。
　　·委派模型：JVM通过利用委派模型知道将使用哪个类加载器。Java JDK 1.2以后的版本，无论类加载器何时收到加载类的请求。在一个类加载器试图加载一个请求的类之前，它委派该加载请求到其父类类加载器，直到引导类加载器。如果父类加载器成功加载所请求的类，那么就返回作为结果的类对象，只有当父类加载器未能加载该类的情况下，原始的类加载器才尝试装载该类。
注：类加载器的更多行为：
　　
·懒散加载：上述类加载器并没有预加载在搜索该路径中的所有类。相反它按要求加载类。这样的行为称为懒散加载。
·类缓存：标准的Java SE类加载器可以按要求查找类，但一旦某个类被加载到类加载器中，它将维持加载（缓存）一段时间。不过，JVM垃圾收集器可以回收这些Class对象。
·独立的命名空间：为每个类加载器分配了唯一的命名空间。
·Apache Tomcat 5.5 Servlet/JSP类加载机制：
同其它服务器应用程序类似，Tomcat 5安装了多种类加载器（即，实现了java.lang.ClassLoader接口的类），来允许容器的不同部分和运行在容器中的Web应用程序来访问不同可用类和资源的库。
　　当Tomcat 5启动时，它创建了一套类加载器，这些加载器组织成如下的父子关系，其中父类加载器位于子类加载器之上（Tomcat 6.0版本的类加载器层次结构发生了变化）：
　　 　　

　　加载器定义如下：
　　·Bootstrap：该加载器包含由JVM提供的基本的运行时类，加上放置在系统扩展目录（<JAVA_HOME\jre\lib\ext>）的JAR文件中的类。注：一些JVM将该加载器实现为一个以上的类加载器，或者它完全不可见；
·System：系统加载器，该加载器通常使用CLASSPATH环境变量来初始化。但是标准的Tomcat 5启动脚本（<CATALINA_HOME>/bin/catalina.sh或者<CATALINA_HOME>\bin\catalina.bat>）完全忽略了CLASSPATH环境变量的内容，并使用下述库来构建System类加载器。如下：
 

　　从上图可以看出，Tomcat使用的CLASSPATH并非我们先前配置的目录。
　　         <CATALINA_HOME>\bin\bootstrap.jar：包含初始化Tomcat 5服务器的main()方法和它所依赖的类加载器实现；
　　       <JAVA_HOME>\lib\tools.jar：包含" javac "编译器用来将JSP页面转化为servlet类；
       <CATALINA_HOME>\bin\commons-logging-api-x.y.z.jar：包含commons logging API；
       <CATALINA_HOME>\bin\commons-daemon.jar：包含commons daemon API；
       jmx.jar ：包含JMX 1.2实现。
　　
·Common：该类加载器包含一些对Tomcat内部类和web应用可见的额外类。其中包括（1）jasper-compiler.jar：JSP 2.0编译器（2）jsp-api.jar：JSP 2.0 API（3）servlet-api.jar：servlet 2.4 API等等。
·Catalina：该加载器初始化用来包含实现Tomcat 5本身所需要所有类和资源；
·Shared：在所有的web应用程序间共享的类和资源；
·WebappX：为每个部署在单个Tomcat 5实例上的Web应用创建的类加载器。加载/WEB-INF/classes和WEB-INF/lib下的类和资源。
值得注意的是，Web应用程序类加载器行为与默认的Java 2委派模型不同。当一个加载类的请求被WebappX类加载器处理时，类加载器将首先查看本地库，而非在查看前就委派，但是也有例外，作为JRE基本类一部分的类不能被覆盖，但是对与一些类，可以使用J2SE 1.4的Endorsed Standards Override机制。最后，任何包含servlet API的JAR包都将被该类加载器忽略。Tomcat 5所有其它的类加载器遵循常用的委派模式。具体细节请参见Tomcat 5的参考文档。
　　
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/codolio/archive/2009/12/17/5027423.aspx