Tomcat的生命周期

前言：
本文是基于Tomcat架构中各个组件及组件间关系的基础上，继续深挖Tomcat中各个组件在“动态”的情况下是如何初始化、开始运行到销毁的流程，如果说上一篇文章是着重于容器的加载和创建，那么这篇文章就力求将这些零散的组件串联起来，各个组件是如何运行流转，相互协作从而保证Tomcat正常运行的
由于在解析的过程中涉及三个经典的设计模式：模板方法、责任链模式和观察者模式，因此读者需要具备这些设计模式大致的概念

Tomcat在入口Bootstrap.main()方法中，首先通过load()方法加载server.xml文件，将配置的所有组件加载到内存中，然后调用start()方法进行组件的初始化和加载

图1. Bootstrap的start方法

图中的catalinaDaemon在上一篇文中分析过，就是Catalina类的实例，所以，实际上该方法通过反射的方式调用了Catalina的start()方法

图2. Catalina类的start方法
我们先来看第二个横线处，其主要的作用是在虚拟机关闭时加了一个“钩子”线程CatalinaShutdownHook，确保Catalina的关闭正常，以及异常时的日志管理。在上一篇中分析过getServer()返回的是一个StandardServer对象的实例，这里调用了他的start()方法，但我们进入该类并没有找到对应的方法，调出继承关系图 图3. StandardServer继承关系图
StandardServer直接继承了抽象父类LifecycleMBeanBase，从而间接继承了LifecycleBase，我们在LifecycleBase中找到了start()方法。这就引出了“模板方法”这个非常好用的设计模式，start()方法就是通用行为，或者称之为算法的骨架，方法内部的步骤中肯定存在一些留给各个子类的具体实现，start()方法的代码清单1

    @Override
    public final synchronized void start() throws LifecycleException {

        //        （1）
        if (LifecycleState.STARTING_PREP.equals(state) || LifecycleState.STARTING.equals(state) ||
                LifecycleState.STARTED.equals(state)) {

            if (log.isDebugEnabled()) {
                Exception e = new LifecycleException();
                log.debug(sm.getString("lifecycleBase.alreadyStarted", toString()), e);
            } else if (log.isInfoEnabled()) {
                log.info(sm.getString("lifecycleBase.alreadyStarted", toString()));
            }

            return;
        }

        if (state.equals(LifecycleState.NEW)) {
            //       （2）
            init();
        } else {
            //       （3）
            if (state.equals(LifecycleState.FAILED)) {
                stop();
            } else if (!state.equals(LifecycleState.INITIALIZED) &&
                    !state.equals(LifecycleState.STOPPED)) {
                invalidTransition(Lifecycle.BEFORE_START_EVENT);
            }
        }

        try {

            setStateInternal(LifecycleState.STARTING_PREP, null, false);

            //         （4）
            startInternal();
            if (state.equals(LifecycleState.FAILED)) {
                // This is a 'controlled' failure. The component put itself into the
                // FAILED state so call stop() to complete the clean-up.
                stop();
            } else if (!state.equals(LifecycleState.STARTING)) {
                // Shouldn't be necessary but acts as a check that sub-classes are
                // doing what they are supposed to.
                invalidTransition(Lifecycle.AFTER_START_EVENT);
            } else {
                setStateInternal(LifecycleState.STARTED, null, false);
            }
        } catch (Throwable t) {
            // This is an 'uncontrolled' failure so put the component into the
            // FAILED state and throw an exception.
            ExceptionUtils.handleThrowable(t);
            setStateInternal(LifecycleState.FAILED, null, false);
            throw new LifecycleException(sm.getString("lifecycleBase.startFail", toString()), t);
        }
    }

注释1处有一个枚举类型LifecycleState，该类中列出了Tomcat容器所有的生命周期状态

图4. LifecycleState中有关容器的生命周期状态字段
大多数的生命周期状态都对应一个Lifecycle的LifecycleEvent事件，在Tomcat中容器状态改变时会将改变的信息封装成事件传递给“观察者”，下面是Tomcat容器的生命周期转换图 图5. Tomcat生命周期转换图
图中设计状态流转的方法有init()、start()、stop()、destory()，本文主要介绍init()和start()之间的转换流程，其他的转换过程类似
再回到代码清单1中的注释2处，当组件的状态是LifecycleState.NEW时，调用了init()进行容器的初始化操作，和图5左上角相互验证 图6. LifecycleBase的init方法
init()方法依然是一个模板，在子类需要具体实现的initInternal()之前将组件的状态设为了LifecycleState.INITIALIZING，之后设置为LifecycleState.INITIALIZED，因为此时实际上是StandardServer的调用流程，所以该流程中initInternal()的具体实现也需要在StandardServer查找，方法中的关键代码片段如下所示 图7. StandardService中initInternal方法关键片段

