Tomcat笔记：Tomcat的执行流程解析

Bootstrap的启动

Bootstrap的main方法先new了一个自己的对象（Bootstrap），然后用该对象主要执行了四个方法：

init();

setAwait(true);

load(args);

start();

init()：初始化了ClassLoader（类加载器，没它的话后面就没法加载其他类了），然后用ClassLoader创建了Catlina实例。

setAwait(true)，load(args)，start();这三个方法实际上都是通过反射调用的Catlina实例中所对应的这三个方法。

Catlina的启动

首先Catlina中的setAwait(true)方法：

这个方法设置的值（true或false），是留给后面用的。当通过后面的start()方法启动完服务器后，会检查这个值为true还是false，如果为true，调用Catlina的await()方法，tomcat继续开着。如果为false，则调用Catlina的stop()方法，关闭tomcat。

然后是Catlina中的load(args)方法：

Catalina将利用Digest解析server.xml（server的配置文件，server是最顶层容器），并根据server的配置文件创建server实例。

然后调用server实例的init()方法，进行server的初始化。

Server初始化时，又会调用其内部的Service的init方法（server只有一个，但service有多个）。

大体流程如下图：

 

然后是Catlina中的start()方法：

Catlina的start()方法主要调用了server的start()方法来启动服务器，然后server的start()方法再调用多个service的start()方法。

大体流程如下图：

Server的启动

由上面Catlina的启动我们知道了，

Catlina中的load(args)方法使得Server进行了初始化，

Catlina中的start()方法使得Server也调用了start方法。

Server是一个接口，它的默认实现类是StandardServer，所以上面和之后我们操作的Server实际上是操作的StandardServer。

StandardServer继承自LifecycleMBeanBase，而LifecycleMBeanBase又继承自LifecycelBean。

根据之前的分析我们知道，StandardServer主要要调用两个方法：init()和start()。

而这两个方法都不在StandardServer中，实际上都在StandardServer的父类LifecycelBean中。而LifecycelBean中的这两个方法，实际上由“回头”调用了StandardServer中的initInternal()和startInternal()方法。

也就是StandardServer调用了init()实际上是调用了自己的initInternal()方法。

StandardServer调用了start()实际上是调用了自己的startInternal()方法。

initInternal()方法和startInternal()方法“分别循环调用了每一个service的init()方法和start()方法”。

除以上方法外，Standard还有addService()方法用来添加service，和remove()方法用来删除service。

另外Standard还拥有await()方法，用法在上面Catlina的启动中讲了。

Service的启动

一个Serve中可以有多个service，Service也是接口，Service接口的默认实现类是StandardService，所以上面和后面讨论的service实际上是在操作StandardService。

StandardService也继承于LifecycleMBeanBase，而LifecycleMBeanBase继承于LifecycelBean，LifecycelBean中存在init()和start()方法。

所以Server循环调用每个StandardService的init()和start()方法，其实是调用的StandardService的父类LifecycelBean中的init()和start()方法，然后init()和start()方法在“回头调用”StandardService中的initInternal()方法和startInternal()方法

也就是说Server循环调用每个StandardService的init()和start()方法，最后执行的是每个Service的initInternal()方法和startInternal()方法。

每一个service都是一个对外提供服务的组件，每一个Service中都包含：一个Container+多个Connector，所以service中的方法，都是用来操作这两种类的。

initInternal()方法：

下面是initInternal源码：

protected void initInternal() throws LifecycleException {
    super.initInternal();
    if(this.container != null) {
        this.container.init();
    }

    Executor[] arr$ = this.findExecutors();
    int arr$1 = arr$.length;

    int len$;
    for(len$ = 0; len$ < arr$1; ++len$) {
        Executor i$ = arr$[len$];
        if(i$ instanceof JmxEnabled) {
            ((JmxEnabled)i$).setDomain(this.getDomain());
        }

        i$.init();
    }

    this.mapperListener.init();
    Object var11 = this.connectorsLock;
    synchronized(this.connectorsLock) {
        Connector[] var12 = this.connectors;
        len$ = var12.length;

        for(int var13 = 0; var13 < len$; ++var13) {
            Connector connector = var12[var13];

            try {
                connector.init();
            } catch (Exception var9) {
                String message = sm.getString("standardService.connector.initFailed", new Object[]{connector});
                log.error(message, var9);
                if(Boolean.getBoolean("org.apache.catalina.startup.EXIT_ON_INIT_FAILURE")) {
                    throw new LifecycleException(message);
                }
            }
        }

    }
}

首先，调用Container的init()方法，

再调用mapperListener的init()方法（mapperListener是用来监听container的变化的）,

再调用“多个”excutor的init()方法（excutor是用来在connector中管理线程池的），

