Tomcat源代码学习(二)----设计模式

Tomcat中的pipeline机制:(责任链模式)

      责任链模式是一种对象的行为模式。在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。所以责任链模式将请求的发送者和请求的处理者解耦了。

      由图1可知,tomcat先建立好连接再与容器Catalina进行交互。tomcat利用Coyote封装了底层的网络通讯,为Catalina容器提供统一的接口,使得Catalina容器和具体的请求协议及I/O方式解耦。

在这里插入图片描述

图1 Coyote内部结构

      通过上图可以得知,connector与container的连接是通过内部的Adapter。具体的请求流和响应流在代码实现中便是通过CoyoteAdapter进入Containter的。

在这里插入图片描述

图2 入口的具体源码

      在tomcat的pipeline机制中使用了责任链模式,其中,Container 扮演抽象处理者角色,具体处理者由 StandardEngine 等子容器扮演。与标准的责任链不同的是,这里引入了 Pipeline 和 Valve 接口。

      Pipeline 和 Valve 是扩展了这个链的功能,使得在责任链在往下传递过程中,能够接受外界的干预。在Catalina中,有4种容器(Engine、Host、Context、Wrapper),每个容器都有自己的Pipeline组件,每个Pipeline组件上至少会设定一个Valve(阀门),这个Valve我们称之为BaseValve(基础阀)。基础阀的作用是连接当前容器的下一个容器,可以说基础阀是两个容器之间的桥梁。

      请求request和响应response在Tomcat的容器中的传递,如下图:

在这里插入图片描述

图3 request和response在容器内的传递

      以四大组件中的Engine为例,对tomcat中管道机制进行分析。

1)使用默认的基本阀创建一个新的标准引擎组件:
      StandardEngine的构造方法调用pipeline主键创建基础阀。

在这里插入图片描述

图4 创建基础阀

2)普通阀与基础阀
      基础阀的作用是指引流进入下一条管道,普通的阀只是指向同一条管道的下一个阀门。

在这里插入图片描述

图5 基础阀(Host为Engine的下一层组件)

在这里插入图片描述

图6 普通阀

      大体的过程就是:Connector将流request和response传入catalina中,首先接触的到的Engine层,流进入pipeline中,流经pipeline的各阀门,阀门对流进行相应的处理,然后传递给同一管道中的下一个阀门,直到传至基础阀,基础阀再将其传递给下一层的管道。

在这里插入图片描述

图7 责任链类图(以Engine拓展为例)

在这里插入图片描述

图8 pipeline上的阀门

Request的外观模式:

      外观模式为整个子系统提供一种高层次的简单借口。

      这种设计模式主要用在一个大的系统中有多个子系统组成时,这多个子系统肯定要涉及到相互通信,但是每个子系统又不能将自己的内部数据过多的暴露给其它系统,不然就没有必要划分子系统了。每个子系统都会设计一个门面,把别的系统感兴趣的数据封装起来,通过这个门面来进行访问。这就是门面设计模式存在的意义。

在这里插入图片描述

图9 外观模式

      RequestFacade内部包含 Request 对象,对于Request对象的访问通过RequestFacade进行。tomcat中使用外观模式主要是为了保证主要类的安全,防止程序员使用核心类的暴露功能。

观察者模式:

      观察者模式常用的设计方法叫发布-订阅模式,也就是事件监听机制,通常在某个事件发生的前后会触发一些操作。定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。主要解决一个对象状态改变给其他对象通知的问题,而且要考虑到易用和低耦合,保证高度的协作。

Tomcat中需要对很多组件进行生命周期管理,为此Tomcat抽象了统一的生命周期管理骨架,通过这个骨架将所有需要进行生命周期管理的类都纳入进来管理。其类图如下:

在这里插入图片描述

图10 观察者模式类图

在这里插入图片描述

图11 具体的观察者

在这里插入图片描述

图12 时序图

单例模式:(异常消息的管理)

      单例模式是对象的创建模式,确保一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。

      tomcat中有一套完善的异常信息管理机制,在每个需要异常管理的工程包下都有相应的 properties 文件,文件中主要定义了各自pacakage下的类的各种异常信息,极大的方便了对异常信息的维护,而且利用java的ResourceBundle类,可以方便的实现国际化。然而,tomcat的核心包就有几百个类,如果将这些类要用到的异常消息存入一个properties文件,在维护上会十分困难。

      Tomcat的做法是一个包共用一个properties文件。当包中的某个类需要用到异常消息时,可以先实例化StringManager,然后调用getString(String key)方法。如果每个类都实例化一个StringManager对象,而这些对象所包含的异常消息都是相同的,同样也会带来资源上的浪费。若每个包中的类,都共用一个StringManager对象,则会大大的提高效率。因此,to-mcat使用了单例模式对其进行管理。

在这里插入图片描述

图13 以SingleSingnon调用StringManger为例

在这里插入图片描述

图14 StringManger类图

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章