从上一篇文章分析可知，一个StandardServer容器下包含一个或多个StandardService对象，这里的services[]就是StandardService对象的集合，也就是说Tomcat容器的初始化调用了StandardServer容器进行初始化，而StandardServer也并没有进行初始化，而是交给了他的子容器StandardService进行初始化，调用init()。我们在查看StandardService的类继承关系时发现，StandardService的继承关系和“父容器”StandardServer几乎一样

图8. StandardService继承关系图
既然继承关系一致，那方法之间调用的时序关系也应该大致相同，同样的，init()是在LifecycleBase中的模板方法，而其中initInternal()方法也在StandardService中具体实现 图9. StandardService中initInternal方法

该方法的执行内容可以分为三大块，与之对应的server.xml中<Service>下的内容可以分为三大块

图10. 对应Service标签下的三大块
两图对比可以看出图9中的2标注内容是对图10中标注1<Executor>标签初始化过程，图9中标注3内容对应的是图10中标注2<Connector>初始化过程，剩下的自然就是Container对象对应图10中标注3的一堆标签的初始化。在Tomcat架构中各个组件及组件间关系中曾今说过，server.xml中的标签和java类并不是完全一一对应的关系，这里的Container实际上就是将<Engine>、<Host>等标签对应类的共性抽取的父接口。因此，StandardService类的初始化过程依然是将初始化的过程“下放”给子容器初始化的过程。这就引出了第二个设计模式：责任链设计模式，在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。至此，实际上组件的初始化流程就分析完了，因为后面组件的初始化也会像上面分析的一样“父传子，子传孙”
回到主线代码清单1，注释3实际上是在容器生命周期状态错误的时候关闭容器的过程，注释2才是容器真正的启动过程 图11. StandardServer的startInternal方法
一看红框中的代码就知道又是“套路”，将父组件的启动传递给子组件，这里不再继续分析，重点看看void fireLifecycleEvent(String type, Object data)，第一个参数是与生命周期相关的事件标识，第二个参数是该事件对应的数据。由于Tomcat组件都有自己独立的生命周期，都直接或者间接继承了LifecycleBase类，因此该方法必然在父类中管理 图12. LifecycleBase代码片段

底层又调用了LifecycleSupport的fireLifecycleEvent方法

图13. LifecycleSupport代码片段
从图中可以看到LifecycleSupport中包含了一个实现了LifecycleListener接口的数组，我们可以通过addLifecycleListener(LifecycleListener)方法向数组中添加新的Listener监视器对象。而fireLifecycleEvent(String, Object)方法首先根据传递来的生命周期相关的事件标识type，和相关数据data包装成LifecycleEvent，再遍历所有的LifecycleListener实现类，依次对生命周期事件进行处理，这里的LifecycleListener实现类实际上就是我们在server.xml中配置的<Listener>标签对应的实体类 图14. Listener标签的相关配置
我们回想一下，这里的组件初始化或者开始等操作等价于一个事件或者一个“新闻”，而LifeSupport可以想象成一个报童，所有的Listener相当于一个个订报纸的平民老百姓。如果一个平民想订报纸了，就要去报社交个钱登记一下，相当于调用了上面的addLifecycleListener(LifecycleListener)方法，当有一个新闻发生，比如容器的start，那么报社就写了篇报道发了个版面，然后找到交完钱登记过要买报纸的百姓，让报童挨家挨户的送报纸，正如这里的LifecycleSupport调用fireLifecycleEvent(String, Object)遍历Listener数组再挨个调用一样，但是每一个百姓看到这条新闻会怎么做就和报社或者报童没有关系了，这就是本文涉及到的第三个设计模式：观察者模式
至此，Tomcat的生命周期就剖析完毕，他的生命周期实际上依赖于下面一个个具有“父子”关系组件的生命周期，而组件的生命周期操作通过责任链模式串联起来，在执行生命周期状态转换的具体操作时又使用了模板方法，将状态转换的骨架抽取出来，每个组件各自实现特定的具体步骤，最后整个过程使用了观察者模式传递给“感兴趣”的监视器进行宏观的把控