1. 调用 StandardServer.initialize 开始组件的初始化，触发 INIT_EVENT 事件，详细过程：
2. 初始化 StandardServer：首先触发各 Listener（具体有哪些，可查看xml的配置）的执行，然后初始化内部的 Services；
3. Service 主要是初始化定义的 Connectors；
4. 初始化 Connector：初始化 Adapter 和 ProtocolHandler，处理器有两种不同实现：

• Http11NioProtocol 初始化：NioEndpoint 设置线程池名称、设置ConnectionHandler、设置接收和发送 ByteBuffer 容量；SSL相关实现初始化；初始化 NioEndpoint：初始化 ServerSocketChannel，设置成阻塞模式，绑定端口；设置 Acceptor、Poller 线程数目；初始化 SSL 信息；初始化 NioSelectorPool；
• Http11Protocol 初始化：JIoEndpoint 设置线程池名和ConnectionHandler，初始化 ServerSocketFactory；初始化 JioEndpoint：设置 Acceptor 线程数；创建 ServerSocket 并绑定端口。

1. 初始化完毕

以上就是在组件在init生命周期事件中完成的设置，注意在 Digester 解析过程中，也完成了一系列的设置。

启动

调用 StandardServer.start 开启组件的启动过程，触发 BEFORE_START_EVENT、START_EVENT、AFTER_START_EVENT 事件：

1. 启动 StandardServer：触发执行各 Listener；启动内部的 Services；
2. Service 默认没有 Listener，首先启动 Engines 、接着启动 Executors、最后启动 Connectors；
3. 启动 Engine，它调用 super.start() 进行启动或触发以下的动作：

• 尝试启动 Manager、Cluster、Realm（LockOutRealm）；
• 启动子容器 Hosts；
• EngineConfig 监听器的执行 - START_EVENT，STOP_EVENT；
• 启动后台线程，定期检查会话超时。

1. 启动 Host：设置 ErrorReportValve，并添加到自己的 pipeline 中，触发 ADD_VALVE_EVENT 容器事件，调用 super.start()：

• 启动子容器 Contexts；
• 启动 pipeline 中实现 Lifecycle 的 Valve。
• 触发 HostConfig 监听器的执行：
• PERIODIC_EVENT：检查所有Web应用程序的状态；
• START_EVENT：创建 Context，启动并部署 webapps & conf/Catalina/localhost/*.xml；
• STOP_EVENT：取消已部署的所有应用。

1. 启动 Context，部署 Web App

• 根据 context.xml（或默认的）使用 Digester 创建 StandardContext 对象，添加 ContextConfig 监听器，通过 host.addChild 启动 Context；
• 初始化用于解析 web.xml 的 Digester，创建设置 WebappLoader 且不使用”标准委托模型”；
• 先解析默认的 conf/web.xml，然后处理 WEB-INF/web.xml，创建 StandardWrapper 封装 Servlet。

1. 启动 Connector，无 Listener，它主要是启动 ProtocolHandler：

• Http11NioProtocol - 启动 NioEndpoint - 启动 Poller 线程，启动 Acceptor 线程；
• Http11Protocol - 启动 JioEndpoint - 启动 Acceptor 线程。

1. 注册 ShutdownHook，阻塞 main 线程，启动完毕。

接下来就该处理请求了，这部分下一篇会介绍。

停止

当调用 Bootstrap.stop 或接收到 SHUTDOWN 指令或者捕捉到系统关闭信号（如ctrl+c，shutdown，logoff）时，开始调用 Catalina.stop 方法，关闭组件，触发 BEFORE_STOP_EVENT、STOP_EVENT 事件：停止Server、Service，暂停 Connector，停止内部组件，停止 Connector，关闭线程池，打断 awaitThread 即 main 线程，结束。

如果 stop 命令执行失败，尝试使用系统信号终止，首先使用 kill -15 ，进程收到后进行处理；如果还是失败那么，等待 5s 后，使用 kill -9 强制终止。

小结

当我看到 Web应用加载的时候，耐心有点不足，感觉捋顺了整个过程，其实还有很多地方经不起推敲，为了看得更透彻，那么这个”简单”的启动过程，又有哪些值得思考的呢？

内部启动的线程和线程池中的线程为什么设置为守护线程（Daemon）？

Java 中有两类线程：守护线程与用户线程，区别是守护线程不会阻止 JVM 的退出。从 Tomcat 的停止流程来看，就算用非守护线程也不会出现什么问题，没有搜到官方对此的描述，这里按照理解强行解释一波 :)。

守护线程一般是服务提供者，运行系统代码，比如 GC 线程，就像操作系统中也区分用户线程和内核线程那样，Tomcat 将内部线程设为 daemon，也能很好的在语义上区分 Servlet 启动的线程，并且对于 Servlet 来说 Tomcat 就是它的操作系统。

生命周期的设计有什么好处？

保证组件启动和停止的一致性，为生命周期事件添加监听器，这些监听器处理其感兴趣的事件，来做一些额外的操作。这是观察者模式的应用。

多应用间如何实现隔离？

应用隔离的本质就是类隔离，主要防止类冲突。类是否相等是由其全限定名和类加载器共同决定的，容器就是通过自定义 ClassLoader 实现应用间隔离，Tomcat 类加载器结构：

当要求类加载器加载类时，它首先将请求委托给父加载器，然后在父加载器找不到所请求的类时，查找自己的存储库。而 Webapp 加载器略有不同，它首先会在自己的资源库中搜索，而不是向上委托，打破了标准的委托机制，其类加载时按以下顺序查找资源库：

• Bootstrap 和 System 已加载的类
• /WEB-INF/classes 和 /WEB-INF/lib/*.jar
• Common 已加载的类

应用热加载和热部署？

当在启动 Engine 时，会新建一个名为 ContainerBackgroundProcessor[StandardEngine[Catalina]] 的线程，默认 10s 检查是否要重新加载或重新部署，对应方法在 Loader 接口定义分别是 backgroundProcess 和 modified。

默认 web.xml 配置了什么？

• 提供一个 DefaultServlet，用于处理静态资源和未找到匹配 Servlet 的请求；
• 用于编译和执行 JSP 的 JspServlet；
• Session 默认超时 30 minutes；
• 默认 MIME Type 映射和 Welcome Files

其他能够想到的点

采用都是常用的数据结构，如 ArrayList、数组、HashMap等，Pipeline 采用链表实现，Digester 使用栈来解析。欢迎补充。

列表好像不支持2、3级嵌套啊...行文中部分链接无法添加，如需要可点击了解更多查看！

閱讀更多 拆輪子 的文章

關鍵字: 组件 Java虚拟机 脚本语言