Tomcat学习笔记

第⼀部分：Tomcat 系统架构与原理剖析

1.1 浏览器访问服务器的流程

1.2 Tomcat 系统总体架构

HTTP 服务器接收到请求之后把请求交给Servlet容器来处理， Servlet 容器通过Servlet接⼝调⽤业务
类。 Servlet接⼝和Servlet容器这⼀整套内容叫作Servlet规范。

Tomcat的两个重要身份
1） http服务器
2） Tomcat是⼀个Servlet容器

1.2.1 Tomcat Servlet容器处理流程

当⽤户请求某个URL资源时
1） HTTP服务器会把请求信息使⽤ServletRequest对象封装起来
2）进⼀步去调⽤Servlet容器中某个具体的Servlet
3）在 2）中， Servlet容器拿到请求后，根据URL和Servlet的映射关系，找到相应的Servlet
4）如果Servlet还没有被加载，就⽤反射机制创建这个Servlet，并调⽤Servlet的init⽅法来完成初始化
5）接着调⽤这个具体Servlet的service⽅法来处理请求，请求处理结果使⽤ServletResponse对象封装
6）把ServletResponse对象返回给HTTP服务器， HTTP服务器会把响应发送给客户端

我们发现tomcat有两个⾮常重要的功能需要完成
1）和客户端浏览器进⾏交互，进⾏socket通信，将字节流和Request/Response等对象进⾏转换
2） Servlet容器处理业务逻辑

Tomcat 设计了两个核⼼组件连接器（Connector） 和容器（Container） 来完成 Tomcat 的两⼤核⼼
功能。
连接器：负责对外交流： 处理Socket连接，负责⽹络字节流与Request和Response对象的转化；
容器：负责内部处理： 加载和管理Servlet，以及具体处理Request请求；

1.2.2 连接器组件 Coyote

客户端通过Coyote与服务器建⽴连接、发送请求并接受响应。

（1） Coyote 封装了底层的⽹络通信（Socket 请求及响应处理）
（2） Coyote 使Catalina 容器（容器组件）与具体的请求协议及IO操作⽅式完全解耦
（3） Coyote 将Socket 输⼊转换封装为 Request 对象，进⼀步封装后交由Catalina 容器进⾏处理，处
理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流
（4） Coyote 负责的是具体协议（应⽤层）和IO（传输层）相关内容

Coyote内部又包含了很多支撑组件

1.2.3 容器组件Catalina

Tomcat就是⼀个Catalina的实例，因为Catalina是Tomcat的核⼼。

• Catalina
  负责解析Tomcat的配置⽂件（server.xml） , 以此来创建服务器Server组件并进⾏管理
• Server
  服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlaet引擎,Tomcat连接
  器。 Server通过实现Lifecycle接⼝，提供了⼀种优雅的启动和关闭整个系统的⽅式
• Service
  服务是Server内部的组件，⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个
  Container
• Container
  容器，负责处理⽤户的servlet请求，并返回对象给web⽤户的模块
• Engine
  表示整个Catalina的Servlet引擎，⽤来管理多个虚拟站点，⼀个Service最多只能有⼀个Engine，
  但是⼀个引擎可包含多个Host
• Host
• 代表⼀个虚拟主机，或者说⼀个站点，可以给Tomcat配置多个虚拟主机地址，⽽⼀个虚拟主机下
  可包含多个Context
• Context
  表示⼀个Web应⽤程序， ⼀个Web应⽤可包含多个Wrapper
• Wrapper
  表示⼀个Servlet， Wrapper 作为容器中的最底层，不能包含⼦容器
  上述组件的配置其实就体现在conf/server.xml中。

第二部分：⼿写实现迷你版 Tomcat

Minicat要做的事情：作为⼀个服务器软件提供服务的，也即我们可以通过浏览器客户端发送http请求，
Minicat可以接收到请求进⾏处理，处理之后的结果可以返回浏览器客户端。
1）提供服务，接收请求（Socket通信）
2）请求信息封装成Request对象（Response对象）
3）客户端请求资源，资源分为静态资源（html）和动态资源（Servlet）
4）资源返回给客户端浏览器

第三部分：核⼼流程源码剖析

3.1 Tomcat启动流程

