目录
结论:
- Tomcat的类加载机制违反了双亲委派机制。
- 对于一些未加载的非基础类(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载,加载不到时再交给commonClassLoader走双亲委托。
- 因此,按照这个过程可以想到,如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class,会优先加载CLASSPATH目录中的文件。
问题:
1、既然 Tomcat 不遵循双亲委派机制,那么如果我自己定义一个恶意的HashMap,会不会有风险呢?
- 没有风险。
- tomcat不遵循双亲委派机制,只是自定义的classLoader顺序不同
- 但顶层还是相同的,还是要去顶层请求classloader。
2、Tomcat是个web容器, 那么它要解决什么问题?
- 1)一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。
- 2)部署在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机。
- 3)web容器也有自己依赖的类库,不能于应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。
- 4)web容器要支持jsp的修改,jsp 文件最终也是要编译成class文件才能在虚拟机中运行,但程序运行后修改jsp已经是司空见惯的事情,否则要你何用? 所以,web容器需要支持 jsp 修改后不用重启。
3、Tomcat 如果使用默认的类加载机制行不行?
- 不行。
- 看2中第一个问题:如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的类加载器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。
- 第二个问题:默认的类加载器是能够实现共享的,因为他的职责就是保证唯一性。
- 第三个问题同第一个问题。
- 第四个问题,我们想我们要怎么实现jsp文件的HotSwap,jsp 文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。
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 违背了java 推荐的双亲委派模型了吗?
- 违背了。
- 双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当由自己的父类加载器加载。
- 显然,tomcat 不是这样实现,tomcat 为了实现隔离性,没有遵守这个约定,每个webappClassLoader加载自己的目录下的class文件,不会传递给父类加载器。
- 如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类,该怎么办?可以使用线程上下文类加载器实现,使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。
类加载
- 在JVM中并不是一次性把所有的文件都加载到,而是一步一步的,按照需要来加载。
- 比如JVM启动时,会通过不同的类加载器加载不同的类。
- 当用户在自己的代码中,需要某些额外的类时,再通过加载机制加载到JVM中,并且存放一段时间,便于频繁使用。
JVM类加载
JVM类加载采用 双亲委派机制,如下图所示:
JVM中包括几种类加载器:BootStrapClassLoader 引导类加载器 、ExtClassLoader 扩展类加载器、 AppClassLoader 应用类加载器、 CustomClassLoader 用户自定义类加载器。他们的区别上面也都有说明。需要注意的是,不同的类加载器加载的类是不同的,因此如果用户使用加载器1加载的某个类,其他用户并不能够使用。
当JVM运行过程中,用户需要加载某些类时,会按照下面的步骤(父类委托机制):
- 用户自己的类加载器,把加载请求传给父加载器,父加载器再传给其父加载器,一直到加载器树的顶层。
- 最顶层的类加载器首先针对其特定的位置加载,如果加载不到就转交给子类。
- 如果一直到底层的类加载都没有加载到,那么就会抛出异常ClassNotFoundException。
因此,按照这个过程可以想到,如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class,会优先加载CLASSPATH目录中的文件。
Tomcat类加载
在tomcat中类的加载稍有不同,如下图:
当tomcat启动时,会创建几种类加载器:
- Bootstrap 引导类加载器:加载JVM启动所需的类,以及标准扩展类(位于jre/lib/ext下)
- System 系统类加载器:加载tomcat启动的类,比如bootstrap.jar,通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下。
- Common 通用类加载器:加载tomcat使用以及应用通用的一些类,位于CATALINA_HOME/lib下,比如servlet-api.jar
- 4 webapp 应用类加载器:每个应用在部署后,都会创建一个唯一的类加载器。该类加载器会加载位于 WEB-INF/lib下的jar文件中的class 和 WEB-INF/classes下的class文件。
当应用需要到某个类时,则会按照下面的顺序进行类加载:
- 1)使用bootstrap引导类加载器加载
- 2)使用system系统类加载器加载
- 3)使用应用类加载器在WEB-INF/classes中加载
- 4)使用应用类加载器在WEB-INF/lib中加载
- 5)使用common类加载器在CATALINA_HOME/lib中加载