Tomcat组成与工作原理总结

本文主要是介绍Tomcat组成与工作原理总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

1 Tomcat
- 1.1 Tomcat是什么
- 1.2 Servlet容器
- - 1.2.1 Connector组件
  - 1.2.2 Container组成
  - - 1.2.2.1 Container容器
    - 1.2.2.2 Container容器处理请求
    - 1.2.2.3 Engine容器
    - 1.2.2.4 Host容器
    - 1.2.2.5 Context容器
    - 1.2.2.6 Wrapper容器
  - 1.2.3 生命周期管理
  - 1.2.4 Tomcat 的启动过程
  - 1.2.5 Web应用的部署方式
  - 1.2.6 Servlet 生命周期
  - - 1.2.6.1 load on startup
    - 1.2.6.2 single thread model
    - 1.2.6.3 请求处理过程
    - 1.2.6.4 Pipeline 与 Valve
    - 1.2.6.5 相关源码
- 1.3 JSP引擎
- - 1.3.1 JSP 生命周期
  - 1.3.2 JSP元素
  - 1.3.3 Jsp 解析过程
- 1.4 Connector
- - 1.4.1 IO相关
  - 1.4.2 Tomcat各类Connector对比
  - 1.4.3 NIO处理相关类
  - 1.4.4 Comet
- 1.5 异步Servlet

1 Tomcat

1.1 Tomcat是什么

开源的Java Web应用服务器，实现了 Java EE(Java Platform Enterprise Edition)的部分技术规范，比如 Java Servlet、Java Server Page、JSTL、Java WebSocket。Java EE 是 Sun 公司为企业级应用推出的标准平台，定义了一系列用于企业级开发的技术规范，除了上述的之外，还有 EJB、Java Mail、JPA、JTA、JMS 等，而这些都依赖具体容器的实现。
在这里插入图片描述
上图对比了 Java EE 容器的实现情况，Tomcat 和 Jetty 都只提供了 Java Web 容器必需的 Servlet和 JSP 规范，开发者要想实现其他的功能，需要自己依赖其他开源实现。
Glassfish 是由 sun 公司推出，Java EE 最新规范出来之后，首先会在 Glassfish 上进行实现，所以是研究 Java EE 最新技术的首选。

最常见的情况是使用 Tomcat 作为 Java Web 服务器，使用 Spring 提供的开箱即用的强大的功能，并依赖其他开源库来完成负责的业务功能实现。

1.2 Servlet容器

Tomcat 组成如下图：主要有 Container 和 Connector 以及相关组件构成。
在这里插入图片描述

Server：指的就是整个 Tomcat 服务器，包含多组服务，负责管理和启动各个 Service，同时监听 8005 端口发过来的 shutdown 命令，用于关闭整个容器；
Service：Tomcat 封装的、对外提供完整的、基于组件的 web 服务，包含 Connectors、Container两个核心组件，以及多个功能组件，各个 Service之间是独立的，但是共享同一 JVM 的资源；
Connector：Tomcat与外部世界的连接器，监听固定端口接收外部请求，传递给 Container，并将 Container 处理的结果返回给外部；
Container：Catalina，Servlet 容器，内部有多层容器组成，用于管理 Servlet 生命周期，调用 servlet 相关方法。
Loader：封装了 Java ClassLoader，用于 Container 加载类文件；
Realm：Tomcat 中为 web 应用程序提供访问认证和角色管理的机制；
JMX：Java SE 中定义技术规范，是一个为应用程序、设备、系统等植入管理功能的框架，通过 JMX 可以远程监控 Tomcat 的运行状态；
Jasper：Tomcat 的 Jsp 解析引擎，用于将 Jsp 转换成 Java 文件，并编译成 class 文件。
Session：负责管理和创建session，以及 Session的持久化(可自定义)，支持 session 的集群。
Pipeline：在容器中充当管道的作用，管道中可以设置各种 valve(阀门)，请求和响应在经由管道中各个阀门处理，提供了一种灵活可配置的处理请求和响应的机制。
Naming：命名服务，JNDI， Java命名和目录接口，是一组在 Java应用中访问命名和目录服务的 API。命名服务将名称和对象联系起来，使得我们可以用名称访问对象，目录服务也是一种命名服务，对象不但有名称，还有属性。Tomcat中可以使用 JNDI 定义数据源、配置信息，用于开发与部署的分离

