Tomcat源码分析-启动分析(三) Catalina启动

在上一篇文章中，我们分析了tomcat的初始化过程，是由Bootstrap反射调用Catalina的load方法完成tomcat的初始化，包括server.xml的解析、实例化各大组件、初始化组件等逻辑。那么tomcat又是如何启动webapp应用，又是如何加载应用程序的ServletContextListener，以及Servlet呢？我们将在这篇文章进行分析

我们先来看下整体的启动逻辑，tomcat由上往下，挨个启动各个组件：

针对如此复杂的组件关系，tomcat 又是如何将各个组件串联起来，实现统一的生命周期管控呢？在这篇文章中，我们将分析 Service、Engine、Host、Pipeline、Valve 组件的启动逻辑，进一步理解tomcat的架构设计

1、Bootstrap

启动过程和初始化一样，由Bootstrap反射调用Catalina的start方法

public void start() throws Exception {if( catalinaDaemon==null ) init();Method method = catalinaDaemon.getClass().getMethod("start", (Class [] )null);method.invoke(catalinaDaemon, (Object [])null);

2、Catalina

主要分为以下三个步骤，其核心逻辑在于Server组件：
1、 调用Server的start方法，启动Server组件
2、 注册jvm关闭的勾子程序，用于安全地关闭Server组件，以及其它组件
3、 开启shutdown端口的监听并阻塞，用于监听关闭指令

public void start() {// 省略若干代码......// Start the new servertry {getServer().start();} catch (LifecycleException e) {// 省略......return;}// 注册勾子，用于安全关闭tomcatif (useShutdownHook) {if (shutdownHook == null) {shutdownHook = new CatalinaShutdownHook();}Runtime.getRuntime().addShutdownHook(shutdownHook);}// Bootstrap中会设置await为true，其目的在于让tomcat在shutdown端口阻塞监听关闭命令if (await) {await();stop();}

3、Server

在前面的Lifecycle文章中，我们介绍了StandardServer重写了startInternal方法，完成自己的逻辑，如果对tomcat的Lifecycle还不熟悉的童鞋，先学习下Lifecycle，《Tomcat8源码分析系列-启动分析(一) Lifecycle》

StandardServer的代码如下所示：

protected void startInternal() throws LifecycleException {fireLifecycleEvent(CONFIGURE_START_EVENT, null);setState(LifecycleState.STARTING);globalNamingResources.start();// Start our defined Servicessynchronized (servicesLock) {for (int i = 0; i < services.length; i++) {services[i].start();}}

先是由LifecycleBase统一发出STARTING_PREP事件，StandardServer额外还会发出CONFIGURE_START_EVENT、STARTING事件，用于通知LifecycleListener在启动前做一些准备工作，比如NamingContextListener会处理CONFIGURE_START_EVENT事件，实例化tomcat相关的上下文，以及ContextResource资源

然后，启动内部的NamingResourcesImpl实例，这个类封装了各种各样的数据，比如ContextEnvironment、ContextResource、Container等等，它用于Resource资源的初始化，以及为webapp应用提供相关的数据资源，比如 JNDI 数据源(对应ContextResource)

接着，启动Service组件，这一块的逻辑将在下面进行详细分析，最后由LifecycleBase发出STARTED事件，完成start

4、Service

StandardService的start代码如下所示：
1、 启动Engine，Engine的child容器都会被启动，webapp的部署会在这个步骤完成；
2、 启动Executor，这是tomcat用Lifecycle封装的线程池，继承至java.util.concurrent.Executor以及tomcat的Lifecycle接口
3、 启动Connector组件，由Connector完成Endpoint的启动，这个时候意味着tomcat可以对外提供请求服务了

protected void startInternal() throws LifecycleException {setState(LifecycleState.STARTING);// 启动Engineif (engine != null) {synchronized (engine) {engine.start();}}// 启动Executor线程池synchronized (executors) {for (Executor executor: executors) {executor.start();}}// 启动MapperListenermapperListener.start();// 启动Connectorsynchronized (connectorsLock) {for (Connector connector: connectors) {try {// If it has already failed, don't try and start itif (connector.getState() != LifecycleState.FAILED) {connector.start();}} catch (Exception e) {// logger......}}}

5、Engine

在Server调用startInternal启动的时候，首先会调用start启动StandardEngine，而StandardEngine继承至ContainerBase，我们再来回顾下Lifecycle类图，关于Container，我们只需要关注右下角的部分即可。

StandardEngine、StandardHost、StandardContext、StandardWrapper各个容器存在父子关系，一个父容器包含多个子容器，并且一个子容器对应一个父容器。Engine是顶层父容器，它不存在父容器，关于各个组件的详细介绍，请参考《tomcat框架设计》。各个组件的包含关系如下图所示，默认情况下，StandardEngine只有一个子容器StandardHost，一个StandardContext对应一个webapp应用，而一个StandardWrapper对应一个webapp里面的一个 Servlet

由类图可知，StandardEngine、StandardHost、StandardContext、StandardWrapper都是继承至ContainerBase，各个容器的启动，都是由父容器调用子容器的start方法，也就是说由StandardEngine启动StandardHost，再StandardHost启动StandardContext，以此类推。

由于它们都是继续至ContainerBase，当调用 start 启动Container容器时，首先会执行 ContainerBase 的 start 方法，它会寻找子容器，并且在线程池中启动子容器，StandardEngine也不例外。

5.1、ContainerBase

ContainerBase的startInternal方法如下所示，主要分为以下3个步骤：
1、 启动子容器
2、 启动Pipeline，并且发出STARTING事件
3、 如果backgroundProcessorDelay参数 >= 0，则开启ContainerBackgroundProcessor线程，用于调用子容器的backgroundProcess

protected synchronized void startInternal() throws LifecycleException {// 省略若干代码......// 把子容器的启动步骤放在线程中处理，默认情况下线程池只有一个线程处理任务队列Container children[] = findChildren();List<Future<Void>> results = new ArrayList<>();for (int i = 0; i < children.length; i++) {results.add(startStopExecutor.submit(new StartChild(children[i])));}// 阻塞当前线程，直到子容器start完成boolean fail = false;for (Future<Void> result : results) {try {result.get();} catch (Exception e) {log.error(sm.getString("containerBase.threadedStartFailed"), e);fail = true;}}// 启用Pipelineif (pipeline instanceof Lifecycle)((Lifecycle) pipeline).start();setState(LifecycleState.STARTING);// 开启ContainerBackgroundProcessor线程用于调用子容器的backgroundProcess方法，默认情况下backgroundProcessorDelay=-1，不会启用该线程threadStart();

5.2、启动子容器

startStopExecutor是在init阶段创建的线程池，默认情况下 coreSize = maxSize = 1，也就是说默认只有一个线程处理子容器的 start，通过调用 Container.setStartStopThreads(int startStopThreads) 可以改变默认值 1
。如果我们有4个webapp，希望能够尽快启动应用，我们只需要设置Host的startStopThreads值即可，如下所示。

server.xml<Host name="localhost"  appBase="webapps"unpackWARs="true" autoDeploy="true" startStopThreads="4"><Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"prefix="localhost_access_log" suffix=".txt"pattern="%h %l %u %t "%r" %s %b" />

ContainerBase会把StartChild任务丢给线程池处理，得到Future，并且会遍历所有的Future进行阻塞result.get()，这个操作是将异步启动转同步，子容器启动完成才会继续运行。我们再来看看submit到线程池的StartChild任务，它实现了java.util.concurrent.Callable接口，在call里面完成子容器的start动作

private static class StartChild implements Callable<Void> {private Container child;public StartChild(Container child) {this.child = child;}@Overridepublic Void call() throws LifecycleException {child.start();return null;