专栏地址https://time.geekbang.org/column/intro/100027701

Tomcat组件生命周期

第一个原则是先创建子组件再创建父组件子组件需要被“注入”到父组件中。

第二个原则是先创建内层组件再创建外层组件内层组建需要被“注入”到外层组件。

最直观的做法就是将图上所有的组件按照先小后大、先内后外的顺序创建出来然后组装在一起。

但这样的方式问题很大一方面组件很多可能会造成遗漏而且代码也会很冗余另一方面不利于后期的功能拓展。

为了解决这个问题我们希望找到一种通用的、统一的方法来管理组件的生命周期LifeCycle

LifeCycle接口

接口里应该定义这么几个方法init()、start()、stop()

init()

调用是由它的父组件的状态变化触发的上层组件的初始化会触发子组件的初始化上层组件的启动会触发子组件的启动因此我们把组件的生命周期定义成一个个状态把状态的转变看作是一个事件。

而事件是有监听器的在监听器里可以实现一些逻辑并且监听器也可以方便的添加和删除这就是典型的观察者模式。

LifeCycle

接口里加入两个方法添加监听器和删除监听器。

除此之外我们还需要定义一个

Enum

NEW、INITIALIZING、INITIALIZED、STARTING_PREP、STARTING、STARTED

NEW

当我们定义好了接口就要去写实现类实现它而在一个接口的不同实现类里可能很多逻辑都是一样的。

那子类如何重用这部分逻辑呢常见的方法就是定义一个基类来实现共同的逻辑然后让各个子类去继承它就达到了重用的目的。

而基类中往往会定义一些抽象方法所谓的抽象方法就是说基类不会去实现这些方法而是调用这些方法来实现骨架逻辑。

抽象方法是留给各个子类去实现的并且子类必须实现否则无法实例化。

LifeCycleBase

Lifecycle接口的基础上定义了如下四个抽象方法交给子类实现并在内部逻辑中调用了该方法

protected

(!state.equals(LifecycleState.NEW))

{invalidTransition(Lifecycle.BEFORE_INIT_EVENT);}try

{//2.

事件的监听器setStateInternal(LifecycleState.INITIALIZING,

null,

调用具体子类的初始化方法initInternal();//4.

INITIALIZED

事件的监听器setStateInternal(LifecycleState.INITIALIZED,

null,

负责触发事件并调用监听器的方法。

那是什么时候、谁把监听器注册进来的呢

Tomcat

自定义了一些监听器这些监听器是父组件在创建子组件的过程中注册到子组件

监听器用来检测

Catalina。

注意Tomcat和Java程序不是一个类加载器

3.Catalina

的启动就算完成了。

这些启动类或者组件不处理具体请求它们的任务主要是“管理”管理下层组件的生命周期并且给下层组件分配任务也就是把请求路由到负责“干活儿”的组件。

2.1

{log.fatal(sm.getString(catalina.noServer));return;}//3.

Servertry

CatalinaShutdownHook();}Runtime.getRuntime().addShutdownHook(shutdownHook);}//

await

LifeCycleBase它的生命周期被统一管理并且它的子组件是

Service因此它还需要管理

{service.setServer(this);synchronized

(servicesLock)

将老的数据复制过去System.arraycopy(services,

results,

services.length);results[services.length]

service;services

触发监听事件support.firePropertyChange(service,

null,

service);}}从上面的代码你能看到它并没有一开始就分配一个很长的数组而是在添加的过程中动态地扩展数组长度当添加一个新的

Service

实例时会创建一个新数组并把原来数组内容复制到新数组这样做的目的其实是为了节省内存空间。

除此之外Server

中读取数据如果读到的数据是停止命令“SHUTDOWN”就退出循环进入

stop

StandardService我们先来看看它的定义以及关键的成员变量。

public

作为“管理”角色的组件最重要的是维护其他组件的生命周期。

此外在启动各种组件时要注意它们的依赖关系也就是说要注意启动的顺序。

我们来看看

Service

触发启动监听器setState(LifecycleState.STARTING);//2.

先启动

{connector.start();}}}}从启动方法可以看到Service

Engine

监听器最后才是启动连接器。

这很好理解因为内层组件启动好了才能对外提供服务才能启动外层的连接器组件。

而

Mapper

在容器组件之后启动。

组件停止的顺序跟启动顺序正好相反的也是基于它们的依赖关系。

2.4

还实现了子容器的“增删改查”甚至连子组件的启动和停止都提供了默认实现比如

ContainerBase

{results.add(startStopExecutor.submit(new

Engine

Valvehost.getPipeline().getFirst().invoke(request,

response);}}这个基础阀实现非常简单就是把请求转发到

Host