Tomcat类加载器架构篇

1.主流的web服务器都实现自己的类加载器,因为一个功能完整的web服务器要解决以下4个问题:
①部署在同一个服务器上的web应用使用的java类库可以实现相互隔离.例如,不同的web应用使用了同一个第三方类库的不同版本,不能要求在一个服务器中只能使用一个版本的第三方类库,必须能够实现同一类库不同版本能够在web程序中独立使用.
②部署在同一个服务器上的不同web应用直接可以共享某些类库.例如,10个使用spring架构的web应用,我们不能使用10套类库.这不是浪费空间的问题,而是所有类库都需要加载到服务器内存中才能使用,如果不能共享,就容易出现过度膨胀的风险.
③服务器需要尽可能保证自身的安全不受部署应用的影响.基于安全考虑,服务器使用的类库应该和应用所使用的类库相互独立.
④支持JSP应用的web服务器,大多数都需要支持热部署(HotSwap-热替换)能力.
由于存在以上问题,在部署web应用时,一个classpath就无法满足要求了.因此各种web服务器都不约而同的提供了多个classpath路径供存放第三方类库,这些路径一般都以"lib"或"classes"命名.被放置到不同路径的类库,具备不同的访问范围和服务对象.
通常,每一个目录都有一个相应的类加载器去加载里面放置的java类库.

2.Tomcat服务器目录结构
2.1 在Tomcat5.x的目录结构中,有三组目录结构:/common/*,/server/*,/shared/*可以存放java类库,另外加上web
应用的目录/WEB-INF/*,一共4组,这些目录的含义如下:
①/common/*:类库可以被Tomcat和所有web应用共同使用.
②/server/*:类库只能被Tomcat服务器使用,对web应用透明.
③/shared/*:类库能被所有web应用共享,但是对tomcat透明.
④/WEB-INF/*:类库可以被本应用使用,对其他应用和Tomcat透明.

2.2 在Tomcat6.x版本中,/common/,/server/,/shared/目录已经合并成一个/lib目录.

3.Tomcat的类加载器结构
3.1 Tomcat5.x中,为了支持以上目录结构,并对目录中的类库进行加载和隔离,Tomcat自定义了多个类加载器,这些加载器使用双亲委派模型来实现.
类加载器结构:
见附件
各个类加载器的作用(Tomcat自定义的类加载器):
①Common类加载器:加载/common/*下的类库,CommonClassLoader加载器加载到类可以被Catalina类加载器和Shared类加载器使用,而他们各自加载到的类则不能被对方使用.
②Catalina类加载器:加载/server/*下的类库
③Shared类加载器:加载/shared/*下的类库
④WebApp类加载器:加载web应用下/WEB-INF下的类库,它可以使SharedClassLoader加载到的类.
⑤Jsp加载器:加载范围仅仅是当前jsp页面编译后的class,它的目的就是为了丢弃:当服务器检测到jsp页面发生变化时, 会替换掉当前的JasperLoader,然后新创建一个JasperLoader实例,实现HotSwap能力.

 
3.2 在Tomcat6.x中,只有在tomcat/conf/catalina.conf配置了server.loader和share.loader才会去创建CatalinaClassLoader和SharedClassLoader实例.否则,使用到这两类加载器的地方都用CommonClassLoader代替.
在默认配置文件中是没有设置这两项的./lib中的类库相当于5.x版本中/common目录中类库的作用.如果默认设置不能满足要求,可以配置以上两项,使用5.x的类加载器架构.