一、从类加载器(ClassLoader)结构说起
1.基本介绍(此部分可参见<<Core Java 2 Volume II>> Chapter9. Security)
顾名思义,类加载器是用于加载Java的类定义信息(.class)。需要注意的是类加载器仅在需要的才加载类定义信息,参见<<Core Java 2 Volume II>> Chapter9. Security关于ClassLoader的说明如下
Note that the virtual machine loads only those class files that are needed for the execution of a program. For example, suppose program execution starts with MyProgram.class. Here are the steps that the virtual machine carries out.
- The virtual machine has a mechanism for loading class files, for example, by reading the files from disk or by requesting them from the Web; it uses this mechanism to load the contents of the MyProgram class file.
- If the MyProgram class has instance variables or superclasses of another class type, these class files are loaded as well. (The process of loading all the classes that a given class depends on is called resolving the class.)
- The virtual machine then executes the main method in MyProgram (which is static, so no instance of a class needs to be created).
- If the main method or a method that main calls requires additional classes, these are loaded next.
JVM的类加载机制使用多个ClassLoader来完成类加载的功能,譬如JVM至少会包含如下三个类加载器:
- The bootstrap class loader:启动类加载器,是JVM的组成部分,使用C语言实现。加载JVM基础Class(譬如rt.jar)。实际没有Bootstrap类加载器的实例,譬如String.class.getClassLoader()返回null
- The extension class loader:扩展类加载器,JVM标准扩展类加载器,加载位于{jre path}/lib/ext目录下类
- The system class loader:系统加载器,加载在classpath路径下定义的class
我们可以通过 obj.getClass().getClassLoader()来获得对象相应的类定义是由哪个ClassLoader加载的
2.对象创建和ClassLoader
JVM提供了如下三种创建对象的方式
- new:通过new操作创建对象,那么相应对象的类定义由创建操作所在的类的类加载器加载
- Class.forName("...").newInstance:类定义的加载器与new相同
- xxxClassLoader.loadClass("...").newInstance:类定义的加载器为xxxClassLoader
需要注意的是,JVM识别类定义之间是否一样,除了检查类全名(譬如xxx.MyClass)是否一样,还检查其相应的ClassLoader是否一样。譬如如下操作会抛出ClassCastException
Object obj = xxxClassLoader.loadClass("xxx.MyClass").newInstance(); //此处xxxClassLoader的parent不是当前类的加载器
xxx.MyClass xxx = (xxx.MyClass) obj;//ClassLoader不一样,因此JVM认为是类型是不一样的
3.ClassLoader代码分析(java.lang.ClassLoader)
我们从入口loadClass开始
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
//检查是是否已经加载过
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
//代理给parent去加载类
c = parent.loadClass(name, false);
} else {
//由Bootstrap去加载类
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
//parent和Bootstrap都无法加载,则由自定义的方式去加载类
//通过扩展该方法来实现自定义的类加载器
c = findClass(name);
}
}
//这是标准的也是JVM推荐的类加载方式,先由parent,然后由Bootstrap,最后是自定义的类,然而Servlet规范定义的是与此相悖的,后面我们再看
if (resolve) {
resolveClass(c);
}
return c;
}
自定义的类加载器主要会有两个过程:获得类定义的byte串、解析byte串到class的结构,第一个步骤是我们应该处理的,而第二个步骤是JVM直接提供的,也就是ClassLoader的defineClass方法,有兴趣可以看看java.lang.ClassLoader.defineClass方法
二、Tomat类加载器结构
1.如下是Tomcat6的类加载器结果图
写道
[BootStrapClassLoader](实际没有这个类)
|
ExtensionClassLoader(对于Sun JVM,是sun.misc.Launcher$ExtClassLoader)
|
SystemClassLoader(对于Sun JVM,是sun.misc.Launcher$AppClassLoader)
|
CommonClassLoader(对于Tomcat 6,是org.apache.catalina.loader.StandardClassLoader)
/ \
CatalinaClassLoader SharedClassLoader
|
org.apache.catalina.loader.WebappClassLoader
|
org.apache.jasper.servlet.JasperLoader
- CommonClassLoader:加载的类目录通过{tomcat}/conf/catalina.properties中的common.loader指定,以SystemClassLoader为parent(目前默认定义是common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar)
- CatalinaClassLoader :加载的类目录通过{tomcat}/conf/catalina.properties中server.loader指定,以CommonClassLoader为parent,如果server.loader配置为空,则ServerClassLoader 与CommonClassLoader是同一个(默认server.loader配置为空)
- SharedClassLoader:加载的类目录通过{tomcat}/conf/catalina.properties中share.loader指定,以CommonClassLoader为parent,如果server.loader配置为空,则CatalinaClassLoader 与CommonClassLoader是同一个(默认share.loader配置为空)
- WebappClassLoader:每个Context一个WebappClassLoader实例,负责加载context的/WEB-INF/lib和/WEB-INF/classes目录,context间的隔离就是通过不同的WebappClassLoader来做到的。由于类定义一旦加载就不可改变,因此要实现tomcat的context的reload功能,实际上是通过新建一个新的WebappClassLoader来做的,因此reload的做法实际上代价是很高昂的,需要注意的是,JVM内存的Perm区是只吃不拉的,因此抛弃掉的WebappClassLoader加载的类并不会被JVM释放,因此tomcat的reload功能如果应用定义的类比较多的话,reload几次就OutOfPermSpace异常了。(关于JVM的内存管理,可以参见之前的文章
,后续对这一块重新做总结)
- JasperLoader:每个JSP一个JasperLoader实例,与WebappClassLoader做法类似,JSP支持修改生效是通过丢弃旧的JasperLoader,建一个新的JasperLoader来做到的,同样的,存在轻微的PermSpace的内存泄露的情况
2.WebappClassLoader详解
我们来看看WebappClassLoader具体是如何实现的,如上,loadClass方法是我们的重点(有时候我们的类会使用Class.getResourceAsStream或者ClassLoader.getResourceAsStream,这种搜索资源的方式会与loadClass的机制类似,因此这里不重复说明)。
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException {
if (log.isDebugEnabled())
log.debug("loadClass(" + name + ", " + resolve + ")");
Class clazz = null;
// Log access to stopped classloader
if (!started) {
try {
throw new IllegalStateException();
} catch (IllegalStateException e) {
log.info(sm.getString("webappClassLoader.stopped", name), e);
}
}
// (0) 检查WebappClassLoader之前是否已经load过这个资源
clazz = findLoadedClass0(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Returning class from cache");
if (resolve)
resolveClass(clazz);
return (clazz);
}
// (0.1) 检查ClassLoader之前是否已经load过
clazz = findLoadedClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Returning class from cache");
if (resolve)
resolveClass(clazz);
return (clazz);
}
// (0.2) 先检查系统ClassLoader,因此WEB-INF/lib和WEB-INF/classes或{tomcat}/libs下的类定义不能覆盖JVM 底层能够查找到的定义(譬如不能通过定义java.lang.Integer替代底层的实现
try {
clazz = system.loadClass(name);
if (clazz != null) {
if (resolve)
resolveClass(clazz);
return (clazz);
}
} catch (ClassNotFoundException e) {
// Ignore
}
// (0.5) Permission to access this class when using a SecurityManager
if (securityManager != null) {
int i = name.lastIndexOf('.');
if (i >= 0) {
try {
securityManager.checkPackageAccess(name.substring(0,i));
} catch (SecurityException se) {
String error = "Security Violation, attempt to use " +
"Restricted Class: " + name;
log.info(error, se);
throw new ClassNotFoundException(error, se);
}
}
}
//这是一个很奇怪的定义,JVM的ClassLoader建议先由parent去load,load不到自己再去load(见如上 ClassLoader部分),而Servelet规范的建议则恰好相反,Tomcat的实现则做个折中,由用户去决定(context的 delegate定义),默认使用Servlet规范的建议,即delegate=false
boolean delegateLoad = delegate || filter(name);
// (1) 先由parent去尝试加载,此处的parent是SharedClassLoader,见如上说明,如上说明,除非设置了delegate,否则这里不执行
if (delegateLoad) {
if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader1 " + parent);
ClassLoader loader = parent;
//此处parent是否为空取决于context 的privileged属性配置,默认privileged=true,即parent为SharedClassLoader
if (loader == null)
loader = system;
try {
clazz = loader.loadClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from parent");
if (resolve)
resolveClass(clazz);
return (clazz);
}
} catch (ClassNotFoundException e) {
;
}
}
// (2) 到WEB-INF/lib和WEB-INF/classes目录去搜索,细节部分可以再看一下findClass,会发现默认是先搜索WEB-INF/classes后搜索WEB-INF/lib
if (log.isDebugEnabled())
log.debug(" Searching local repositories");
try {
clazz = findClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from local repository");
if (resolve)
resolveClass(clazz);
return (clazz);
}
} catch (ClassNotFoundException e) {
;
}
// (3) 由parent再去尝试加载一下
if (!delegateLoad) {
if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader at end: " + parent);
ClassLoader loader = parent;
if (loader == null)
loader = system;
try {
clazz = loader.loadClass(name);
if (clazz != null) {
if (log.isDebugEnabled())
log.debug(" Loading class from parent");
if (resolve)
resolveClass(clazz);
return (clazz);
}
} catch (ClassNotFoundException e) {
;
}
}
throw new ClassNotFoundException(name);
}
分享到:
相关推荐
【标题】"Tomcat源码分析系列文档"深入解析了Apache Tomcat服务器的内部工作原理,涵盖了一系列关键知识点,如HTTP协议、类加载机制、容器设计模式等。这些文档为理解Tomcat的运行机制提供了宝贵的资源。 【描述】...
Java 类加载器是Java虚拟机(JVM)的核心组成部分,它负责将编译后的字节码文件(.class文件)加载到JVM中并转换为运行时的数据结构。Tomcat,作为广泛使用的Java Servlet容器,它自定义了一套类加载机制,以满足Web...
源码解析部分则是对Tomcat源码的深度剖析,涵盖了关键类和方法的作用、设计模式的运用以及性能优化技巧。这有助于开发者理解Tomcat内部的工作流程,例如,如何处理HTTP请求的生命周期,以及线程池是如何调度和管理的...
Apache Tomcat源码分析 Apache Tomcat是一款广泛应用的开源Java Servlet容器,它是Java EE Web应用程序的标准实现。Tomcat源码的深入理解对于Java Web开发者来说是至关重要的,它可以帮助我们了解HTTP服务器的工作...
3-7Tomcat中自定义类加载器的使用与源码实现(1).mp4
类加载遵循“双亲委托模型”,即当一个类加载器收到加载类的请求时,它会首先委托父类加载器尝试加载,只有当父类加载器无法找到对应的类时,才会自己尝试加载。这样保证了基础类库的一致性,同时也允许Web应用覆盖...
Tomcat使用自定义的类加载器来加载Web应用中的类,以实现不同应用之间的类隔离。主要有CommonClassLoader、SharedClassLoader和WebappClassLoader,它们按层次加载类。 5. **连接器(Connector)与协议处理器...
这些问题可能包括端口被占用、配置文件错误、类加载器相关问题等。通过对这些问题的分析,我们可以更加深入地理解Tomcat的工作机制,以及其在不同环境下可能遇到的问题和解决方案。 3. 架构探讨:Tomcat拥有清晰的...
一、Tomcat7源码结构解析 Tomcat7的源代码结构清晰,主要包含以下几个核心模块: 1. catalina:这是Tomcat的核心模块,负责处理Servlet容器的主要功能,如Servlet和Context的生命周期管理,请求处理等。 2. ...
源码中的`Host`和`Context`类展示了如何解析WAR文件并加载应用到服务器。 5. **JMX(Java Management Extensions)**:Tomcat支持JMX,允许管理员监控和管理服务器状态。查看`jmx`目录下的源码可以了解如何使用JMX...
Catalina通过生命周期管理类加载器、请求处理和会话管理。深入理解`org.apache.catalina`包下的类,特别是`Engine`、`Host`、`Context`和`Wrapper`,它们分别代表了服务器、虚拟主机、Web应用和Servlet实例。 3. **...
2. **类加载机制**:Tomcat使用自定义的类加载器,如`CommonClassLoader`、`WebappClassLoader`等,以实现不同Web应用间的隔离。 3. **请求处理**:` CoyoteAdapter`是Servlet容器与Tomcat网络接口(Coyote)之间的...
JVM采用**父类委托机制**来加载类,这意味着当一个类加载器接收到加载请求时,它首先会委托给其父类加载器尝试加载,直到达到Bootstrap类加载器(顶级加载器)。如果父类加载器找不到所需类,那么请求会回溯到子类...
【标题】"Tomcat源码学习:一个最简单的‘Tomcat’",这篇博客主要探讨的是如何通过学习Tomcat的源代码来理解这个流行的开源Java Servlet容器的工作原理。Tomcat是Apache软件基金会的一个项目,它是Java Web应用...
《深入解析Spring Instrument Tomcat源码》 Spring框架以其强大的功能和灵活性在Java开发领域占据着举足轻重的地位。而Spring Instrument Tomcat模块则是Spring框架中的一个重要组成部分,它为Tomcat服务器提供了类...
3. **Servlet生命周期**:Servlet在Tomcat中的生命周期包括加载、初始化、服务、销毁四个阶段。Tomcat通过Servlet容器管理Servlet实例,确保其正确地创建、初始化和销毁。 4. **请求处理**:当一个HTTP请求到达时,...
《深入理解Tomcat源码与依赖包》 Tomcat,作为Apache软件基金会的顶级项目,是广泛应用的开源Java Servlet容器,它实现了Java EE中的Servlet和JavaServer Pages(JSP)规范。本文将深入探讨Tomcat的源码以及相关...
源码阅读可以帮助我们理解其内部机制,如请求解析、连接管理、线程池、类加载器等核心功能的实现。 "可直接导入eclipse"这一特点意味着开发者无需额外的配置步骤,只需简单操作即可在Eclipse这样的集成开发环境中...