1.2.1 Connector组件

Connector组件是Tomcat中的两个核心组件之一，它的主要任务是负责接收浏览器发过来的TCP连接请求，创建一个Request和 Response对象分别用于和请求端交换数据。然后会产生一个线程来处理这个请求并把产生的Request和Response对象传给处理这个请求的线程，处理这个请求的线程就是Container组件要做的事了

在Tomcat 5中默认的Connector是Coyote，这个Connector是可以选择替换的。Connector最重要的功能就是接收连接请求，然后分配线程让Container来处理这个请求，所以这必然是多线程的，多线程的处理是Connector设计的核心。Tomcat 5将这个过程更加细化，它将Connector划分成Connector、Processor、Protocol，另外Coyote也定义自己的 Request 和 Response 对象

HttpConnector 的 Start 方法如下

public void start() throws LifecycleException   
{  if (started)  throw new LifecycleException(sm.getString ("httpConnector.alreadyStarted"));  threadName = "HttpConnector[" + port + "]";  lifecycle.fireLifecycleEvent(START_EVENT null);  started = true;  threadStart();  while (curProcessors < minProcessors)   {  if ((maxProcessors > 0) && (curProcessors >= maxProcessors))  break;  HttpProcessor processor = newProcessor〇;  recycle(processor);  }  
}

当执行到threadStart()方法时，就会进入等待请求的状态，直到一个新的请求到来才会激活它继续执行，这个激活是在HttpProcessor的assign方法中的，这个方法的代码如下

synchronized void assign(Socket socket){  while (available)   {  try   {  wait ();  }   catch (InterruptedException e)   {  }  }  this.socket = socket;  available = true;  notifyAll();  if ((debug >= 1) && (socket != null))  log(" An incoming request is being assigned");  
}

创建HttpProcessor对象时会把available设为false,所以当请求到来时不会进入while循环，将请求的Socket赋给当前处理的Socket,并将available设为true，当available没置为true时，HttpProcessor的run方法将被激活，接下来将会处理这次请求

public void run() {  while (!stopped)   {  Socket socket = await();  if (socket == null)  continue;  try   {  process(socket);  }   catch (Throwable t)   {  log("process.invoke", t);  }  connector.recycle(this);  }  synchronized (threadSync)   {  threadSync.notifyAll();  }  
}

解析Socket的过程在process方法中
当Connector将Socket连接封装成Request和Response对象后，接下来的事情就交给Container来处理了

1.2.2 Container组成

1.2.2.1 Container容器

Container是容器的父接口，所有子容器都必须实现这个接口，Container容器的设计用的是典型的责任链的设计模式，它由4个子容器组件构成，分别是Engine、Host、Context和Wrapper，这4个组件不是平行的，而是父子关系，Engine包含Host，Host包含Context,Context包含 Wrapper。通常一个 Servlet class 对应一个Wrapper，如果有多个 Servlet，则可以定义多个Wrapper;如果有多个Wrapper，则要定义一个更高的Container

Context还可以定义在父容器Host中，Host不是必需的，但是要运行war程序，就必须要用Host,因为在war中必有web.xml文件，这个文件的解析就需要Host。如果要有多个Host就要定义一个top容器Engine。而Engine没有父容器了，一个Engine代表一个完整的 Servlet引擎

如下是Container容器组成：
在这里插入图片描述
Container组成：

Engine：Servlet 的顶层容器，包含一个或多个 Host 子容器；
Host：虚拟主机，负责 web应用的部署和 Context 的创建；
Context：Web 应用上下文，包含多个Wrapper，负责 web 配置的解析、管理所有的 Web 资源；
Wrapper：最底层的容器，是对 Servlet 的封装，负责 Servlet 实例的创建、执行和销毁。

1.2.2.2 Container容器处理请求

当Connector接受一个连接请求时，会将请求交给Container，Container是如何处理这个请求的？这4个组件是怎么分工的？怎么把请求传给特定的子容器的？又是如何将最终的请求交给Servlet处理的
在这里插入图片描述
这里看到了 Valve，是不是很熟悉？没错，Valve的设计在其他框架中也有用到，同样Pipeline的原理基本上也是相似的。它是一个管道，Engine和 Host都会执行这个Pipeline，你可以在这个管道上增加任意的Valve，Tomcat会挨个执行这些Valve，而且4个组件都会有自己的一套 Valve集合。那么怎么才能定义自己的Valve呢？在server.xml文件中可以添加，如给Engine和Host增加一个Valve,代码如下

