简单了解Tomcat与OSGi的类加载器架构
前言：
本次博客主要是对Tomcat与OSGi的类加载器架构，所以就需要对tomcat、OSGi以及类加载机制有所了解
类加载可以在http://www.cnblogs.com/ghoster/p/7594224.html中简单了解
一、Tomcat：正统的类加载架构
1.主流的Java Web服务器，如Tomcat、Jetty、WebLogic、WebSphere等都实现了自己定义的类加载器（一般都不止一个）。因为一个功能健全的web服务器要解决一下几个问题：
1）部署在一个服务器上的两个web应用程序所使用的Java类库可以实现互相隔离。这是最基本的需求，两个不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求一个类库在一个服务器中只有一份，服务器应当保证两个应用程序的类库可以互相独立使用
2）部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享。这个需求也非常很常见，如，用户可能有10各使用Spring组织的应用程序部署在同一台服务器上，如果把10份Spring分别存放在各个应用程序的隔离目录中，将会是很大的资源浪费-这主要不是浪费磁盘空间的问题，而是指类库在使用时都要被加载到服务器内存，如果类库不能共享，虚拟机的方法区就会很容易出现过度膨胀的风险
3）服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。目前，有许多主流的Java Web服务器自身也是使用Java语言来实现的。因此，服务器本身也有类库依赖的问题，一般来说，基于安全考虑，服务器所使用的类库应该与应用程序的类库相互独立
4）支持jsp应用的Web服务器，大多数都需要支持HotSwap功能。我们知道，jsp文件最终要编译成Java Class才能由虚拟机执行，但jsp文件由于其纯文本存储的特性，运行时修改的概率远远大于第三方类库或程序自身的Class文件。而且ASP、PHP和JSP这些网页应用也把修改后无需重启作为一个很大的“优势”来看待，因此，“主流”的Web服务器都会支持JSP的热替换，当然也有“非主流”的，如运行在生产模式下的WebLogic服务器默认就不会处理JSP文件的变化
由于存在上述问题，在部署Web应用时，单独的一个ClassPath就无法满足需求了，所以各种Web服务器都“不约而同”地提供了好几个ClassPath路径供用户存放第三方类库，这些路径一般都以lib或classes命名，被放置到不同路径中的类库，具备不同的访问范围和服务对象，通常，每一个目录都会有一个相应的自定义类加载器去加载放置在里面的Java类库。
2.Tomcat对用户类库与类加载器的规划
在其目录结构下有三组目录（“/common/*”、“/server/*”、“/shared/*”）可以存放Java类库,另外还可以加上Web应用程序本身的目录“/WEB-INF/*”，一共4组，把Java类库放置在这些目录中的含义分别如下：
1）放置在/commom目录中：类库可被Tomcat和所有的Web应用程序共同使用
2）放置在/server目录中：类库可被Tomcat使用，对所有的Web应用程序都不可见
3）放置在/shared目录中：类库可被所有的Web应用程序所共同使用，但对Tomcat自己不可见
4）放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见
为了支持这套目录结构，并对目录里面的类库进行加载和隔离，Tomcat自定义了多个类加载器，这些类加载器按照经典的双亲委派模型来实现，所下图：
最上面的三个类加载器是JDK默认提供的类加载器，这三个加载器的的作用之前也说过，这里不再赘述了，可以在http://www.cnblogs.com/ghoster/p/7594224.html简单了解。而CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebAppClassLoader则是Tomcat自己定义的类加载器，他们分别加载/common/*、/server/*、/shared/*和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个jsp文件对应一个Jsp类加载器
从上图的委派关系可以看出，CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的哪一个Class，它出现的目的就是为了被丢弃：当服务器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过在建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能
二、OSGi：灵活的类加载器架构
既然说到OSGI，就要来解释一下OSGi是什么，以及它的作用
OSGi（Open Service Gateway Initiative）：是OSGi联盟指定的一个基于Java语言的动态模块化规范，这个规范最初是由Sun、IBM、爱立信等公司联合发起，目的是使服务提供商通过住宅网管为各种家用智能设备提供各种服务，后来这个规范在Java的其他技术领域也有不错的发展，现在已经成为Java世界中的“事实上”的模块化标准，并且已经有了Equinox、Felix等成熟的实现。OSGi在Java程序员中最著名的应用案例就是Eclipse IDE
OSGi中的每一个模块（称为Bundle）与普通的Java类库区别并不大，两者一般都以JAR格式进行封装，并且内部存储的都是Java Package和Class。但是一个Bundle可以声明它所依赖的Java Package（通过Import-Package描述），也可以声明他允许导出发布的Java Package（通过Export-Package描述）。在OSGi里面，Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖（至少外观上如此），而且类库的可见性能得到精确的控制，一个模块里只有被Export过的Package才可能由外界访问，其他的Package和Class将会隐藏起来。除了更精确的模块划分和可见性控制外，引入OSGi的另外一个重要理由是，基于OSGi的程序很可能可以实现模块级的热插拔功能，当程序升级更新或调试除错时，可以只停用、重新安装然后启动程序的其中一部分，这对企业级程序开发来说是一个非常有诱惑性的特性
OSGi之所以能有上述“诱人”的特点，要归功于它灵活的类加载器架构。OSGi的Bundle类加载器之间只有规则，没有固定的委派关系。例如，某个Bundle声明了一个它依赖的Package，如果有其他的Bundle声明发布了这个Package，那么所有对这个Package的类加载动作都会为派给发布他的Bundle类加载器去完成。不涉及某个具体的Package时，各个Bundle加载器是平级关系，只有具体使用某个Package和Class的时候，才会根据Package导入导出定义来构造Bundle间的委派和依赖
另外，一个Bundle类加载器为其他Bundle提供服务时，会根据Export-Package列表严格控制访问范围。如果一个类存在于Bundle的类库中但是没有被Export，那么这个Bundle的类加载器能找到这个类，但不会提供给其他Bundle使用，而且OSGi平台也不会把其他Bundle的类加载请求分配给这个Bundle来处理
一个例子：假设存在BundleA、BundleB、BundleC三个模块，并且这三个Bundle定义的依赖关系如下：
BundleA：声明发布了packageA，依赖了java.*的包
BundleB：声明依赖了packageA和packageC，同时也依赖了Java.*的包
BundleC：声明发布了packageC，依赖了packageA
那么，这三个Bundle之间的类加载器及父类加载器之间的关系如下图：
由于没有涉及到具体的OSGi实现，所以上图中的类加载器没有指明具体的加载器实现，只是一个体现了加载器之间关系的概念模型，并且只是体现了OSGi中最简单的加载器委派关系。一般来说，在OSGi中，加载一个类可能发生的查找行为和委派关系会比上图中显示的复杂，类加载时的查找规则如下：
1）以java.*开头的类，委派给父类加载器加载
2）否则，委派列表名单内的类，委派给父类加载器加载
3）否则，Import列表中的类，委派给Export这个类的Bundle的类加载器加载
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载
5）否则，查找是否在自己的Fragment Bundle中，如果是，则委派给Fragment bundle的类加载器加载
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载
7）否则，查找失败
从之前的图可以看出，在OSGi里面，加载器的关系不再是双亲委派模型的树形架构，而是已经进一步发展成了一种更复杂的、运行时才能确定的网状结构。