再调用Connctor的init()方法。

startInternal()方法：

与上同理，也是分别调用四种类的start()方法。

总结一下，Server和Service的关系大致如下图（需要说明的是，下图中每个类或接口中所包含的方法我并没有全写出来，只写了与流程相关的几个）：

Lifecycle接口

将到这里应该提一下Lifecycle接口，该接口的默认实现就是LifecycleBean类。

通过上面提到Server和Service子类我们发现他们都继承了LifecycleBean类，并调用了该类的init()和start()方法。

实际上凡是拥有“生命周期”的组件都实现了Lifecycle接口，Lifecycle接口的作用就是进行“生命周期的规定”。

该接口主要做了以下四件事：

一、定义了13个String常量，这些常量被用于定义“LifecycleEvent事件”的type属性中 。这样设计的好处是，只需要发送一种类型事件LifecycleEvent，而根据里面type属性的值的不同，来判定是什么事件。（否则13种事件就得定义13中事件类）。

二、定义了三个管理监听的方法，分别用来添加、查找、删除LifecycleListener类型的监听器。

三、定义了四个生命周期方法：init()、start()、stop()、destroy()，用于执行生命周期各个阶段的操作。

四、定义了用来获取当前状态的两个方法。

LifecycleBase实现类

lifecycleBase是Lifecycle接口的默认实现类，所有拥有生命周期的组件都直接或间接的继承自lifecycleBase类，lifecycleBase为lifecycle接口中的各个方法提供了默认实现。

三个管理监听的方法：

这三个方法分别是addLifecycleListener（添加监听器）、findLifecycleListeners（查找监听器）、removeLifecycleListener（删除监听器）。

监听器的管理专门使用了一个“LifecycleSupport类”来完成。

这三个方法都调用了LifecycleSupport中的同名方法。

LifecycleSupport中通过一个数组来保存现有个监听器。

另外LifecycleSupport中还定义了处理LifecycleEvent时间的方法。

四个生命周期方法：

主要就是init()和start()方法，在调用方法之前会先判断当前状态与要调用的方法是否匹配，如果不匹配则会执行相应的方法使其匹配（如在低啊用init之前先调用了start，这是就会先执行init）。

之后会调用相应的模板方法（initInternal()和startInternal()）让子类具体执行init和start。

我们先看一下init()方法的源码：

public final synchronized void init() throws LifecycleException {
    if(!this.state.equals(LifecycleState.NEW)) {
        this.invalidTransition("before_init");
    }

    this.setStateInternal(LifecycleState.INITIALIZING, (Object)null, false);

    try {
        this.initInternal();
    } catch (Throwable var2) {
        ExceptionUtils.handleThrowable(var2);
        this.setStateInternal(LifecycleState.FAILED, (Object)null, false);
        throw new LifecycleException(sm.getString("lifecycleBase.initFail", new Object[]{this.toString()}), var2);
    }

    this.setStateInternal(LifecycleState.INITIALIZED, (Object)null, false);
}

可以看出，init()方法先将当前状态设置成了INITIALIZING，然后执行的是具体实现类的initInternal()方法。

再看看start()的源码：

public final synchronized void start() throws LifecycleException {
    if(!LifecycleState.STARTING_PREP.equals(this.state) && !LifecycleState.STARTING.equals(this.state) && !LifecycleState.STARTED.equals(this.state)) {
        if(this.state.equals(LifecycleState.NEW)) {
            this.init();
        } else if(this.state.equals(LifecycleState.FAILED)) {
            this.stop();
        } else if(!this.state.equals(LifecycleState.INITIALIZED) && !this.state.equals(LifecycleState.STOPPED)) {
            this.invalidTransition("before_start");
        }

        this.setStateInternal(LifecycleState.STARTING_PREP, (Object)null, false);

        try {
            this.startInternal();
        } catch (Throwable var2) {
            ExceptionUtils.handleThrowable(var2);
            this.setStateInternal(LifecycleState.FAILED, (Object)null, false);
            throw new LifecycleException(sm.getString("lifecycleBase.startFail", new Object[]{this.toString()}), var2);
        }

        if(this.state.equals(LifecycleState.FAILED)) {
            this.stop();
        } else if(!this.state.equals(LifecycleState.STARTING)) {
            this.invalidTransition("after_start");
        } else {
            this.setStateInternal(LifecycleState.STARTED, (Object)null, false);
        }

    } else {
        if(log.isDebugEnabled()) {
            LifecycleException t = new LifecycleException();
            log.debug(sm.getString("lifecycleBase.alreadyStarted", new Object[]{this.toString()}), t);
        } else if(log.isInfoEnabled()) {
            log.info(sm.getString("lifecycleBase.alreadyStarted", new Object[]{this.toString()}));
        }

    }
}

