Tomcat相关知识总结（仅仅会打包发布可不够）

时间：2023-06-29 09:09:01 | 来源：网站运营

时间：2023-06-29 09:09:01 来源：网站运营

Tomcat相关知识总结（仅仅会打包发布可不够）：前言

Tomcat想必大家都不陌生，接触得最多的就是他了，但是对于他的认知，很多人估计都是停留在把项目打成war包，扔在webapp目录下面，然后启动完事，本篇文章基于拉勾的Tomcat课程所做的个人笔记，从外到内真正认识一下Tomcat，内容包含访问流程、总体架构、两大组件解析、核心配置标签解析、启动流程、请求流程、Tomcat调优等等，希望对大家有所帮助。

一、 Tomcat系统架构和原理剖析

浏览器访问服务器的流程

浏览器访问服务器使⽤的是Http协议，Http是应⽤层协议，⽤于定义数据通信的格式，具体的数据传输使⽤的是TCP/IP协议。

Tomcat 系统总体架构

Tomcat的两个身份：

1）http服务器

2）Tomcat是⼀个Servlet容器

Tomcat是⼀个Http服务器，HTTP 服务器接收到请求之后把请求交给Servlet容器来处理，Servlet 容器通过Servlet接⼝调⽤业务类，避免tomcat和业务类耦合在一起。Servlet接⼝和Servlet容器这⼀整套内容就是Servlet规范。

Tomcat Servlet容器处理流程：

1）HTTP服务器会把请求信息使⽤ServletRequest对象封装起来

2）进⼀步去调⽤Servlet容器中某个具体的Servlet

3）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）来干上面的两个事情

连接器，负责对外交流： 处理Socket连接，负责⽹络字节流与Request和Response对象的转化

容器，负责内部处理：加载和管理Servlet，以及具体处理Request请求

Tomcat 两大组件之连接器组件 Coyote

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

（1）Coyote 封装了底层的⽹络通信（Socket 请求及响应处理）

（2）Coyote 使Catalina 容器（Container容器组件）与具体的请求协议及IO操作⽅式完全解 耦

（3）Coyote 将Socket 输⼊转换封装为 Request 对象，进⼀步封装后交由Catalina 容器进⾏处理，处理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流。

（4）Coyote 负责的是具体协议（应⽤层）和IO（传输层）相关内容







注意： 8.0 之前 ，Tomcat 默认采⽤的I/O⽅式为 BIO，之后改为 NIO。 ⽆论 NIO、NIO2 还是 APR， 在性能⽅⾯均优于以往的BIO。 如果采⽤APR， 甚⾄可以达到 Apache HTTP Server 的影响性能。

Coyote 的内部组件及流程

Tomcat 两大组件之Servlet容器组件Catalina

Tomcat是由⼀系列可配置（conf/server.xml）的组件构成的Web容器，⽽Catalina是Tomcat的servlet容器。

Tomcat 本质上就是⼀款 Servlet 容器， 因此Catalina 才是 Tomcat 的核⼼ ， 其他模块都是为Catalina 提供⽀撑的。 ⽐如 ： 通过 Coyote 模块提供链接通信，Jasper 模块提供 JSP 引擎，Naming 提供JNDI 服务，Juli 提供⽇志服务。




整个Tomcat就是⼀个Catalina实例，一个Catalina实例有一个Server实例，一个Server实例可以有多个Service实例, 每⼀个Service实例下可以有多个Connector实例和⼀个Container实例。




Catalina

负责解析Tomcat的配置⽂件（server.xml） , 以此来创建服务器Server组件并进⾏管理

Server

服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝，提供了⼀种优雅的启动和关闭整个系统的⽅式

Service

服务是Server内部的组件，⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个

Container

Container容器，负责处理⽤户的servlet请求，并返回对象给web⽤户的模块

Container组件下有四种具体的组件，分别是Engine、Host、Context和Wrapper，他们是层级关系。

Engine：表示整个Catalina的Servlet引擎，⽤来管理多个虚拟站点，⼀个Service最多只能有⼀个Engine，但是⼀个引擎可包含多个Host。

Host：代表⼀个虚拟主机，或者说⼀个站点，可以给Tomcat配置多个虚拟主机地址，⽽⼀个虚拟主机下可包含多个Context。

Context：表示⼀个Web应⽤程序， ⼀个Web应⽤可包含多个Wrapper。

Wrapper：表示⼀个Servlet，Wrapper 作为容器中的最底层，不能包含⼦容器。

Tomcat 服务器核⼼配置Server标签

