Tomcat核心知识梳理(Tomcat体系结构、Tomcat类加载机制剖析、Jvm类加载机制剖析)

最新推荐文章于 2024-04-04 13:47:14 发布

Crazy Code Farmer

最新推荐文章于 2024-04-04 13:47:14 发布

阅读量222

点赞数

分类专栏：项目部署与运维文章标签： tomcat

本文链接：https://blog.csdn.net/illovesoftware/article/details/118884980

版权

项目部署与运维专栏收录该内容

10 篇文章 0 订阅

订阅专栏

找到Tomcat安装路径下的Server.xml看到tomcat中的内部结构(去掉杂余注释更清晰，如下代码)

Tomcat体系结构

概要

Tomcat是⼀个Http服务器（能够接收并且处理http请求，所以tomcat是⼀个http服务器）我们使⽤浏览器向某⼀个⽹站发起请求，发出的是Http请求，那么在远程，Http服务器接收到这个请求之后，会调⽤具体的程序（Java类）进⾏处理，往往不同的请求由不同的Java类完成处理。

Tomcat体系结构结构概念如下:

Server

一个 Tomcat 代表一个 Server 服务器.

Engine

Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理。

Host

代表一个Virtual Host，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配每个虚拟主机下都可以部署(deploy)一个或者多个Web App，每个Web App对应于一个Context，有一个Context path当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理匹配的方法是“最长匹配”，所以一个path==”"的Context将成为该Host的默认Context所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配。

Connector

连接器负责将各种网络协议封装起来，对外部屏蔽了网络连接与 IO 处理的细节，将处理得到的 Request 对象传递给容器处理，Tomcat 将处理请求的细节封装到 ProtocolHandler。在 Tomcat 中一共设计了 4 种容器，它们分别为 Engine、Host、Context、Wrapper

Context

一个Context对应于一个Web Application，一个WebApplication由一个或者多个Servlet组成 Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml载入Servlet类，当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类。如果找到，则执行该类，获得请求的回应，并返回。

Wrapper

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

找到Tomcat安装路径下的Server.xml看到tomcat中的内部结构(去掉杂余注释更清晰，如下代码)

</Host>

</Engine>

</Service>

</Server>

Tomcat类加载机制剖析

java类（.java）—> 字节码⽂件(.class) —> 字节码⽂件需要被加载到jvm内存当中（这个过程就是⼀个类加载的过程）类加载器（ClassLoader，说⽩了也是⼀个类，jvm启动的时候先把类加载器读取到内存当中去，其他的类（⽐如各种jar中的字节码⽂件，⾃⼰开发的代码编译之后的.class⽂件等等））要说 Tomcat 的类加载机制，⾸先需要来看看 Jvm 的类加载机制，因为 Tomcat 类加载机制是在 Jvm 类加载机制基础之上进⾏了⼀些变动。

JVM 的类加载机制

JVM 的类加载机制中有⼀个⾮常重要的⻆⾊叫做类加载器（ClassLoader），类加载器有⾃⼰的体系，Jvm内置了⼏种类加载器，包括：引导类加载器、扩展类加载器、系统类加载器，他们之间形成⽗⼦关系，通过 Parent 属性来定义这种关系，最终可以形成树形结构。

类加载器

引导启动类加载器

BootstrapClassLoader

c++编写，加载java核⼼库 java.*,⽐如rt.jar中的类，构

造ExtClassLoader和AppClassLoader

扩展类加载器 ExtClassLoader

java编写，加载扩展库 JAVA_HOME/lib/ext⽬录下的jar

中的类，如classpath中的jre ，javax.*或者java.ext.dir

指定位置中的类

系统类加载器

SystemClassLoader/AppClassLoade

默认的类加载器，搜索环境变量 classpath 中指明的路

径

另外：⽤户可以⾃定义类加载器（Java编写，⽤户⾃定义的类加载器，可加载指定路径的 class ⽂件）

当 JVM 运⾏过程中，⽤户⾃定义了类加载器去加载某些类时，会按照下⾯的步骤（⽗类委托机制）

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

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

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

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

双亲委派机制

什么是双亲委派机制

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

双亲委派机制的作⽤

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

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

Object类 -----> ⾃定义类加载器（会出现问题的，那么真正的Object类就可能被篡改了）