2021年6月22日星期二

面试官:谈谈 Tomcat 架构及启动过程,我一脸懵逼。。

来源:https://github.com/c-rainstorm/blog/tree/master/tomcat

这个题目命的其实是很大的,写的时候还是很忐忑的,但我尽可能把这个过程描述清楚。因为这是读过源码以后写的总结,在写的过程中可能会忽略一些前提条件,如果有哪些比较突兀就出现,或不好理解的地方可以给我提 Issue,我会尽快补充修订相关内容。

很多东西在时序图中体现的已经非常清楚了,没有必要再一步一步的作介绍,所以本文以图为主,然后对部分内容加以简单解释。

绘制图形使用的工具是 PlantUML + Visual Studio Code + PlantUML Extension

本文对 Tomcat 的介绍以 Tomcat-9.0.0.M22 为标准。

https://tomcat.apache.org/tomcat-9.0-doc/index.html

Overview

  1. Bootstrap 作为 Tomcat 对外界的启动类,在 $CATALINA_BASE/bin 目录下,它通过反射创建 Catalina 的实例并对其进行初始化及启动。
  2. Catalina 解析 $CATALINA_BASE/conf/server.
  3. StandardServer 代表的是整个 Servlet 容器,他包含一个或多个 StandardService
  4. StandardService 包含一个或多个 Connector,和一个 Engine,Connector 和 Engine 都是在解析 conf/server.
  5. MapperListener 实现了 LifecycleListener 和 ContainerListener 接口用于监听容器事件和生命周期事件。该监听器实例监听所有的容器,包括 StandardEngine、StandardHost、StandardContext、StandardWrapper,当容器有变动时,注册容器到 Mapper。
  6. Mapper 维护了 URL 到容器的映射关系。当请求到来时会根据 Mapper 中的映射信息决定将请求映射到哪一个 Host、Context、Wrapper。
  7. Http11NioProtocol 用于处理 HTTP/1.1 的请求
  8. NioEndpoint 是连接的端点,在请求处理流程中该类是核心类,会重点介绍。
  9. CoyoteAdapter 用于将请求从 Connctor 交给 Container 处理。使 Connctor 和 Container 解耦。
  10. StandardEngine 代表的是 Servlet 引擎,用于处理 Connector 接受的 Request。包含一个或多个 Host(虚拟主机), Host 的标准实现是 StandardHost。
  11. StandardHost 代表的是虚拟主机,用于部署该虚拟主机上的应用程序。通常包含多个 Context (Context 在 Tomcat 中代表应用程序)。Context 在 Tomcat 中的标准实现是 StandardContext。
  12. StandardContext 代表一个独立的应用程序,通常包含多个 Wrapper,一个 Wrapper 容器封装了一个 Servlet,Wrapper的标准实现是 StandardWrapper。
  13. StandardPipeline 组件代表一个流水线,与 Valve(阀)结合,用于处理请求。 StandardPipeline 中含有多个 Valve, 当需要处理请求时,会逐一调用 Valve 的 invoke 方法对 Request 和 Response 进行处理。特别的,其中有一个特殊的 Valve 叫 basicValve,每一个标准容器都有一个指定的 BasicValve,他们做的是最核心的工作。
  • StandardEngine 的是 StandardEngineValve,他用来将 Request 映射到指定的 Host;
  • StandardHost 的是 StandardHostValve, 他用来将 Request 映射到指定的 Context;
  • StandardContext 的是 StandardContextValve,它用来将 Request 映射到指定的 Wrapper;
  • StandardWrapper 的是 StandardWrapperValve,他用来加载 Rquest 所指定的 Servlet,并调用 Servlet 的 Service 方法。

Tomcat init

  • 当通过 ./startup.sh 脚本或直接通过 java 命令来启动 Bootstrap 时,Tomcat 的启动过程就正式开始了,启动的入口点就是 Bootstrap 类的 main 方法。
  • 启动的过程分为两步,分别是 init 和 start,本节主要介绍 init;
  • 初始化类加载器。
  1. 通过从 CatalinaProperties 类中获取 common.loader 等属性,获得类加载器的扫描仓库。CatalinaProperties 类在的静态块中调用了 loadProperties() 方法,从 conf/catalina.properties 文件中加载了属性.(即在类创建的时候属性就已经加载好了)。
  2. 通过 ClassLoaderFactory 创建 URLClassLoader 的实例
  • 通过反射创建 Catalina 的实例并设置 parentClassLoader
  • setAwait(true)。设置 Catalina 的 await 属性为 true。在 Start 阶段尾部,若该属性为 true,Tomcat 会在 main 线程中监听 SHUTDOWN 命令,默认端口是 8005.当收到该命令后执行 Catalina 的 stop() 方法关闭 Tomcat 服务器。
  • createStartDigester()。Catalina 的该方法用于创建一个 Digester 实例,并添加解析 conf/server.
  • parse() 方法就是 Digester 处理 conf/server.
  1. EngineConfig。LifecycleListener 的实现类,触发 Engine 的生命周期事件后调用,这个监听器没有特别大的作用,就是打印一下日志
  2. HostConfig。LifecycleListener 的实现类,触发 Host 的生命周期事件后调用。这个监听器的作用就是部署应用程序,这包括 conf/// 目录下所有的 Context
  3. ContextConfig。LifecycleListener 的实现类,触发 Context 的生命周期事件时调用。这个监听器的作用是配置应用程序,它会读取并合并 conf/web.
  • reconfigureStartStopExecutor() 用于重新配置启动和停止子容器的 Executor。默认是 1 个线程。我们可以配置 conf/server.
  • 需要注意的是 Host 的 init 操作是在 Start 阶段来做的, StardardHost 创建好后其 state 属性的默认值是 LifecycleState.NEW,所以在其调用 startInternal() 之前会进行一次初始化。