由此可看到start方法判断了当前状态，如果状态正确执行的起始是子类的startInternal()方法

两个获取当前状态的方法：

在生命周期的相应方法中已经设置了state属性，这两个方法就是返回该属性。

Connector

Connector的主要任务是负责处理浏览器发送过来的请求，并创建一个Request和Response的对象用于和浏览器交换数据，然后产生一个线程用于处理请求，Connector会把Request和Response对象传递给该线程，该线程的具体的处理过程是Container容器的事了。Container就是Servlet的容器，Container处理完后会吧结果返回给Connector，最后Connector使用socket将处理结果返回给客户端，整个请求处理完毕。

Connector的底层是使用socket进行连接，Request和Response时按照http协议（协议可选）来封装，所以Connector同时实现了TCP/IP和HTTP协议。

很明显Connector应该可以有多个，因为一次请求对应一个Connector，统一时间可能有多个请求。

Connector可以处理不同协议类型的请求，默认处理的是HTTP1.1协议。

Connector中使用ProtocolHandler来具体处理请求，不同的ProtocolHandler代表不同协议的请求类型。

ProtocolHandler中又包含三个重要的组件：

Endpoint，用于处理底层socket网络连接。

Processor，用于将socket接收到的socket封装成request。

Adapter，用于将requst交给Container进行处理。

具体执行顺序如下

一、之前讲过了，Catlina会调用load方法，根据server.xml配置文件创建Server对象，之后Server由调用init()创建service，service再调用Connector的init方法创建并初始化。

所以Connector是在Catlina会调用load方法时创建的。

二、Conntctor首先执行的是初始化init，Conntctor的初始化主要是用来初始化ProtocolHandler。

所以Conntctor执行init后：

1、先创建一个Adapter，并设置到ProtocolHandler中（这个Adapter后面要用，也就是上面所提到的用于将requst交给Container进行处理。）

2、调用ProtocolHandler的init方法，让它进行初始化。

3、调用mapperListener的init方法初始化（mapperListener作用是用来监听容器，容器发生变化会被通知）

三、刚刚上面提到了ProtocolHandler的init方法被调用了，我们在看看ProtocolHandler初始化都做了什么。

整个ProtocolHandler结构如下图：

ProtocolHandler的初始化方法被实现于“AbstractProtocol抽象类”中。

该抽象类有两种子抽象类：AbstractAjpProtocol和AbstractHttp11Protocol，分别对应了两种不同的请求协议。

所以最终我们初始化的步骤其实是在AbstractHttp11Protocol抽象类中执行（当协议为HTTP时）。

配置文件server.xml中可以指明需要创建的ProtocolHandler类型，默认是处理HTTP1.1协议的ProtocolHandler，之后我们真正创建的就是AbstractHttp11Protocol抽象类的某一个子类（如Http11NioProtocol）

AbstractHttp11Protocol抽象类的初始化主要是调用了Endpoint的init初始化。

四、endpoint的init方法在抽象父类AbstractEndpoint中，是个模板方法，实际上调用的是子类NioEndpoint里面的bind()方法。

这里的bind()方法主要作用是，检查Acceptor和poller的线程数量是否正确（必须大于等于1）。

提一下Acceptor和poller这两个类，Acceptor的作用是控制与tomcat建立连接的数量，但Acceptor只负责建立连接。socket内容的读写是通过Poller来实现的。

此时Connector的init初始化就完成了。

五、Connector的init方法执行完后，会被调用执行startInternal方法。

同理，此方法会调用protocolHandler.start()方法。

然后protocolHandler的start又会调用endpoint.start()方法。

endpoint的start方法在抽象父类AbstractEndpoint中，是个模板方法，实际上调用的是子类NioEndpoint里面的startInternal()方法。

该方法主要做了：

1、初始化一些属性

2、根据之前定义的Acceptor和poller的线程数量，来启动相应数量的Acceptor和poller。

其中poller会将请求交给SocketProcessor，而SocketProcessor的职责就是把具体的请求处理过程委派给Handler，handler会执行Processor接口里的process()方法，进行“对request的解析，包括请求头、请求行和请求体”。

而这个process()方法是在抽象父类AbstractHttp11Processor里实现的，

process()方法会先从socket里读取http请求数据，并解析请求头，构造Request对象和Response对象。

六、process()方法最后会调用Adapter的service()方法。

Adapter接口只有一个实现类CoyoteAdapter。

service()完成“请求行和请求体的解析”，并把解析出来的信息封装到Request对象和Response对象中，之后service()便将封装了Request以及Response对象的Socket传给Container容器了。

传输的代码是：

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

即：先从Connector中获取service，然后从service中获取Container。接着再获取管道，再获取管道的第一个值Value，最后调用invoke()方法执行请求。

