Java虚拟机--类加载器分析

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类加载器之间不再是双亲委派模型的树形结构，而是进一步发展成 为一种运行时才能确定的网状结构。这种网状类加载器结构拥有更优秀的灵活性， 同时也有许多隐患，由于各模块间依赖关系错综复杂，高并发量下容易发生死锁等 问题。