Tomcat Start[Deployment]

  • 图中从 StandardHost Start StandardContext 的这步其实在真正的执行流程中会直接跳过,因为 conf/server.
  • 触发 Host 的 BEFORE_START_EVENT 生命周期事件,HostConfig 调用其 beforeStart() 方法创建 CATALINA_BASE/webapps& $CATALINA_BASE/conf/// 目录。
  • 触发 Host 的 START_EVENT 生命周期事件,HostConfig 调用其 start() 方法开始部署已在 CATALINA_BASE/webapps & $CATALINA_BASE/conf/// 目录下的应用程序。
  1. 解析 $CATALINA_BASE/conf/// 目录下所有定义 Context 的
  2. 部署 $CATALINA_BASE/webapps 下所有的 WAR 文件,并添加到 StandardHost。
  3. 部署 $CATALINA_BASE/webapps 下所有已解压的目录,并添加到 StandardHost。

特别的,添加到 StandardHost 时,会直接调用 StandardContext 的 start() 方法来启动应用程序。启动应用程序步骤请看 Context Start 一节。

  • 在 StandardEngine 和 StandardContext 启动时都会调用各自的 threadStart() 方法,该方法会创建一个新的后台线程来处理该该容器和子容器及容器内各组件的后台事件。StandardEngine 会直接创建一个后台线程,StandardContext 默认是不创建的,和 StandardEngine 共用同一个。后台线程处理机制是周期调用组件的 backgroundProcess() 方法。详情请看 Background process 一节。
  • MapperListener
  1. addListeners(engine) 方法会将该监听器添加到 StandardEngine 和它的所有子容器中
  2. registerHost() 会注册所有的 Host 和他们的子容器到 Mapper 中,方便后期请求处理时使用。
  3. 当有新的应用(StandardContext)添加进来后,会触发 Host 的容器事件,然后通过 MapperListener 将新应用的映射注册到 Mapper 中。
  • Start 工作都做完以后 Catalina 会创建一个 CatalinaShutdownHook 并注册到 JVM。CatalinaShutdownHook 继承了 Thread,是 Catalina 的内部类。其 run 方法中直接调用了 Catalina 的 stop() 方法来关闭整个服务器。注册该 Thread 到 JVM 的原因是防止用户非正常终止 Tomcat,比如直接关闭命令窗口之类的。当直接关闭命令窗口时,操作系统会向 JVM 发送一个终止信号,然后 JVM 在退出前会逐一启动已注册的 ShutdownHook 来关闭相应资源。

Context Start

  • StandRoot 类实现了 WebResourceRoot 接口,它容纳了一个应用程序的所有资源,通俗的来说就是部署到 webapps 目录下对应 Context 的目录里的所有资源。因为我对 Tomcat 的资源管理部分暂时不是很感兴趣,所以资源管理相关类只是做了简单了解,并没有深入研究源代码。
  • resourceStart() 方法会对 StandardRoot 进行初始配置
  • postWorkDirectory() 用于创建对应的工作目录 $CATALINA_BASE/work///, 该目录用于存放临时文件。
  • StardardContext 只是一个容器,而 ApplicationContext 则是一个应用程序真正的运行环境,相关类及操作会在请求处理流程看完以后进行补充。
  • StardardContext 触发 CONFIGURE_START_EVENT 生命周期事件,ContextConfig 开始调用 configureStart() 对应用程序进行配置。
  1. 这个过程会解析并合并 conf/web.//web./WEB-INF/web.
  2. 配置配置文件中的参数到 StandardContext, 其中主要的包括 Servlet、Filter、Listener。
  3. 因为从 Servlet3.0 以后是直接支持注解的,所以服务器必须能够处理加了注解的类。Tomcat 通过分析 WEB-INF/classes/ 中的 Class 文件和 WEB-INF/lib/ 下的 jar 包将扫描到的 Servlet、Filter、Listerner 注册到 StandardContext。
  4. setConfigured(true),是非常关键的一个操作,它标识了 Context 的成功配置,若未设置该值为 true 的话,Context 会启动失败。

Background process

没有评论:

发表评论