七、调用mapperListener的start方法。，该方法注册了已初始化的组件（在上面讲的Connector的init时初始化的mapperListener），然后为这些组件添加监听器，最后添加容器之间的映射关系。

此时Connector的startIntenal就完成了。

至此整个Connector启动完毕，大致的流程图如下（需要说明的是，下图中每个类或接口中所包含的方法我并没有全写出来，只写了与流程相关的几个，并且多处地方的子类选择不是唯一的，我画的该流程是基于获取HTTP1.1协议的请求）：

Container

Container容器是子容器的父接口，所有的子容器都继承该接口。

Container容器还继承Lifecycle接口，这样就拥有了完整的生命周期，他的子容器也就拥有了完整的生命周期。

Container接口的实现子类为ContainerBase，

其下的四个子容器接口为：Engine、Host、Context、Wrapper。他们之间是逐层包含的，每个service只能有一个Engine，一个Engine能够含有多个Host，每个Host可以含有多个Context，每个Context能够含有多个Wrapper。

四个子容器接口也有各自的子实现类，这些实现类继承自ContainerBase。

4中子容器的作用：

1、Engine：接收Connector传来的request和response，选择可用的Host来处理当前请求管理Host）。

2、Host：代表一个虚拟主机，也是一个站点。外面以www.demo.com/test这个url为例，www.demo.com这个域名就代表一个Host，该域名对应的就是webapps目录所代表的站点。

3、Context：代表一个应用，还是以www.demo.com/test这个url为例，通过域名可以直接访问到ROOT根目录里面的应用就是主应用。webapps/test目录可以通过www.demo.com/test访问到，这个test就又是一个子应用。于是这就是两个Context（每一个应用对应一个Context）。

所以www.demo.com下的应用都属于该Host站点。而其他的域名又是其他Host站点。

4、Wrapper：每一个Wrapper封装一个servlet。

这里需要特殊说明的是Container的四个子容器的生命周期：

1、虽然四个子容器的共同父类ContainerBase定义了initInternal()和startInternal()方法，但子容器还是可以根据自身情况再添加内容。

2、ContainerBase的init()方法是service初始化的时候调用的。但四个子容器的init方法“并不是”在ContainerBase的init()方法中被循环调用。而是在执行start()方法时，通过状态判定来调用的init()（如果没初始化就初始化）。

3、Context和Wrapper是“动态添加的”，在站点目录下每放置一个war包，就会动态添加一个Context，在web.xml里每配置一个servlet，就可以动态添加一个Wrapper。所以子容器的start方法不仅仅在“tomcat启动的时候会被调用”，当"父容器ContainerBase添加某个子容器时"，也会调用该子容器的start()方法。

Container的执行流程为两条：

初始化

第一条流程为：Service执行init()调用Container的init()方法（注意，此时Container并不会调用子容器的init()方法），然后Service执行start()时调用Container的start，Container的start再循环调用每一个子容器的start()方法。然后再调用管道的“生命周期管理”（管道不需要初始化，所以在init()中不会调用）。第一条流程的流程图示如下：

 

Container的init()和start()方法执行内容如下：

一、Container的启动是通过init()和start()完成的。之前分析过这两个方法都会通过service来调用。

init()和start存在于LifecycelBean中，实际上最后调用的是ContainerBase中的initInternal()和startInternal()方法。

ContainerBase的initInternal方法主要是初始化了ThreadPoolExecutor类（startStopExecutor属性），用于管理启动和关闭的线程。

ThreadPoolExecutor继承自Executor用于管理线程，这里就不过多介绍了。

代码如下：

    protected void initInternal() throws LifecycleException {
        LinkedBlockingQueue startStopQueue = new LinkedBlockingQueue();
        this.startStopExecutor = new ThreadPoolExecutor(this.getStartStopThreadsInternal(), this.getStartStopThreadsInternal(), 10L, TimeUnit.SECONDS, startStopQueue, new ContainerBase.StartStopThreadFactory(this.getName() + "-startStop-"));
        this.startStopExecutor.allowCoreThreadTimeOut(true);
        super.initInternal();
    }

二、ContainerBase执行完initInternal后，会由于service的start的调用，执行ContainerBase的startInternal()方法。

