Tomcat:正统的类加载架构。
通常的Java Web服务器都实现了自己的类加载器(一般不止一个)。
正常的Web服务器要解决如下几个问题:
(1)部署在一个服务器上的两个Web应用程序所使用的Java类库可以实现隔离。
(2)部署在一个服务器上的两个Web应用程序所使用的Java类库可以实现共享。
(3)服务器尽可能的保证自身安全不受部署的Web应用程序影响。
(4)支持JSP的Web服务器,通常都需要支持HotSwap功能。
Tomcat目录结构:
三组目录(/common/*、/server/*、/shared/*)存放Java类库,加上应用程序本身的 目录(/WEB-INF/*),一共四组目录。
(1)common目录:能被Tomcat和所有Web应用程序共享。
(2)server目录:仅能被Tomcat使用,其他Web应用程序不可见。
(3)Shared目录:可以被所有Web应用程序使用,对Tomcat不可见。
(4)WEB-INF目录:尽可以被此Web应用程序使用,对其他不可见。
Tomcat类加载器委派关系:
CommonClassLoader、CatalinaClassLoader、ShareClassLoader、和WebappClassLoader 是 Tomcat自定义加载器,分别对应加载/common/*、/server/*、/shared/*和 /WEB-INF/*类库, 其中Webapp类加载器和Jsp类加载器会存在多个,每个Web 应用对应一个Webapp类加 载器,每个JSP文件对应Jsp类加载器。
Tomcat类加载器分析:
CommonClassLoader加载的类可以被CatalinaClassLoader和ShareClassLoader使 用;CatalinaClassLoader加载的类和ShareClassLoader加载的类相互隔离; WebappClassLoader可以使用ShareClassLoader加载的类,但各个 WebappClassLoader间相互隔离;JspClassLoader仅能用JSP文件编译的class文件。
OSGi:灵活的类加载结构。
OSGi(Open Service Gateway Initiative):是OSGi联盟定制的基于Java语言 的动态模块化规范。
OSGi的模块(Bundle)与普通Java区别:两者区别并不太大,都是以JAR 格式封装,并且内部存储都是Java Package和Class。但是Bundle可以声明依赖 的Java Package,也可以声明它导出发布的Java Package。Bundle从传统上层模块依 赖转变为平级模块依赖。QSGi的Bundle类加载器之间只有规则,没有固定委派关 系。
OSGi类加载器关系:
某个Bundle声明依赖的Package,如果有其他Bundle发布了此Package,则对这个 个package的所有类加载动作会委派它的Bundle了类加载器去完成。
例如:
BundleA:声明发布PackageA,依赖java.*的包;
BundleB:声明依赖PackageA和PackageC,也同时依赖java.*;
BundleC:声明发布PackageC,同时声明依赖PackageA。
则关系图如下:
OSGi类加载器分析:
可以看出,OSGi类加载器之间不再是双亲委派模型的树形结构,而是进一步发展成 为一种运行时才能确定的网状结构。这种网状类加载器结构拥有更优秀的灵活性, 同时也有许多隐患,由于各模块间依赖关系错综复杂,高并发量下容易发生死锁等 问题。