<Engine defaultHost="localhost" name="Catalina">  <Valve className="org.apache.catalina.valves.RequestDumperValven"/>  
.......  <Host appBase="webappsn autoDeploy="true" name="localhost" unpackWARs="true” xmlNamespaceAware="false" xmlValidation="false"〉  <Valve className=»org.apache.catalina.valves.FastCommonAccessLogValve" directory="logs" prefix="localhost_access_log. " suffix=".txt" pattern="common" resolveHosts="false"/>  
.......  </Host>  
</Engine>

StandardEngineValve、StandardHostValve 是 Engine 和 Host 默认的 Valve，最后一个Valve负责将请求传给它们的子容器，以继续往下执行。
前面是Engine和Host容器的请求过程，下面看Context和Wrapper容器是如何处理请求的
从Tomcat5开始，子容器的路由放在了request中，在request保存了当前请求正在处理的 Host、Context 和 Wrapper

1.2.2.3 Engine容器

Engine容器比较简单，它只定义了一些基本的关联关系
它的标准实现类是StandardEngine,注意Engine没有父容器，如果调用setParent方法将会报错
在这里插入图片描述
Engine容器接口常见方法：

String getDefaultHost()
void setDefaultHost(String defaultHost)
String getJvmRoute()
void setJvmRoute(String jvmRouteId)
String getService()
void setService(Service service)
void addDefaultContext(DefaultContext defaultContext)
DefaultContext getDefaultContext()
void importDefaultContext(Context context)

1.2.2.4 Host容器

Host是Engine的子容器，一*个Host在Engine中代表一个虚拟主机这个虚拟主机的作用就是运行多个应用，它负责安装和展开这些应用，并且标识这个应用以便能够区分它们。它的子容器通常是Context,它除了关联子容器外，还保存一个主机应有的信息
在这里插入图片描述

从图中可以看出，除了所有容器都继承的ContainerBase外，StandardHost还实现了Deployer接口，图11-12清楚地列出了这个接口的主要方法，这些方法都可以安装、展开、启动和结束每个Web应用
Deployer接口的实现是StandardHostDeployer,这个类实现了最主要的几个方法，Host可以调用这些方法完成应用的部署等

1.2.2.5 Context容器

Context代表Servlet的Context，它具备了 Servlet运行的基本环境，理论上只要有Context就能运行Servlet了。简单的Tomcat可以没有Engine和Host

Context最重要的功能就是管理它里面的Servlet实例，Servlet实例在Context中是以Wrapper出现的。还有一点就是 Context如何才能找到正确的Servlet来执行它呢？ Tomcat 5以前是通过一个Mapper类来管理的，在Tomcat5以后这个功能被移到了Request中，在前面的时序图中就可以发现获取子容器都是通过Request来分配的

主要作用是设置各种资源属性和管理组件，还有一个非常重要的作用就是启动子容器和Pipeline
我们知道Context的配置文件中有个reloadable属性，如下面的配置

<Context path="/library" 
docBase="D:\projects\library\deploy\target\library.war" 
reloadable="true" />

当这个reloadable设为true时，war被修改后Tomcat会自动重新加载这个应用。如何做到这点呢？这个功能是在StandardContext的backgroundProcess方法中实现的，这个方法的代码如下

public void backgroundProcess()   
{  if (!started)   return;  count = (count + 1) % managerChecksFrequency;  if ((getManager()   !=  null)   &&  (count  ==  0)){  try   {  getManager().backgroundProcess();  }   catch ( Exception x )   {  log.warn("Unable to perform background process on manager",x);  }  }  if (getLoader() !=  null)     {  if (reloadable && (getLoader().modified())){  try   {  Thread.currentThread().setContextClassLoader(StandardContext.class.getClassLoader());  reload();  } finally   {  if (getLoader() !=  null)   {  Thread.currentThread{).setContextClassLoader(getLoader().getClassLoader());  }  }  }  if (getLoader() instanceof WebappLoader)   {  ((WebappLoader) getLoader()).closeJARs(false);  }  }  
}

