标签：类库 Java tomcat Tomcat 双亲 jsp 加载
tomcat相关的源码解析
深入理解 Tomcat（一）源码环境搭建和 How Tomcat works 源码
深入理解 Tomcat (二) 从宏观上理解 Tomcat 组件及架构
深入理解 Tomcat（三）Tomcat 底层实现原理
深入理解 Tomcat（四）Tomcat 类加载器之为何违背双亲委派模型
深入理解 Tomcat（五）源码剖析Tomcat 启动过程----类加载过程
深入理解 Tomcat（六）源码剖析Tomcat 启动过程----生命周期和容器组件
深入理解 Tomcat（七）源码剖析 Tomcat 完整启动过程
深入理解 Tomcat（八）源码剖析之连接器
深入理解 Tomcat（九）源码剖析之请求过程
深入理解 Tomcat(十) 总结
1. 如何破坏双亲委任模型？
刚刚我们说过，双亲委任模型不是一个强制性的约束模型，而是一个建议型的类加载器实现方式。在Java的世界中大部分的类加载器都遵循者模型，但也有例外，到目前为止，双亲委派模型有过3次大规模的“被破坏”的情况。
第一次：在双亲委派模型出现之前-----即JDK1.2发布之前。
第二次：是这个模型自身的缺陷导致的。我们说，双亲委派模型很好的解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API， 但没有绝对，如果基础类调用会用户的代码怎么办呢？
这不是没有可能的。一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器去加载（在JDK1.3时就放进去的rt.jar）,但它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI， Service Provider Interface）的代码，但启动类加载器不可能“认识“这些代码啊。因为这些类不在rt.jar中，但是启动类加载器又需要加载。怎么办呢？
为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader方法进行设置。如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过多的话，那这个类加载器默认即使应用程序类加载器。
嘿嘿，有了线程上下文加载器，JNDI服务使用这个线程上下文加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则。但这无可奈何，Java中所有涉及SPI的加载动作基本胜都采用这种方式。例如JNDI，JDBC，JCE，JAXB，JBI等。
第三次：为了实现热插拔，热部署，模块化，意思是添加一个功能或减去一个功能不用重启，只需要把这模块连同类加载器一起换掉就实现了代码的热替换。
书中还说到：
Java 程序中基本有一个共识：OSGI对类加载器的使用时值得学习的，弄懂了OSGI的实现，就可以算是掌握了类加载器的精髓。
牛逼啊！！！
现在，我们已经基本明白了Java默认的类加载的作用了原理，也知道双亲委派模型。说了这么多，差点把我们的tomcat给忘了，我们的题目是Tomcat 加载器为何违背双亲委派模型？下面就好好说说我们的tomcat的类加载器。
2. Tomcat 的类加载器是怎么设计的？
首先，我们来问个问题：
Tomcat 如果使用默认的类加载机制行不行？
我们思考一下：Tomcat是个web容器， 那么它要解决什么问题：
- 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
- 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。
- web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
- web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。
再看看我们的问题：Tomcat 如果使用默认的类加载机制行不行？
答案是不行的。为什么？我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
Tomcat 如何实现自己独特的类加载机制？
所以，Tomcat 是怎么实现的呢？牛逼的Tomcat团队已经设计好了。我们看看他们的设计图：
我们看到，前面3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载/common/*、/server/*、/shared/*（在tomcat 6之后已经合并到根目录下的lib目录下）和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。
- commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
- catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
- sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
- WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；
从图中的委派关系中可以看出：
CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。
好了，至此，我们已经知道了tomcat为什么要这么设计，以及是如何设计的，那么，tomcat 违背了java 推荐的双亲委派模型了吗？答案是：违背了。 我们前面说过：
双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。
很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。
我们扩展出一个问题：如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？
看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。牛逼吧。
总结
好了，终于，我们明白了Tomcat 为何违背双亲委派模型，也知道了tomcat的类加载器是如何设计的。顺便复习了一下 Java 默认的类加载器机制，也知道了如何破坏Java的类加载机制。这一次收获不小哦！！！ 嘿嘿。
类的唯一性、初始类装载器/定义类装载器
对于任意一个类，都需要由加载它的类加载器和类的全限定名一同确定其在Java虚拟机中的唯一性。
概念
A a = (A)Class.forName("pacage.A").newInstance(); 等效于 A a = new A();
Class.forName("XXX.XXX") == Class.forName("XXX.XXX", true, CALLCLASS.class.getClassLoader());
备注：
1. CALLCLASS = Reflection.getCallerClass(); //获取调用方法
2.第二个参数表示是否初始化该类(调用类的静态块的语句及初始化静态成员变量, 不会调用'{}'和构造方法)
3. Class a = Reflection.getCallerClass(0);
0：返回sun.reflect.Reflection
1: 返回当前类的Class对象
2：返回调用该方法的Class对象
结论：如果类A是被一个加载器加载的，那么类A中引用的B也是由这个加载器加载的(如果B还没有被加载的话)，通常情况下就是类B必须在类A的classpath下。
我的理解
- myclassloader 遵循双亲委托
- myclassloader 是初始类装载器 。 new A() 没有初始类装载器这一说。
在需要动态加载类和资源的系统编程时, 往往需要从三种类加载器里选择
1.系统或程序的类加载器. ClassLoader.getSystemClassLoader()
由于系统类加载器是JVM最后创建的类加载器，这样代码只会适应于简单命令行启动的程序。一旦代码移植到EJB、Web应用或者Java Web Start应用程序中，程序肯定不能正确执行。
2.当前类加载器
当前类加载器是指当前方法所在类的加载器。这个类加载器是运行时类解析使用的加载器，Class.forName(String)和Class.getResource(String)也使用该类加载器。代码中X.class的写法使用的类加载器也是这个类加载器。
3.当前线程的上下文类加载器 (ContextClassLoader)
使用场景：基础类需要回调用户的代码，通过线程上下文类加载器可以实现父加载器对子加载器的逆向访问。
对3举例
备注: ServiceLoader默认使用BootStarpClassloader加载。 引用方则使用APPClassLoader来加载。当父类加载器需要加载子类加载器中的资源时候可以通过设置和获取线程上下文类加载器来实现。
参考文章：
1、https://blog.csdn.net/qq_38182963/article/details/78660779
2、https://www.jianshu.com/p/7ffa2320b2f0
标签：类库,Java,tomcat,Tomcat,双亲,jsp,加载 来源： https://blog.csdn.net/yangyangrenren/article/details/121588654
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。