Tomcat 服务器核⼼配置Service标签

Tomcat 服务器核⼼配置Executor标签

Tomcat 服务器核⼼配置Connector标签

Connector 标签⽤于创建链接器实例默认情况下，server.xml 配置了两个链接器，⼀个⽀持HTTP协议，⼀个⽀持AJP协议

⼤多数情况下，我们并不需要新增链接器配置，只是根据需要对已有链接器进⾏优化.




共享线程池:配置共享线程池，多个connector共用，节约资源。

Tomcat 服务器核⼼配置Engine标签

Engine 表示 Servlet 引擎

Tomcat 服务器核⼼配置Host标签

Tomcat 服务器核⼼配置Context标签

二、手写实现Tomcat服务器与源码剖析

手写实现Tomcat服务器需求及实现步骤

1）提供服务，接收请求（Socket通信）

2）请求信息封装成Request对象（Response对象）

3）客户端请求资源，资源分为静态资源（html）和动态资源（Servlet）

4）资源返回给客户端浏览器

1. 创建一个启动类Bootstrap，通过main方法调用启动start方法







2. 通过dom4j加载解析web.xml存入map集合中，此map存储的是地址和自定义的HttpServlet类




3. 定义端口号，创建一个ServerSocket，通过accept获取Socket类,把Socket和map集合传入多线程处理类。




4. 通过Socket获取输入流封装Request对象




5. 通过Socket获取输出流封装Response对象。

6. 根据请求查询map集合是否为空判断静态资源，静态资源处理

7. 动态资源处理，调用自定义的LgServlet继承HttpServlet重写doGet和doPost进行输出

8. 关闭socket，获取已经创建好的多线程类，放入调用定义线程池threadPoolExecutor中调用execute执行。

Tomcat启动流程

从脚本start.sh找到Bootstap类的main方法从父容器开始把组件一个个初始化再逐级启动

Tomcat请求流程

请求处理流程分析图




Mapper组件体系结构




请求处理流程示意图

三、Tomcat类加载机制剖析

类加载过程：Java类（.java）文件被编译成字节码文件（.class），然后通过类加载器（classloader）加载到jvm内存中。

JVM类加载机制

Jvm内置了⼏种类加载器，包括：引导类加载器、扩展类加载器、系统类加载器，他们之间形成⽗⼦关系，通过 Parent 属性来定义这种关系，最终可以形成树形结构，同时我们自己也可以自定义类加载器。







⽤户可以⾃定义类加载器（Java编写，⽤户⾃定义的类加载器，可加载指定路径的 class ⽂件）当 JVM 运⾏过程中，⽤户⾃定义了类加载器去加载某些类时，会按照下⾯的步骤（⽗类委托机制）

1） ⽤户⾃⼰的类加载器，把加载请求传给⽗加载器，⽗加载器再传给其⽗加载器，⼀直到加载器树的顶层

2 ）最顶层的类加载器⾸先针对其特定的位置加载，如果加载不到就转交给⼦类

3 ）如果⼀直到底层的类加载都没有加载到，那么就会抛出异常 ClassNotFoundException

因此，按照这个过程可以想到，如果同样在 classpath 指定的⽬录中和⾃⼰⼯作⽬录中存放相同的class，会优先加载 classpath ⽬录中的⽂件。

JVM双亲委派机制

当某个类加载器需要加载某个.class⽂件时，它⾸先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，⾃⼰才会去加载这个类。

作用：

防⽌重复加载同⼀个.class。通过委托去向上⾯问⼀问，加载过了，就不⽤再加载⼀遍。保证数据安全。

保证核⼼.class不能被篡改。通过委托⽅式，不会去篡改核⼼.class，即使篡改也不会去加载，即使加载也不会是同⼀个.class对象了。不同的加载器加载同⼀个.class也不是同⼀个.class对象。这样保证了class执⾏安全（如果⼦类加载器先加载，那么我们可以写⼀些与java.lang包中基础类同名的类， 然后再定义⼀个⼦类加载器，这样整个应⽤使⽤的基础类就都变成我们⾃⼰定义的类了）。

Tomcat类加载机制

Tomcat 的类加载机制相对于 Jvm 的类加载机制做了⼀些改变，因为如果同时存在两个应用，然后他们有相同的全限定类名，如果遵循双亲委派机制，tomcat加载了应用1的全限定类之后就不会再加载应用2的类，但是这两个类虽然全限定类名相同，里面的逻辑却是不同的，所以JVM的双亲委派机制就不适合Tomcat了。因此在原来Jvm类加载机制上做了扩展和改变。增加了Commons、Catalina、Shared、WebApp类加载器。