它会调用reload方法，而reload方法会先调用stop方法，然后再调用Start方法，完成Context的一次重新加载。可以看出，执行reload方法的条件是reloadable为true和应用被修改，那么这个backgroundProcess方法是怎么被调用的呢
这个方法是在ContainerBase类中定义的内部类ContainerBackgroundProcessor中被周期调用的，这个类运行在一个后台线程中。它会周期地执行run方法，它的nm方法会周期地调用所有容器的backgroundProcess方法，因为所有容器都会继承 ContainerBase类，所以所有容器都能够在backgroundProcess方法中定义周期执行的事件

1.2.2.6 Wrapper容器

Wrapper代表一个Servlet，它负责管理一个Servlet,包括Servlet的装载、初始化、执行及资源回收。Wrapper是最底层的容器，它没有子容器了，所以调用它的addChild将会报错。
Wrapper 的实现类是 StandardWrapper，StandardWrapper 还实现了拥有一个 Servlet 初始化信息的ServletConfig，由此看出StandardWrapper将直接和Servlet的各种信息打交道
它基本上描述了对Servlet的操作，装载了Servlet后就会调用Servlet的init方法，同时会传一个 StandardWrapperFacade对象给Servlet，这个对象包装了StandardWrapper，ServletConfig与它们的关系如下所示：
在这里插入图片描述
Servlet可以获得的信息都在StandardWrapperFacade里封装，这些信息又是在StandardWrapper对象中拿到的，所以Servlet可以通过ServletConfig拿到有限的容器的信息

当Servlet被初始化完成后，就等着StandardWrapperValue去调用它的Service方法了，调用Service方法之前要调用Servlet所有的filter

1.2.3 生命周期管理

生命周期管理 ：Tomcat为了方便管理组件和容器的生命周期，定义了从创建、启动、到停止、销毁共 12 中状态，tomcat生命周期管理了内部状态变化的规则控制，组件和容器只需实现相应的生命周期方法即可完成各生命周期内的操作(initInternal、startInternal、stopInternal、 destroyInternal)；

比如执行初始化操作时，会判断当前状态是否 New，如果不是则抛出生命周期异常；是的话则设置当前状态为 Initializing，并执行 initInternal 方法，由子类实现，方法执行成功则设置当前状态为 Initialized，执行失败则设置为 Failed 状态；
在这里插入图片描述
Tomcat 的生命周期管理引入了事件机制，在组件或容器的生命周期状态发生变化时会通知事件监听器，监听器通过判断事件的类型来进行相应的操作。事件监听器的添加可以在 server.xml 文件中进行配置;

Tomcat 各类容器的配置过程就是通过添加 listener 的方式来进行的，从而达到配置逻辑与容器的解耦。如 EngineConfig、HostConfig、ContextConfig。EngineConfig：主要打印启动和停止日志 HostConfig：主要处理部署应用，解析应用 META-INF/context.xml并创建应用的 Context
ContextConfig：主要解析并合并 web.xml，扫描应用的各类 web 资源 (filter、servlet、listener)
在这里插入图片描述

1.2.4 Tomcat 的启动过程

在这里插入图片描述

启动从 Tomcat 提供的 start.sh 脚本开始，shell 脚本会调用 Bootstrap 的 main 方法，实际调用了 Catalina 相应的 load、start 方法。

load 方法会通过 Digester进行 config/server.xml的解析，在解析的过程中会根据 xml 中的关系和配置信息来创建容器，并设置相关的属性。接着 Catalina 会调用 StandardServer 的 init 和 start 方法进行容器的初始化和启动。

按照 xml 的配置关系，server 的子元素是 service，service 的子元素是顶层容器 Engine，每层容器有持有自己的子容器，而这些元素都实现了生命周期管理的各个方法，因此就很容易的完成整个容器的启动、关闭等生命周期的管理。

StandardServer 完成 init 和 start 方法调用后，会一直监听来自 8005 端口(可配置)，如果接收到 shutdown 命令，则会退出循环监听，执行后续的 stop 和 destroy 方法，完成 Tomcat 容器的关闭。同时也会调用 JVM 的 Runtime.getRuntime().addShutdownHook 方法，在虚拟机意外退出的时候来关闭容器。

所有容器都是继承自 ContainerBase，基类中封装了容器中的重复工作，负责启动容器相关的组件 Loader、Logger、Manager、Cluster、Pipeline，启动子容器(线程池并发启动子容器，通过线程池 submit 多个线程，调用后返回 Future对象，线程内部启动子容器，接着调用 Future 对象的 get 方法来等待执行结果)。

