tomcat类加载器为何要破坏双亲委派机制？

1、tomcat是个web容器，要解决如下问题

1. 一个web容器可能要部署两个或者多个应用程序，不一样的应用程序，可能会依赖同一个第三方类库的不一样版本，所以要保证每个应用程序的类库都是独立、相互隔离的。

2. 部署在同一个web容器中的相同类库的相同版本能够共享，不然，会有重复的类库被加载进JVM

3. web容器也有本身的类库，不能和应用程序的类库混淆，须要相互隔离

4. web容器支持jsp文件修改后不用重启，jsp文件也是要编译成.class文件的，支持HotSwap功能

 

2、tomcat使用Java默认类加载器的问题

1. 默认的类加载器没法加载两个相同类库的不一样版本，它只在意类的全限定类名，而且只有一份，因此没法解决上面1和3，相互隔离的问题

2. 修改jsp文件后，由于类名同样，默认的类加载器不会从新加载，而是使用方法区中已经存在的类；因此须要每一个jsp对应一个惟一的类加载器，当修改jsp的时候，直接卸载惟一的类加载器，而后从新建立类加载器，并加载jsp文件

 

3、tomcat的类加载机制

1. 架构图

2. tomcat本身定义的类加载器：

CommonClassLoader：tomcat最基本的类加载器，加载路径中的class能够被tomcat和各个webapp访问

CatalinaClassLoader：tomcat私有的类加载器，webapp不能访问其加载路径下的class，即对webapp不可见

SharedClassLoader：各个webapp共享的类加载器，对tomcat不可见

WebappClassLoader：webapp私有的类加载器，只对当前webapp可见

JspClassLoader

3. 每个web应用程序对应一个WebappClassLoader，每个jsp文件对应一个JspClassLoader，因此这两个类加载器有多个实例

4. 工做原理：

a. CommonClassLoader能加载的类均可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用

b. CatalinaClassLoader和Shared ClassLoader本身能加载的类则与对方相互隔离

c. WebAppClassLoader可使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离，多个WebAppClassLoader是同级关系

d. 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并经过再创建一个新的Jsp类加载器来实现JSP文件的HotSwap功能

5. tomcat目录结构，与上面的类加载器对应

/common/*

/server/*

/shared/*

/WEB-INF/*

6. 默认状况下，conf目录下的catalina.properties文件，没有指定server.loader以及shared.loader，因此tomcat没有创建CatalinaClassLoader和SharedClassLoader的实例，这两个都会使用CommonClassLoader来代替。Tomcat6以后，把common、shared、server目录合成了一个lib目录。因此在咱们的服务器里看不到common、shared、server目录。

 

 

4、tomcat类加载器和双亲委派模型的关系

1. tomcat为了实现隔离性和热替换，没有使用默认的类加载器，而是本身实现了类加载器：

每一个webappClassLoader加载本身目录下的class文件

每一个jasper类加载器加载一个jsp文件

2. 双亲委派模型的标准是：每一个类加载器要加载类的时候，先传给父类加载器加载，父类加载器加载不了的时候，才由本身加载

3. webappClassLoader和jasperClassLoader没有传给父类加载器去加载，仍是传给了父类加载器而父类加载器加载不了？先本身加载

4. 从WebappClassLoader.loadClass源码上看，确实没有传给父类加载器去加载，确实破坏了双亲委派模型，对于一些未加载的非基础类(非Object,String等)，各个web应用本身的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托

hasExternalRepositories && searchExternalFirst 默认为false

5. 为何要破坏？不破坏行不行？每一个webapp有本身的目录和类库，好比一个webapp使用类库A1.0版本，一个webapp使用类库A2.0版本，父类加载器加载类库A1.0版本，若是使用双亲委派，会由commonClassLoader去加载类库A1.0版本，这样第二个webapp会有问题

6. 能够经过在Context.xml文件中加上<Loader delegate = "true">开启正统的“双亲委派”加载机制

public Class<?> findClass(String name) throws ClassNotFoundException { // 其余代码略去..... // Ask our superclass to locate this class, if possible // (throws ClassNotFoundException if it is not found)
        Class<?> clazz = null; try { if (log.isTraceEnabled()) log.trace("      findClassInternal(" + name + ")"); // (1)默认为false
            if (hasExternalRepositories && searchExternalFirst) { try { clazz = super.findClass(name); } catch(ClassNotFoundException cnfe) { // Ignore - will search internal repositories next
                } catch(AccessControlException ace) { log.warn("WebappClassLoaderBase.findClassInternal(" + name + ") security exception: " + ace.getMessage(), ace); throw new ClassNotFoundException(name, ace); } catch (RuntimeException e) { if (log.isTraceEnabled()) log.trace("      -->RuntimeException Rethrown", e); throw e; } } // (2)
            if ((clazz == null)) { try { clazz = findClassInternal(name); } catch(ClassNotFoundException cnfe) { if (!hasExternalRepositories || searchExternalFirst) { throw cnfe; } } catch(AccessControlException ace) { log.warn("WebappClassLoaderBase.findClassInternal(" + name + ") security exception: " + ace.getMessage(), ace); throw new ClassNotFoundException(name, ace); } catch (RuntimeException e) { if (log.isTraceEnabled()) log.trace("      -->RuntimeException Rethrown", e); throw e; } } //其余代码略去........
        return (clazz); }

 

 加载过程：

1. 先在本地缓存中查找是否已经加载过该类(对于一些已经加载了的类，会被缓存在resourceEntries这个数据结构中)，若是已经加载即返回，不然 继续下一步。
2. 让系统类加载器(AppClassLoader)尝试加载该类，主要是为了防止一些基础类会被web中的类覆盖，若是加载到即返回，返回继续。
3. 前两步均没加载到目标类，那么web应用的类加载器将自行加载，若是加载到则返回，不然继续下一步。
4. 最后仍是加载不到的话，则委托父类加载器(Common ClassLoader)去加载。

 

 

5、其余破坏了双亲委派模型的技术

1. OSGI是基于Java语言的动态模块化规范，类加载器之间是网状结构，更加灵活，可是也更复杂

2. JNDI服务，使用线程上线文类加载器，父类加载器去使用子类加载器

 

 

 

 

参考文档：

http://www.javashuo.com/article/p-nqgssvfe-d.html

http://www.javashuo.com/article/p-hdpezkrq-hx.html

http://www.javashuo.com/article/p-blkkoeru-dm.html