标签：工作原理 lin 解决 模型 不能 .com load com 实例
一、tomcat是个web容器，要解决以下问题
1. 一个web容器可能要部署两个或者多个应用程序，不同的应用程序，可能会依赖同一个第三方类库的不同版本，因此要保证每一个应用程序的类库都是独立、相互隔离的。
2. 部署在同一个web容器中的相同类库的相同版本可以共享，否则，会有重复的类库被加载进JVM
3. web容器也有自己的类库，不能和应用程序的类库混淆，需要相互隔离
4. web容器支持jsp文件修改后不用重启，jsp文件也是要编译成.class文件的，支持HotSwap功能
二、tomcat使用Java默认类加载器的问题
1. 默认的类加载器无法加载两个相同类库的不同版本，它只在乎类的全限定类名，并且只有一份，所以无法解决上面1和3，相互隔离的问题
2. 修改jsp文件后，因为类名一样，默认的类加载器不会重新加载，而是使用方法区中已经存在的类；所以需要每个jsp对应一个唯一的类加载器，当修改jsp的时候，直接卸载唯一的类加载器，然后重新创建类加载器，并加载jsp文件
三、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实例之间相互隔离
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目录。
四、小结
tomcat为了实现隔离性，每个webappClassLoader加载自己目录下的class文件，而不会传给父类加载器去加载。所以破坏了Java默认类加载器的双亲委派模型。
五、其他破坏了双亲委派模型的技术
1. OSGI是基于Java语言的动态模块化规范，类加载器之间是网状结构，更加灵活，但是也更复杂
2. JNDI服务，使用线程上线文类加载器，父类加载器去使用子类加载器
参考文档：
https://blog.csdn.net/qq_38182963/article/details/78660779
标签：工作原理 lin 解决 模型 不能 .com load com 实例
原文地址：https://www.cnblogs.com/june0816/p/10090428.html