代码如下：

    protected synchronized void startInternal() throws LifecycleException {
        this.logger = null;
        this.getLogger();

 //如果有Cluster和Realm，则调用他们的start方法。
        Cluster cluster = this.getClusterInternal();
        if(cluster != null && cluster instanceof Lifecycle) {
            ((Lifecycle)cluster).start();
        }

        Realm realm = this.getRealmInternal();
        if(realm != null && realm instanceof Lifecycle) {
            ((Lifecycle)realm).start();
        }

        Container[] children = this.findChildren();
        ArrayList results = new ArrayList();

 //使用startStopExecutor调用新线程来启动每一个子容器
        for(int fail = 0; fail < children.length; ++fail) {
            results.add(this.startStopExecutor.submit(new ContainerBase.StartChild(children[fail])));
        }

        boolean var10 = false;
        Iterator i$ = results.iterator();

        while(i$.hasNext()) {
            Future result = (Future)i$.next();

            try {
                result.get();
            } catch (Exception var9) {
                log.error(sm.getString("containerBase.threadedStartFailed"), var9);
                var10 = true;
            }
        }

        if(var10) {
            throw new LifecycleException(sm.getString("containerBase.threadedStartFailed"));
        } else {
     //调用管道的启动方法
            if(this.pipeline instanceof Lifecycle) {
                ((Lifecycle)this.pipeline).start();
            }

     //设置生命周期状态为STARTING状态。
            this.setState(LifecycleState.STARTING);

     //调用threadStart方法启动后台线程
            this.threadStart();
        }
    }

startInternal()方法主要做了5件事：

1、如果有Cluster和Realm，则调用他们的start方法。

Cluster用于配置集群，在server.xml中可配置，它的作用是同步session。

Realm是tomcat的安全域，可以用来管理资源的访问权限。

2、使用startStopExecutor调用新线程来启动每一个子容器（即调用他们的start()方法），具体启动过程是通过一个for循环对每个子容器启动一个线程（这样可以多个线程同时启动，效率高），并将返回的Future保存到一个List中，然后遍历每个Future并调用其get方法。（下面详细说）

3、调用管道中Value的start方法来启动管道。（下面详细说）

4、设置生命周期状态为STARTING状态。

5、调用threadStart方法启动后台线程，该线程是一个while循环，定期调用backgroundProcess方法做一些事情，间隔时间可通过属性设置，单位是秒，如果小于0就不启动后台线程了。

backgroundProcess()方法在ContainerBase、StandardContext、StandardWrapper中都有实现。

ContainerBase中的backgroundProcess()：调用了Cluster、Realm和管道的backgroundProcess()方法。

StandardContext中的backgroundProcess()：调用ContainerBase中的backgroundProcess()，还对Session过期和资源变化进行了处理。

StandardWrapper中的backgroundProcess()：调用ContainerBase中的backgroundProcess()，还会对jsp生成的servlet定期进行检查。

至此Container的启动就完成了，接下来我们详细的说一下上面的四个子容器的启动，和管道的启动。

先来看看使用startStopExecutor调用新线程来启动每一个子容器（即调用他们的start()方法）时，每一个子容器都干了些啥。

由于每一个子容器的接口都继承自Container接口，而Container接口又继承自Lifecycle接口，所以每一个子容器都有完整的生命周期（都拥有start和init方法），所以调用各个子容器的start方法实际上就是调用他们各自实现类的startInternal()方法。

StandardEngine

protected void initInternal() throws LifecycleException {
    this.getRealm();
    super.initInternal();
}

由源码可看出init方法调用了getRealm()，作用是如果没有配置Realm，则使用默认的NullPealm。然后调用了父类ContainerBase中的initInternal方法。

protected synchronized void startInternal() throws LifecycleException {
    if(log.isInfoEnabled()) {
        log.info("Starting Servlet Engine: " + ServerInfo.getServerInfo());
    }

    super.startInternal();
}

由源码可看出：startInternal()只是调用了父类的startInternal()方法。

StandardHost

Host的默认实现类StandardHost没有重写initInternal方法，所以初始化时调用的是父类的相应方法。

startInternal代码如下：

protected synchronized void startInternal() throws LifecycleException {
    String errorValve = this.getErrorReportValveClass();
    if(errorValve != null && !errorValve.equals("")) {
        try {
            boolean t = false;
            Valve[] valves = this.getPipeline().getValves();
            Valve[] valve = valves;
            int len$ = valves.length;

            for(int i$ = 0; i$ < len$; ++i$) {
                Valve valve1 = valve[i$];
                if(errorValve.equals(valve1.getClass().getName())) {
                    t = true;
                    break;
                }
            }

            if(!t) {
                Valve var9 = (Valve)Class.forName(errorValve).newInstance();
                this.getPipeline().addValve(var9);
            }
        } catch (Throwable var8) {
            ExceptionUtils.handleThrowable(var8);
            log.error(sm.getString("standardHost.invalidErrorReportValveClass", new Object[]{errorValve}), var8);
        }
    }

    super.startInternal();
}

由此看到此方法就是查看管道中是否有ErrorReportValve，如果没有就将他添加进去。判断的方法就是遍历管道里面的所有value，然后通过每个value的名字进行判断。