List<Future<Void>> results = new ArrayList<Future<Void>>();
for (int i = 0; i < children.length; i++) {results.add(startStopExecutor.submit(new StartChild(children[i])));
}
boolean fail = false;
for (Future<Void> result ：results) {try {result.get();} catch (Exception e) {log.error(sm.getString("containerBase.threadedStartFailed")， e);fail = true;}
}

1.2.5 Web应用的部署方式

注：catalina.home：安装目录;catalina.base：工作目录;默认值 user.dir

Server.xml 配置 Host 元素，指定 appBase 属性，默认$catalina.base/webapps/
Server.xml配置 Context元素，指定 docBase，元素，指定 web 应用的路径
自定义配置：在$catalina.base/EngineName/HostName/XXX.xml配置 Context 元素

HostConfig 监听了 StandardHost 容器的事件，在 start方法中解析上述配置文件：

扫描 appbase 路径下的所有文件夹和 war 包，解析各个应用的 META-INF/context.xml，并创建 StandardContext，并将 Context加入到 Host 的子容器中。
解析$catalina.base/EngineName/HostName/下的所有Context配置，找到相应 web 应用的位置，解析各个应用的 META-INF/context.xml，并创建 StandardContext，并将 Context 加入到 Host 的子容器中。

注：

HostConfig 并没有实际解析 Context.xml，而是在 ContextConfig 中进行的。
HostConfig 中会定期检查 watched 资源文件(context.xml 配置文件)

ContextConfig 解析 context.xml 顺序：

先解析全局的配置 config/context.xml
然后解析 Host 的默认配置 EngineName/HostName/context.xml.default
最后解析应用的 META-INF/context.xml

ContextConfig 解析 web.xml 顺序：

先解析全局的配置 config/web.xml
然后解析 Host 的默认配置 EngineName/HostName/web.xml.default，接着解析应用的 MEB-INF/web.xml
扫描应用 WEB-INF/lib/下的 jar 文件，解析其中的 META-INF/web-fragment.xml 最后合并 xml 封装成 WebXml，并设置 Context

注：

扫描 web 应用和 jar 中的注解(Filter、Listener、Servlet)就是上述步骤中进行的。
容器的定期执行：backgroundProcess，由 ContainerBase 来实现的，并且只有在顶层容器中才会开启线程。(backgroundProcessorDelay=10 标志位来控制)

1.2.6 Servlet 生命周期

在这里插入图片描述

Servlet 是用 Java编写的服务器端程序。其主要功能在于交互式地浏览和修改数据，生成动态 Web 内容。
请求到达 server 端，server 根据 url映射到相应的 Servlet
判断 Servlet 实例是否存在，不存在则加载和实例化 Servlet 并调用 init 方法
Server 分别创建 Request 和 Response 对象，调用 Servlet 实例的 service 方法(service 方法内部会根据 http 请求方法类型调用相应的 doXXX 方法)
doXXX 方法内为业务逻辑实现，从 Request 对象获取请求参数，处理完毕之后将结果通过 response 对象返回给调用方
当 Server 不再需要 Servlet 时(一般当 Server 关闭时)，Server 调用 Servlet 的 destroy() 方法。

1.2.6.1 load on startup

当值为 0 或者大于 0 时，表示容器在应用启动时就加载这个 servlet; 当是一个负数时或者没有指定时，则指示容器在该 servlet 被选择时才加载; 正数的值越小，启动该 servlet 的优先级越高;

1.2.6.2 single thread model

每次访问 servlet，新建 servlet 实体对象，但并不能保证线程安全，同时 tomcat 会限制 servlet的实例数目最佳实践：不要使用该模型，servlet 中不要有全局变量

1.2.6.3 请求处理过程

在这里插入图片描述
根据 server.xml 配置的指定的 connector以及端口监听 http、或者 ajp 请求
请求到来时建立连接,解析请求参数,创建 Request 和 Response 对象,调用顶层容器 pipeline 的 invoke 方法
容器之间层层调用,最终调用业务 servlet 的 service 方法
Connector 将 response 流中的数据写到 socket 中

1.2.6.4 Pipeline 与 Valve

在这里插入图片描述

Pipeline 可以理解为现实中的管道,Valve 为管道中的阀门,Request和 Response 对象在管道中经过各个阀门的处理和控制。

