1.Tomcat:正统的类加载器架构
一个功能健全的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生成类的热替换,当然也有"非主
流"的,如运行在生产模式(Production Mode)下的WebLogic服务器默认就不会处理JSP文件的变
化.
在Tomcat目录结构中,有三组目录("/common/*","/server/*"和"/shared/*")可以存放
Java类库,另外还可以加上Web应用程序自身的目录"/WEB-INF/*",一共四组,把Java类库放置在
这些目录中的含义分别是:
放置在/common目录中:类库可被Tomcat和所有的Web应用程序共同使用.
放置在/server目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见.
放置在/shared目录中:类库可被所有的Web应用程序共同使用,但对Tomcat自己不可见.
放置在/WebApp/WEB-INF目录中:类库仅仅可以被此Web应用程序使用,对Tomcat和其他Web
应用程序都不可见.
为了支持这套目录结构,并对目录里面的类库进行加载和隔离,Tomcat自定义了多个类加载器,
这些类加载器按照经典的双亲委派模型来实现,如下图所示.
对于Tomcat的6.X版本,只有指定了tomcat/conf/catalina.properties配置文件的
server.loader和share.loader项后才会真正建立CatalinaClassLoader和
SharedClassLoader的实例,否则会用到这两个类加载器的地方都会用CommonClassLoader的实
例来代替,而默认的配置文件中没有设置这两个loader项,所以Tomcat 6.X顺理成章地把/common,
/server和/shared三个目录默认合并到一起编程一个/lib目录,这个目录里的类库相当于以前
/common目录中类库的作用.
2.OSGi:灵活的类加载器架构
对于单个虚拟机下的应用,从开发初期就建立在OSGi上是一个很不错的选择,这样便于约束依赖.
但并非所有的应用都适合采用OSGi作为基础架构,OSGi在提供强大功能的同时,也引入了额外的复杂
度,带来了线程死锁和内存泄漏的风险.
3.字节码生成技术与动态代理的实现
略