StandardContext

在startInternal中通过一个var25的boolean来判断是否进行下一步的处理，起始位true，当中途遇到问题后改为false，后面某些处理就不做了。

if(var25 && !this.listenerStart()) {
    log.error(sm.getString("standardContext.listenerFail"));
    var25 = false;
}

此处触发Listener（Listener定义在web.xml中）。

if(var25 && !this.filterStart()) {
    log.error(sm.getString("standardContext.filterFail"));
    var25 = false;
}

此处触发web.xml中配置的filter过滤器。

if(var25 && !this.loadOnStartup(this.findChildren())) {
    log.error(sm.getString("standardContext.servletFail"));
    var25 = false;
}

此处初始化了所有Servlet，即调用在web.xml中配置了load-on-startup的servlet的init方法初始化（load-on-startup的作用是标记容器是否在启动时加载此servlet）。

StandardWrapper

StandardWrapper没有重写initInternal方法，其startInternal()源码如下：

protected synchronized void startInternal() throws LifecycleException {
    Notification notification;
    if(this.getObjectName() != null) {
        notification = new Notification("j2ee.state.starting", this.getObjectName(), (long)(this.sequenceNumber++));
        this.broadcaster.sendNotification(notification);
    }

    super.startInternal();
    this.setAvailable(0L);
    if(this.getObjectName() != null) {
        notification = new Notification("j2ee.state.running", this.getObjectName(), (long)(this.sequenceNumber++));
        this.broadcaster.sendNotification(notification);
    }

}

主要就做了三件事：

1、用broadcaster发送通知，只要用于JMX，

2、调用父类的startInternal方法

3、调用setAvailable方法，作用是设置Wrapper包含的所有servlet的有效的起始时间。 

下面谈论管道的startInternal方法：

管道

由源码可知管道是在ContainerBase中启动的，而四个子容器都继承了ContainerBase，所以四个自容器都有属于自己的管道。

而每一个管道里装的都是“Value”类型，Value是接口，Value的实现类用于进行各种各样的具体处理操作。

所谓管道就是指多个处理者（value）对某一个请求“依次”进行处理，请求交给第一个value处理完后，再交给第二个value处理·····，每一条管道的“最后一个Value”都会有点特殊，该Value会将请求发送给下一个管道，然后下一个管道拿到请求后，继续交给该管道内的第一个value处理·····

举例，如：

请求到达Engine后，实际上是传给了Engine的管道（因为Engine继承了Container，所以他拥有StandardPipeline类型的管道），然后管道中有一个Value first属性，该属性是一个链式结构，存放在管道中first里面的Value是该管道的第一个value，而该value内部存在指针，指向他的下一个value。

管道就能依靠头value来遍历该管道内的每一个value，让他们依次处理请求。

而Engine管道的最后一个value为StandardEngineValue类，该value会将请求发送给Host的管道。

总结一下，每一个子容器都有它的StandardPipeline管道，每一条管道中装有多个value，value中的 invoke方法用来进行具体的处理请求，每个管道中的最后一个value会将请求传给下一个子容器的管道。（感觉自己有点啰嗦了。。。 (｀・ω・´)）

回到管道的生命周期讲解，

在ContainerBase中调用管道的启动方法（该语句存在于startInternal中）：

if(this.pipeline instanceof Lifecycle) {
    ((Lifecycle)this.pipeline).start();
}

Pipeline的实现类为StandardPipeline类。该类中相应的源码为：

protected synchronized void startInternal() throws LifecycleException {
    Valve current = this.first;
    if(current == null) {
        current = this.basic;
    }

    for(; current != null; current = current.getNext()) {
        if(current instanceof Lifecycle) {
            ((Lifecycle)current).start();
        }
    }

    this.setState(LifecycleState.STARTING);
}

首先调用了first属性赋值给了current，first属性里存储的是“第一个value”，并将它赋值到了当前value上。

之后做了一个判断，判断当前value是否为空，为空就将当前value设置为“最后一个value”。

之后从当前value（即：第一个value）开始调用start方法，每调用完一个，就将当前value的下一个value赋值到当前value上。即：循环调用该管道内所有value的start方法。

我们再来看一下value的start方法。

value继承于生命周期接口，所以调用start就是调用其子类的startInternal()方法。

所有的子value都继承于ValueBase类，而startInternal方法就是定义在ValueBase类里，源码如下：

protected synchronized void startInternal() throws LifecycleException {
    this.setState(LifecycleState.STARTING);
}

可以看出ValueBase中的startInternal方法只做了一件事，就是将当前状态设置为STARTING。

至此，第一条流程就完成了。

传值