3.3 Tomcat请求处理流程

请求处理流程分析

请求处理流程示意图

根据url寻找对应的servlet，需要按照Host->Context->Wrapper->Servlet的顺序一步一步定位。

而tomcat通过Mapper组件来保存Host、Context、Wrapper之间的关系

第四部分：Tomcat 类加载机制剖析

Tomcat类加载器没有严格的遵从双亲委派机制，也可以说打破了双亲委派机制

因为如下情况：

有⼀个tomcat， webapps下部署了两个应⽤
app1/lib/a-1.0.jar com.lagou.edu.Abc
app2/lib/a-2.0.jar com.lagou.edu.Abc
不同版本中Abc类的内容是不同的，代码是不⼀样的

按照双亲委派机制加载会出现有的应用中需要的类不被加载！

• 引导类加载器 和 扩展类加载器 的作⽤不变
• 系统类加载器正常情况下加载的是 CLASSPATH 下的类，但是 Tomcat 的启动脚本并未使⽤该变
  量，⽽是加载tomcat启动的类，⽐如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。
  位于CATALINA_HOME/bin下
• Common 通⽤类加载器加载Tomcat使⽤以及应⽤通⽤的⼀些类，位于CATALINA_HOME/lib下，
  ⽐如servlet-api.jar
• Catalina ClassLoader ⽤于加载服务器内部可⻅类，这些类应⽤程序不能访问
• Shared ClassLoader ⽤于加载应⽤程序共享类，这些类服务器不会依赖
• Webapp ClassLoader，每个应⽤程序都会有⼀个独⼀⽆⼆的Webapp ClassLoader，他⽤来加载
  本应⽤程序 /WEB-INF/classes 和 /WEB-INF/lib 下的

1、⾸先从 Bootstrap Classloader加载指定的类
2、如果未加载到，则从 /WEB-INF/classes加载
3、如果未加载到，则从 /WEB-INF/lib/*.jar 加载

4、如果未加载到，则依次从 System、 Common、 Shared 加载

第五部分：Tomcat 性能优化

Tomcat优化从两个⽅⾯进⾏
1） JVM虚拟机优化（优化内存模型）
2） Tomcat⾃身配置的优化（⽐如是否使⽤了共享线程池？ IO模型？）

5.1 虚拟机运⾏优化（参数调整）

Java 虚拟机的运⾏优化主要是内存分配和垃圾回收策略的优化：

• 内存直接影响服务的运⾏效率和吞吐量
• 垃圾回收机制会不同程度地导致程序运⾏中断（垃圾回收策略不同，垃圾回收次数和回收效率都是
  不同的）
  

使用jhsdb map --heap --pid 8481查看

2） 垃圾回收（GC）策略jvm内存配置

垃圾回收性能指标

• 吞吐量：⼯作时间（排除GC时间）占总时间的百分⽐， ⼯作时间并不仅是程序运⾏的时间，还包
  含内存分配时间。
• 暂停时间：由垃圾回收导致的应⽤程序停⽌响应次数/时间。

上述配置的更改在bin/catalina.sh的脚本中 , 追加对应的配置重启tomcat即可。

5.2 Tomcat 配置调优

调整tomcat线程池

使用共享线程池

调整tomcat的连接器

禁⽤ AJP 连接器

调整 IO 模型

Tomcat8之前的版本默认使⽤BIO（阻塞式IO），对于每⼀个请求都要创建⼀个线程来处理，不适
合⾼并发； Tomcat8以后的版本默认使⽤NIO模式（⾮阻塞式IO）

修改protocl属性为对应的协议IO模型的全路径名即可，如protocol=org.apache.coyote.http11.Http11Nio2Protocol

当Tomcat并发性能有较⾼要求或者出现瓶颈时，我们可以尝试使⽤APR模式， APR（Apache Portable
Runtime）是从操作系统级别解决异步IO问题，使⽤时需要在操作系统上安装APR和Native（因为APR
原理是使⽤使⽤JNI技术调⽤操作系统底层的IO接⼝）

动静分离

可以使⽤Nginx+Tomcat相结合的部署⽅案， Nginx负责静态资源访问， Tomcat负责Jsp等动态资
源访问处理（因为Tomcat不擅⻓处理静态资源）。