引导类加载器 和 扩展类加载器 的作⽤不变。

系统类加载器正常情况下加载的是 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 下的类。

加载顺序：

⾸先从 Bootstrap Classloader加载指定的类->

如果未加载到，则从 /WEB-INF/classes加载->

如果未加载到，则从 /WEB-INF/lib/*.jar 加载->

如果未加载到，则依次从 System、Common、Shared 加载（在这最后⼀步，遵从双亲委派机制）

四、Tomcat 对 Https 的支持及 Tomcat 性能优化策略

Tomcat 对 HTTPS 的支持

Https是⽤来加强数据传输安全的。Http超⽂本传输协议，明⽂传输 ，传输不安全，https在传输数据的时候会对数据进⾏加密，也就是在http的基础上增加了ssl协议。

HTTPS和HTTP的主要区别：

HTTPS协议使⽤时需要到电⼦商务认证授权机构（CA）申请SSL证书。

HTTP默认使⽤8080端⼝，HTTPS默认使⽤8443端⼝。

HTTPS则是具有SSL加密的安全性传输协议，对数据的传输进⾏加密，效果上相当于HTTP的升级版。

HTTP的连接是⽆状态的，不安全的；HTTPS协议是由SSL+HTTP协议构建的可进⾏加密传输、身份认证的⽹络协议，⽐HTTP协议安全。

HTTPS⼯作原理：




使用：生成秘钥库文件xx.keystore，把绝对路径地址配置到conf/server.xml即可。

JVM内存调优

系统性能的衡量指标，主要是响应时间和吞吐量。

1）响应时间：执行某个操作的耗时；

2) 吞吐量：系统在给定时间内能够⽀持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，⼀个事务是指⼀个客户机向服务器发送请求然后服务器做出反应的过程。

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

1）内存直接影响服务的运⾏效率和吞吐量

2）垃圾回收机制会不同程度地导致程序运⾏中断（垃圾回收策略不同，垃圾回收次数和回收效率都是不同的）




JVM内存模型




使用：配置在catalina.sh的脚本

JVM垃圾收集策略

垃圾回收性能指标

吞吐量：⼯作时间（排除GC时间）占总时间的百分⽐， ⼯作时间并不仅是程序运⾏的时间，还包含内存分配时间。

暂停时间：由垃圾回收导致的应⽤程序停⽌响应次数/时间。

垃圾收集器：

串⾏收集器（Serial Collector）

单线程执⾏所有的垃圾回收⼯作， 适⽤于单核CPU服务器⼯作进程-----|（单线程）垃圾回收线程进⾏垃圾收集|---⼯作进程继续

并⾏收集器（Parallel Collector）

⼯作进程-----|（多线程）垃圾回收线程进⾏垃圾收集|---⼯作进程继续⼜称为吞吐量收集器（关注吞吐量）， 以并⾏的⽅式执⾏年轻代的垃圾回收， 该⽅式可以显著降低垃圾回收的开销(指多条垃圾收集线程并⾏⼯作，但此时⽤户线程仍然处于等待状态)。适⽤于多处理器或多线程硬件上运⾏的数据量较⼤的应⽤

并发收集器（Concurrent Collector）

以并发的⽅式执⾏⼤部分垃圾回收⼯作，以缩短垃圾回收的暂停时间。适⽤于那些响应时间优先于吞吐量的应⽤， 因为该收集器虽然最⼩化了暂停时间(指⽤户线程与垃圾收集线程同时执⾏,但不⼀定是并⾏的，可能会交替进⾏)， 但是会降低应⽤程序的性能

CMS收集器（Concurrent Mark Sweep Collector）

并发标记清除收集器， 适⽤于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应⽤

G1收集器（Garbage-First Garbage Collector）

适⽤于⼤容量内存的多核服务器， 可以在满⾜垃圾回收暂停时间⽬标的同时， 以最⼤可能性实现⾼吞吐量(JDK1.7之后)

垃圾回收器参数：




使用：配置在catalina.sh的脚本

Tomcat调优

Tomcat优化从两个⽅⾯进⾏

1）JVM虚拟机优化（优化内存模型）

2）Tomcat⾃身配置的优化（⽐如是否使⽤了共享线程池？IO模型？）

优化一调整线程池




优化二调整tomcat的连接器：调整tomcat/conf/server.xml 中关于链接器的配置可以提升应⽤服务器的性能。




优化三禁用 AJP 连接器




优化四调整 IO 模式

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




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

优化五动静分离

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