第二条流程为：Connector的Adapter将request和response传给Container的管道，从Engine的管道一路处理到Wrapper的管道，Wrapper再将response一路返回给Engine，然后Engine将response返回给Connector，Connector再返回给用户浏览器。

需要提前说明的是，四个自容器的管道中，每个管道都有多个value用来依次处理请求，但我在这主要分析“每个子容器管道的最后一个value”，分别是：StandardEngineValue、StandardHostValue、StandardContextValue、StandardWrapperValue。

StandardEngineValue

final class StandardEngineValve extends ValveBase {
    private static final StringManager sm = StringManager.getManager("org.apache.catalina.core");

    public StandardEngineValve() {
        super(true);
    }

    public final void invoke(Request request, Response response) throws IOException, ServletException {
        Host host = request.getHost();
        if(host == null) {
            response.sendError(400, sm.getString("standardEngine.noHost", new Object[]{request.getServerName()}));
        } else {
            if(request.isAsyncSupported()) {
                request.setAsyncSupported(host.getPipeline().isAsyncSupported());
            }

            host.getPipeline().getFirst().invoke(request, response);
        }
    }

    public final void event(Request request, Response response, CometEvent event) throws IOException, ServletException {
        request.getHost().getPipeline().getFirst().event(request, response, event);
    }
}

这里的invoke方法主要就做了一件事：

根据请求找到所对应的站点（Host），然后找到host的管道，调用其头部value的invoke方法，并把request和response传给他。

StandardHostValue

其invoke源码为：

public final void invoke(Request request, Response response) throws IOException, ServletException {
    Context context = request.getContext();
    if(context == null) {
        response.sendError(500, sm.getString("standardHost.noContext"));
    } else {
        if(request.isAsyncSupported()) {
            request.setAsyncSupported(context.getPipeline().isAsyncSupported());
        }

        boolean asyncAtStart = request.isAsync();
        boolean asyncDispatching = request.isAsyncDispatching();

        try {
            context.bind(Globals.IS_SECURITY_ENABLED, MY_CLASSLOADER);
            if(!asyncAtStart && !context.fireRequestInitEvent(request)) {
                return;
            }

            try {
                if(asyncAtStart && !asyncDispatching) {
                    if(!response.isErrorReportRequired()) {
                        throw new IllegalStateException(sm.getString("standardHost.asyncStateError"));
                    }
                } else {
                    context.getPipeline().getFirst().invoke(request, response);
                }
            } catch (Throwable var10) {
                ExceptionUtils.handleThrowable(var10);
                if(response.isErrorReportRequired()) {
                    this.container.getLogger().error("Exception Processing " + request.getRequestURI(), var10);
                } else {
                    request.setAttribute("javax.servlet.error.exception", var10);
                    this.throwable(request, response, var10);
                }
            }

            response.setSuspended(false);
            Throwable t = (Throwable)request.getAttribute("javax.servlet.error.exception");
            if(!context.getState().isAvailable()) {
                return;
            }

            if(response.isErrorReportRequired()) {
                if(t != null) {
                    this.throwable(request, response, t);
                } else {
                    this.status(request, response);
                }
            }

            if(!request.isAsync() && (!asyncAtStart || !response.isErrorReportRequired())) {
                context.fireRequestDestroyEvent(request);
            }
        } finally {
            if(ACCESS_SESSION) {
                request.getSession(false);
            }

            context.unbind(Globals.IS_SECURITY_ENABLED, MY_CLASSLOADER);
        }

    }
}

Host的用处再上上面已经讲过了，一个host代表一个站点（也叫一个虚拟主机），

其处理过程可以总结如下：

1、先根据request请求，选择一个context容器。如果不为空，则继续处理。

2、调用Context容器的bind()方法。此方法获取一条线程，然后让该线程处理Context。

3、获取context的管道，再调用管道中头value的invoke方法，将request和response传入其中。

StandardContextValue

其invoke源码如下：

public final void invoke(Request request, Response response) throws IOException, ServletException {
    MessageBytes requestPathMB = request.getRequestPathMB();
    if(!requestPathMB.startsWithIgnoreCase("/META-INF/", 0) && !requestPathMB.equalsIgnoreCase("/META-INF") && !requestPathMB.startsWithIgnoreCase("/WEB-INF/", 0) && !requestPathMB.equalsIgnoreCase("/WEB-INF")) {
        Wrapper wrapper = request.getWrapper();
        if(wrapper != null && !wrapper.isUnavailable()) {
            try {
                response.sendAcknowledgement();
            } catch (IOException var6) {
                this.container.getLogger().error(sm.getString("standardContextValve.acknowledgeException"), var6);
                request.setAttribute("javax.servlet.error.exception", var6);
                response.sendError(500);
                return;
            }

            if(request.isAsyncSupported()) {
                request.setAsyncSupported(wrapper.getPipeline().isAsyncSupported());
            }

            wrapper.getPipeline().getFirst().invoke(request, response);
        } else {
            response.sendError(404);
        }
    } else {
        response.sendError(404);
    }
}

