[Tomcat源码系列] Tomcat 类加载器结构

xuol001

　　一、从类加载器(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);
}