每个容器的管道中都有一个必不可少的 basic valve,其他的都是可选的,basic valve 在管道中最后调用,同时负责调用子容器的第一个 valve。

Valve 中主要的三个方法:setNext、getNext、invoke;valve 之间的关系是单向链式结构,本身 invoke 方法中会调用下一个 valve 的 invoke 方法。

各层容器对应的 basic valve 分别是 StandardEngineValve、StandardHostValve、 StandardContextValve、StandardWrapperValve。

1.2.6.5 相关源码

Lifecycle接口的方法的实现都在其他组件中，就像前面说的，组件的生命周期由包含它的父组件控制，所以它的Start方法自然就是调用它下面的组件的Start方法，Stop方法也是一样。如在Server中Start方法就会调用Service组件的Start方法，Server的Start方法代码如下

public void start() throws LifecycleException   
{  if (started)   {  log.debug (sm.getString("standardServer.start.started"));  return;  }  lifecycle.fireLifecycleEvent{BEFORE_START_EVENT, null);  lifecycle.fireLifecycleEvent{START_EVENTr null);  started = true;  synchronized (services)   {  for (int i = 0; i < services.length; i++)      {  if (services[i] instanceof Lifecycle)  ((Lifecycle) services[i]).start();  }  }  lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);  
}

监听的代码会包围Service组件的启动过程，即简单地循环启动所有Service组件的Start方法，但是所有的Service必须要实现Lifecycle接口，这样做会更加灵活

stop方法如下：

public void stop() throws LifecycleException   
{  if (!started)  return;  lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENTf null);  lifecycle.fireLifecycleEvent(STOP_£VENT, null);  started = false;  for (int i = 0; i < services.length; i++)      {  if (services[i] instanceof Lifecycle)  ((Lifecycle) services[i]).stop();  }  lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);  
}

1.3 JSP引擎

在这里插入图片描述

1.3.1 JSP 生命周期

编译阶段:servlet 容器编译 servlet源文件,生成 servlet 类
初始化阶段:加载与 JSP 对应的 servlet 类, 创建其实例,并调用它的初始化方法
执行阶段:调用与 JSP 对应的 servlet 实例的服务方法
销毁阶段:调用与 JSP 对应的 servlet 实例的销毁方法,然后销毁 servlet实例

1.3.2 JSP元素

JSP元素代码片段：

<% 代码片段 %> 
JSP声明： <%! declaration; [ declaration; ]+ ... %> 
JSP表达式：<%= 表达式 %> 
JSP注释： <%-- 注释 --%> 
JSP指令：   <%@ directive attribute=“value” %> 
JSP行为：   <jsp:action_name attribute=“value” /> 
HTML元素：html/head/body/div/p/… 
JSP隐式对象：request、response、out、session、application、config、 pageContext、page、Exception

JSP 元素说明

代码片段:包含任意量的 Java 语句、变量、方法或表达式;
JSP 声明:一个声明语句可以声明一个或多个变量、方法,供后面的 Java 代码使用;
JSP 表达式:输出Java 表达式的值,String 形式;
JSP 注释:为代码作注释以及将某段代码注释掉
JSP 指令:用来设置与整个 JSP 页面相关的属性, <%@ page … %>定义页面的依赖属性,比如 language、contentType、errorPage、 isErrorPage、import、isThreadSafe、session 等等 <%@ include … %>包含其他的 JSP 文件、HTML 文件或文本文件,是该 JSP 文件的一部分,会被同时编译执行 <%@ taglib … %>引入标签库的定义,可以是自定义标签 JSP 行为:jsp:include、jsp:useBean、jsp:setProperty、jsp:getProperty、jsp:forward

1.3.3 Jsp 解析过程

在这里插入图片描述

代码片段:在_jspService()方法内直接输出
JSP 声明: 在 servlet 类中进行输出
JSP 表达式:在_jspService()方法内直接输出
JSP 注释:直接忽略,不输出
JSP 指令:根据不同指令进行区分,include:对引入的文件进行解析;page相关的属性会做为 JSP 的属性,影响的是解析和请求处理时的行为
JSP 行为:不同的行为有不同的处理方式,jsp:useBean 为例,会从 pageContext 根据 scope 的类别获取 bean 对象,如果没有会创建 bean,同时存到相应 scope 的 pageContext 中
HTML:在_jspService()方法内直接输出
JSP隐式对象:在_jspService()方法会进行声明,只能在方法中使用;