其处理过程可以总结如下：

1、先获取request的请求路径，该路径不能直接访问WEB-INF或者META-INF目录下的资源。

2、再根据request，选择合适的Wrapper。

3、再在response中设置一个sendAcknowledgement（在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。）

4、获取Wrapper的管道，再调用管道中头value的invoke方法，将request和response传入其中。

StandardWrapperValue

每个Wrapper都封装着一个servlet，所以Wrapper和servlet有着很深的联系。

StandardWrapper里会加载他代表的servlet并创建实例（即调用它的init方法），但不会调用servlet的service方法。

StandardWrapperValue会调用sertvlet的service方法。

其具体执行顺序如下，

1、分配一个Servlet实例，因为StandardWrapper负责加载servlet，所以也是从Wrapper中获取servlet。

try {
    if(!unavailable) {
        servlet = wrapper.allocate();
    }
} catch (UnavailableException var38) {
    this.container.getLogger().error(sm.getString("standardWrapper.allocateException", new Object[]{wrapper.getName()}), var38);
    long requestPathMB = wrapper.getAvailable();
    if(requestPathMB > 0L && requestPathMB < 9223372036854775807L) {
        response.setDateHeader("Retry-After", requestPathMB);
        response.sendError(503, sm.getString("standardWrapper.isUnavailable", new Object[]{wrapper.getName()}));
    } else if(requestPathMB == 9223372036854775807L) {
        response.sendError(404, sm.getString("standardWrapper.notFound", new Object[]{wrapper.getName()}));
    }
} catch (ServletException var39) {
    this.container.getLogger().error(sm.getString("standardWrapper.allocateException", new Object[]{wrapper.getName()}), StandardWrapper.getRootCause(var39));
    throwable = var39;
    this.exception(request, response, var39);
} catch (Throwable var40) {
    ExceptionUtils.handleThrowable(var40);
    this.container.getLogger().error(sm.getString("standardWrapper.allocateException", new Object[]{wrapper.getName()}), var40);
    throwable = var40;
    this.exception(request, response, var40);
    servlet = null;
}

2、执行Servlet相关的所有过滤器：

ApplicationFilterChain filterChain = ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);

try {
    if(servlet != null && filterChain != null) {
        if(context.getSwallowOutput()) {
            boolean var29 = false;

            try {
                var29 = true;
                SystemLogHandler.startCapture();
                if(request.isAsyncDispatching()) {
                    ((AsyncContextImpl)request.getAsyncContext()).doInternalDispatch();
                    var29 = false;
                } else if(comet1) {
                    filterChain.doFilterEvent(request.getEvent());
                    var29 = false;
                } else {
                    filterChain.doFilter(request.getRequest(), response.getResponse());
                    var29 = false;
                }
            } finally {
                if(var29) {
                    String time = SystemLogHandler.stopCapture();
                    if(time != null && time.length() > 0) {
                        context.getLogger().info(time);
                    }

                }
            }

            String t2 = SystemLogHandler.stopCapture();
            if(t2 != null && t2.length() > 0) {
                context.getLogger().info(t2);
            }
        } else if(request.isAsyncDispatching()) {
            ((AsyncContextImpl)request.getAsyncContext()).doInternalDispatch();
        } else if(comet1) {
            filterChain.doFilterEvent(request.getEvent());
        } else {
            filterChain.doFilter(request.getRequest(), response.getResponse());
        }
    }
}

ApplicationFilterChain可以看做是一个“过滤器链”，StandardWrapperValve中的invoke会先创建该类的实例，然后调用它的doFilter方法，即从该链中的第一个过滤器开始调用。如果执行到了最后一个过滤器，就开始调用Servlet的service方法。

3、关闭过滤器链

if(filterChain != null) {
    if(request.isComet()) {
        filterChain.reuse();
    } else {
        filterChain.release();
    }
}

4、通知Wrapper，重新委派处理完毕的servlet。

try {
    if(servlet != null) {
        wrapper.deallocate(servlet);
    }
} catch (Throwable var31) {
    ExceptionUtils.handleThrowable(var31);
    this.container.getLogger().error(sm.getString("standardWrapper.deallocateException", new Object[]{wrapper.getName()}), var31);
    if(throwable == null) {
        throwable = var31;
        this.exception(request, response, var31);
    }
}

至此Container第二条流程也完成了。

总结出来，简易流程图如下：

 

本文转载自

原文作者：black-ant

原文链接：https://blog.csdn.net/zzg19950824/article/details/79433735