1.4 Connector

在这里插入图片描述

Http:HTTP 是超文本传输协议,是客户端浏览器或其他程序与 Web 服务器之间的应用层通信协议
AJP:Apache JServ协议(AJP)是一种二进制协议,专门代理从 Web 服务器到位于后端的应用程序服务器的入站请求

阻塞 IO

在这里插入图片描述

1.4.1 IO相关

非阻塞 IO
在这里插入图片描述

IO多路复用
在这里插入图片描述

阻塞与非阻塞的区别在于进行读操作和写操作的系统调用时，如果此时内核态没有数据可读或者没有缓冲空间可写时，是否阻塞。
IO多路复用的好处在于可同时监听多个socket的可读和可写事件，这样就能使得应用可以同时监听多个socket，释放了应用线程资源。

1.4.2 Tomcat各类Connector对比

在这里插入图片描述

表格中字段含义说明：

Support Polling：是否支持基于IO多路复用的socket事件轮询
Polling Size：轮询的最大连接数
Wait for next Request：在等待下一个请求时，处理线程是否释放，BIO是没有释放的，所以在keep-alive=true的情况下处理的并发连接数有限
Read Request Headers：由于request header数据较少，可以由容器提前解析完毕，不需要阻塞
Read Request Body：读取request body的数据是应用业务逻辑的事情，同时Servlet的限制，是需要阻塞读取的
Write Response：跟读取request body的逻辑类似，同样需要阻塞写

Connector的实现模式有三种，分别是BIO、NIO、APR，可以在server.xml中指定。

JIO：用java.io编写的TCP模块，阻塞IO
NIO：用java.nio编写的TCP模块，非阻塞IO，（IO多路复用）
APR：全称Apache Portable Runtime，使用JNI的方式来进行读取文件以及进行网络传输
Apache Portable Runtime是一个高度可移植的库，它是Apache HTTP Server 2.x的核心。APR具有许多用途，包括访问高级IO功能（如sendfile，epoll和OpenSSL），操作系统级功能（随机数生成，系统状态等）和本地进程处理（共享内存，NT管道和Unix套接字）。

1.4.3 NIO处理相关类

在这里插入图片描述
Acceptor线程负责接收连接，调用accept方法阻塞接收建立的连接，并对socket进行封装成PollerEvent，指定注册的事件为op_read，并放入到EventQueue队列中，PollerEvent的run方法逻辑的是将Selector注册到socket的指定事件；

Poller线程从EventQueue获取PollerEvent，并执行PollerEvent的run方法，调用Selector的select方法，如果有可读的Socket则创建Http11NioProcessor，放入到线程池中执行；

CoyoteAdapter是Connector到Container的适配器，Http11NioProcessor调用其提供的service方法，内部创建Request和Response对象，并调用最顶层容器的Pipeline中的第一个Valve的invoke方法

Mapper主要处理http url 到servlet的映射规则的解析，对外提供map方法

NIO Connector主要参数
在这里插入图片描述

1.4.4 Comet

Comet是一种用于web的推送技术，能使服务器实时地将更新的信息传送到客户端，而无须客户端发出请求在WebSocket出来之前，如果不使用comet，只能通过浏览器端轮询Server来模拟实现服务器端推送。Comet支持servlet异步处理IO，当连接上数据可读时触发事件，并异步写数据(阻塞)
在这里插入图片描述

Tomcat要实现Comet，只需继承HttpServlet同时，实现CometProcessor接口

Begin：新的请求连接接入调用，可进行与Request和Response相关的对象初始化操作，并保存response对象，用于后续写入数据
Read：请求连接有数据可读时调用
End：当数据可用时，如果读取到文件结束或者response被关闭时则被调用
Error：在连接上发生异常时调用，数据读取异常、连接断开、处理异常、socket超时

注意：

Read：在post请求有数据，但在begin事件中没有处理，则会调用read，如果read没有读取数据，在会触发Error回调，关闭socket
End：当socket超时，并且response被关闭时也会调用；server被关闭时调用
Error：除了socket超时不会关闭socket，其他都会关闭socket
End和Error时间触发时应关闭当前comet会话，即调用CometEvent的close方法，在事件触发时要做好线程安全的操作