![8f32a181eba8f0543c763ba9db04b5a8.png](https://img-blog.csdnimg.cn/img_convert/8f32a181eba8f0543c763ba9db04b5a8.png)
Apache Tomcat Web应⽤服务器学习笔记
浏览器访问服务器的流程
http请求的处理过程:
![aae011312b43f5a07358c38b317c2ffa.png](https://img-blog.csdnimg.cn/img_convert/aae011312b43f5a07358c38b317c2ffa.png)
浏览器访问服务器使⽤的是Http协议,Http是应⽤层协议,⽤于定义数据通信的格式,具体的数据传输使⽤的是TCP/IP协议。
Tomcat 系统总体架构
Tomcat是⼀个Http服务器(能够接收并且处理http请求,所以tomcat是⼀个http服务器),tomcat是Apache旗下的一个开源Servlet的容器,实现了对Servlet和JSP技术支持。相同的服务器软件还有WebSphere、weblogic。
我们使⽤浏览器向某⼀个⽹站发起请求,发出的是Http请求,那么在远程,Http服务器接收到这个请求之后,会调⽤具体的程序(Java类)进⾏处理,往往不同的请求由不同的Java类完成处理。
![62b8c9ac173f20b71e9b036c0dbd53ad.png](https://img-blog.csdnimg.cn/img_convert/62b8c9ac173f20b71e9b036c0dbd53ad.png)
HTTP 服务器接收到请求之后把请求交给Servlet容器来处理,Servlet 容器通过Servlet接⼝调⽤业务类。Servlet接⼝和Servlet容器这⼀整套内容叫作Servlet规范。 注意:Tomcat既按照Servlet规范的要求去实现了Servlet容器,同时它也具有HTTP服务器的功能。
Tomcat目录结构
bin: 存在是可执行文件。在window下使用startup.bat和shutdown.bat(linux,使用startup.sh和shutdown.sh)在来开启和关闭。最核心的脚本是catalina.bat/catalina.sh,startup和shutdown脚本都会调用catalina脚本,catalina脚本启动或者停止tomcat服务器。
conf: tomcat的配置文件目录,主要的4个配置文件
server.xml:配置整个web服务器信息。例如修改端口号,添加虚拟主机等.
tomcat-users.xml:存储tomcat用户的文件,这里保存的是tomcat的用户名及密码,以及用户的角色信息。
web.xml:部署描述符文件,这个文件中注册了很多MIME类型,即文档类型。
context.xml:对所有应用的统一配置,通常我们不会去配置它。
lib: tomcat的类库。如果需要添加tomcat依赖的jar文件,可以把它放到这个目录中,当然也可以把应用依赖的jar文件放到这个目录中,这个目录中的jar所有项目都可以共享,但这样你的应用放到其他tomcat下时就不能再共享这个目录下的jar包了,所以建议只把tomcat需要的jar包放到这个目录下。
logs:这个目录中都是日志文件,记录了tomcat启动和关闭的信息,如果启动tomcat时有错误,那么异常也会记录在日志文件中。
temp:存放tomcat的临时文件,这个目录下的东西可以在停止tomcat后删除。
webapps:存放web项目的目录,其中每个文件夹都是一个项目;如果这个目录下已经存在了目录,那么都是tomcat自带项目。其中ROOT是一个特殊的项目,在地址栏中没有给出项目目录时,对应的就是ROOT项目。http://localhost:8080/examples,进入示例项目。其中examples就是项目名,即文件夹的名字。
work:运行时生成的文件,最终运行的文件都在这里。通过webapps中的项目生成的,可以把这个目录下的内容删除,再次运行时会生再次生成work目录。当客户端用户访问一个JSP文件时,tomcat会通过JSP生成Java文件,然后再编译Java文件生成class文件,生成的java和class文件都会存放到这个目录下。
Tomcat Servlet容器处理流程
1)为了解耦,HTTP服务器并不直接调用Servlet去处理每个用户请求。而是交给了更为专业的Servlet容器(Tomcat)去处理请求。 2)首先,把用户请求的HTTP报文,解析封装成一个 ServletRequest对象,然后传给 Servlet容器,根据这个对象里的url,通过事先在(web.xml或者注解上定义的映射关系),找到对应的Servlet进行处理。(这里利用了反射技术,动态地创建相应的Servlet)。 3)把ServletRequest传给Servlet之后,Servlet再调用核心方法 Service()进行逻辑的处理,根据不同的请求格式,如POST,GET分别处理(doPost(),doGet() )。 4)然后再把响应信息封装到 servletResponse对象中,最后通过HTTP服务的处理,加上响应头,封装成HTTP报文传回给客户端。
![8cb11e2db68989eed1ae750a9a553a8f.png](https://img-blog.csdnimg.cn/img_convert/8cb11e2db68989eed1ae750a9a553a8f.png)
Tomcat整体架构-两大组件
从宏观上来看,且从数据流转的角度来看,Tomcat最外面的两个核心组件就是Connector连接器和Container容器。
Connector:负责处理Socket请求,然后把请求数据封装成Request对象;还把Response中的响应数据封装成HTTP报文返回给客户端。(相当于HTTP服务器,不处理具体的逻辑业务,只负责转发和接收)
Container容器(Servlet容器):主要是拿到Connector传过来的Request对象,通过解析里面的url,找到对应的Servlet进行处理。先检查这个Servlet是否已经加载(如果加载过了,就直接用),没有加载过的话,就通过反射进行创建);所以从这里可以看得出来Servlet是单例的。
然后Servlet调用Service()方法进行处理,把响应数据封装成Response对象传回Connector。
![8004e3d68eb44dbdfdc965b9a909b3dc.png](https://img-blog.csdnimg.cn/img_convert/8004e3d68eb44dbdfdc965b9a909b3dc.png)
(中间还要经过catalina容器) (Catalina容器接收的是ServletRequest对象) (所以在Connector组件和Catalina之间还有好多组件)
Tomcat⽀持多种应⽤层协议和I/O模型,如下:
![557f73c9c589b3242a349e3c0ff0ede2.png](https://img-blog.csdnimg.cn/img_convert/557f73c9c589b3242a349e3c0ff0ede2.png)
Coyote 的内部组件及流程
![70cb2bb8a48c9620d9c153596196cf39.png](https://img-blog.csdnimg.cn/img_convert/70cb2bb8a48c9620d9c153596196cf39.png)
![f061828971296b2c5fbf2503ed2d7353.png](https://img-blog.csdnimg.cn/img_convert/f061828971296b2c5fbf2503ed2d7353.png)
Endpoint:Coyote的通信端点,是具体Socket接收和发送处理器,是对传输层的抽象,因此,Endpoint是用来实现TCP/IP协议的。 Tomcat没有Endpoint接口,而是定义了AbstractEndpoint,里面定义了两个内部类:Acceptor和SocketProcessor。 Acceptor用来监听Socket请求,SocketProcessor用来处理接收到的Socket请求,它实现了Runnable接口。 Processor:Coyote协议处理接口,如果说Endpoint是用来实现TCP/IP协议的,那么Processor是专门用来实现HTTP协议的。Processor接收来自Endpoint的Socket,读取字节流(按照HTTP协议)解析成Tomcat Request和Response对象,并通过Adapter提交到容器进行处理。 ProcessorHandler:Coyote协议接口,通过Endpoint和Processor,实现对具体协议的处理能力。 Adater:适配器的应用
Tomcat Servlet 容器 Catalina
![f132fb3c2fb91f06efa6873f581d2038.png](https://img-blog.csdnimg.cn/img_convert/f132fb3c2fb91f06efa6873f581d2038.png)
Tomcat是⼀个由⼀系列可配置(conf/server.xml)的组件构成的Web容器,⽽Catalina是Tomcat的servlet容器。
从另⼀个⻆度来说,Tomcat 本质上就是⼀款 Servlet 容器, 因为 Catalina 才是 Tomcat 的核⼼ , 其他模块都是为Catalina 提供⽀撑的。 ⽐如 : 通过 Coyote 模块提供链接通信,Jasper 模块提供 JSP 引擎,Naming 提供JNDI 服务,Juli 提供⽇志服务。
![437d3c862b30bdc0aa9f3d7c9d8bb348.png](https://img-blog.csdnimg.cn/img_convert/437d3c862b30bdc0aa9f3d7c9d8bb348.png)
其实,可以认为整个Tomcat就是⼀个Catalina实例,Tomcat 启动的时候会初始化这个实例,Catalina实例通过加载server.xml完成其他实例的创建,创建并管理⼀个Server,Server创建并管理多个服务,每个服务⼜可以有多个Connector和⼀个Container。 ⼀个Catalina实例(容器) ⼀个 Server实例(容器) 多个Service实例(容器) 每⼀个Service实例下可以有多个Connector实例和⼀个Container实例。 Container又含有四大基本容器类:Engine,Host,Context,Wrapper。
Catalina 负责解析Tomcat的配置⽂件(server.xml) , 以此来创建服务器Server组件并进⾏管理
Server 服务器表示整个Catalina Servlet容器以及其它组件,负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝,提供了⼀种优雅的启动和关闭整个系统的⽅式
Service 服务是Server内部的组件,⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个Container
Container 容器,负责处理⽤户的servlet请求,并返回对象给web⽤户的模块
Tomcat 服务器核心配置
核⼼配置在tomcat⽬录下conf/server.xml⽂件
<!--
Server 根元素,创建⼀个Server实例,⼦标签有 Listener、GlobalNamingResources、Service
-->
<Server>
<!--定义监听器-->
<Listener/>
<!--定义服务器的全局JNDI资源 -->
<GlobalNamingResources/>
<!--
定义⼀个Service服务,⼀个Server标签可以有多个Service服务实例
-->
<Service/>
</Server>
Server 标签
<!--
port:关闭服务器的监听端⼝
shutdown:关闭服务器的指令字符串
-->
<Server port="8005" shutdown="SHUTDOWN">
<!-- 以⽇志形式输出服务器 、操作系统、JVM的版本信息 -->
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<!-- Security listener. Documentation at /docs/config/listeners.html
<Listener className="org.apache.catalina.security.SecurityListener" />
-->
<!--APR library loader. Documentation at /docs/apr.html -->
<!-- 加载(服务器启动) 和 销毁 (服务器停⽌) APR。 如果找不到APR库, 则会输出⽇志, 并不影响 Tomcat启动 -->
<Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<!-- 避免JRE内存泄漏问题 -->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<!-- 加载(服务器启动) 和 销毁(服务器停⽌) 全局命名服务 -->
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<!-- 在Context停⽌时重建 Executor 池中的线程, 以避免ThreadLocal 相关的内存泄漏 -->
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<!-- Global JNDI resources
Documentation at /docs/jndi-resources-howto.html
GlobalNamingResources 中定义了全局命名服务
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: A "Service" is not itself a "Container",so you may not define subcomponents such as "Valves" at this level.Documentation at /docs/config/service.html
-->
<Service name="Catalina">
...
</Service>
</Server>
Service 标签
<!--
该标签⽤于创建 Service 实例,默认使⽤ org.apache.catalina.core.StandardService。
默认情况下,Tomcat 仅指定了Service 的名称, 值为 "Catalina"。
Service ⼦标签为 : Listener、Executor、Connector、Engine,
其中:
Listener ⽤于为Service添加⽣命周期监听器,
Executor ⽤于配置Service 共享线程池,
Connector ⽤于配置Service 包含的链接器,
Engine ⽤于配置Service中链接器对应的Servlet 容器引擎
-->
<Service name="Catalina">
...
</Service>
Executor 标签
<!--
默认情况下,Service 并未添加共享线程池配置。 如果我们想添加⼀个线程池, 可以在<Service> 下添加如下配置:
name:线程池名称,⽤于 Connector中指定
namePrefix:所创建的每个线程的名称前缀,⼀个单独的线程名称为
namePrefix+threadNumber
maxThreads:池中最⼤线程数
minSpareThreads:活跃线程数,也就是核⼼池线程数,这些线程不会被销毁,会⼀直存在
maxIdleTime:线程空闲时间,超过该时间后,空闲线程会被销毁,默认值为6000(1分钟),单位 毫秒
maxQueueSize:在被执⾏前最⼤线程排队数⽬,默认为Int的最⼤值,也就是⼴义的⽆限。除⾮特殊情况,这个值 不需要更改,否则会有请求不会被处理的情况发⽣
prestartminSpareThreads:启动线程池时是否启动
minSpareThreads部分线程。默认值为false,即不启动
threadPriority:线程池中线程优先级,默认值为5,值从1到10
className:线程池实现类,未指定情况下,默认实现类为
org.apache.catalina.core.StandardThreadExecutor。如果想使⽤⾃定义线程池⾸先需要实现
org.apache.catalina.Executor接⼝
-->
<Executor name="commonThreadPool"
namePrefix="thread-exec-"
maxThreads="200"
minSpareThreads="100"
maxIdleTime="60000"
maxQueueSize="Integer.MAX_VALUE"
prestartminSpareThreads="false"
threadPriority="5"
className="org.apache.catalina.core.StandardThreadExecutor"/>
Connector 标签 Connector 标签⽤于创建链接器实例 默认情况下,server.xml 配置了两个链接器,⼀个⽀持HTTP协议,⼀个⽀持AJP协议 ⼤多数情况下,我们并不需要新增链接器配置,只是根据需要对已有链接器进⾏优化
<!--
port:端⼝号,Connector ⽤于创建服务端Socket 并进⾏监听, 以等待客户端请求链接。如果该属性设置为0, Tomcat将会随机选择⼀个可⽤的端⼝号给当前Connector 使⽤
protocol:
当前Connector ⽀持的访问协议。 默认为 HTTP/1.1 , 并采⽤⾃动切换机制选择⼀个基于 JAVA NIO 的链接器或者基于本地APR的链接器(根据本地是否含有Tomcat的本地库判定)
connectionTimeOut:
Connector 接收链接后的等待超时时间, 单位为 毫秒。 -1 表示不超时。
redirectPort:
当前Connector 不⽀持SSL请求, 接收到了⼀个请求, 并且也符合security-constraint 约束,
需要SSL传输,Catalina⾃动将请求重定向到指定的端⼝。
executor:
指定共享线程池的名称, 也可以通过maxThreads、minSpareThreads 等属性配置内部线程池。
URIEncoding:
⽤于指定编码URI的字符编码, Tomcat8.x版本默认的编码为 UTF-8 , Tomcat7.x版本默认为ISO-
8859-1
-->
<!--org.apache.coyote.http11.Http11NioProtocol , ⾮阻塞式 Java NIO 链接器-->
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Engine 标签 Engine 表示 Servlet 引擎
<!--
name: ⽤于指定Engine 的名称, 默认为Catalina
defaultHost:默认使⽤的虚拟主机名称, 当客户端请求指向的主机⽆效时, 将交由默认的虚拟主机处
理, 默认为localhost
-->
<Engine name="Catalina" defaultHost="localhost">
...
</Engine>
Host 标签 Host 标签⽤于配置⼀个虚拟主机
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
...
</Host>
Context 标签 Context 标签⽤于配置⼀个Web应⽤,如下:
<Host name="www.abc.com" appBase="webapps" unpackWARs="true"
autoDeploy="true">
<!--
docBase:Web应⽤⽬录或者War包的部署路径。可以是绝对路径,也可以是相对于 Host appBase的
相对路径。
path:Web应⽤的Context 路径。如果我们Host名为localhost, 则该web应⽤访问的根路径为:
http://localhost:8080/web_demo。
-->
<Context docBase="/Users/yingdian/web_demo" path="/web3"></Context>
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
Tomcat 类加载机制剖析
Java类(.java)—> 字节码⽂件(.class) —> 字节码⽂件需要被加载到jvm内存当中(这个过程就是⼀个类加载的过程)
类加载器(ClassLoader,说⽩了也是⼀个类,jvm启动的时候先把类加载器读取到内存当中去,其他的类(如各种jar中的字节码⽂件,⾃⼰开发的代码编译之后的.class⽂件等等))要说 Tomcat的类加载机制,⾸先需要来看看 Jvm 的类加载机制,因为 Tomcat 类加载机制是在 Jvm类加载机制基础之上进⾏了⼀些变动。
JVM 的类加载机制 JVM 的类加载机制中有⼀个⾮常重要的⻆⾊叫做类加载器(ClassLoader),类加载器有⾃⼰的体系,Jvm内置了⼏种类加载器,包括:引导类加载器、扩展类加载器、系统类加载器,他们之间形成⽗⼦关系,通过 Parent 属性来定义这种关系,最终可以形成树形结构。
![b2c22f21913cb861a9811ef04a520cd6.png](https://img-blog.csdnimg.cn/img_convert/b2c22f21913cb861a9811ef04a520cd6.png)
![dffb3be88521a0d451811d0ca873384c.png](https://img-blog.csdnimg.cn/img_convert/dffb3be88521a0d451811d0ca873384c.png)
用户可以自定义类加载器(Java编写,⽤户⾃定义的类加载器,可加载指定路径的 class ⽂件)
当 JVM 运⾏过程中,⽤户⾃定义了类加载器去加载某些类时,会按照下⾯的步骤(⽗类委托机制)
1) ⽤户⾃⼰的类加载器,把加载请求传给⽗加载器,⽗加载器再传给其⽗加载器,⼀直到加载器树的顶层
2 )最顶层的类加载器⾸先针对其特定的位置加载,如果加载不到就转交给⼦类
3 )如果⼀直到底层的类加载都没有加载到,那么就会抛出异常 ClassNotFoundException 因此,按照这个过程可以想到,如果同样在 classpath 指定的⽬录中和⾃⼰⼯作⽬录中存放相同的class,会优先加载 classpath ⽬录中的⽂件
Tomcat 的类加载机制 Tomcat 的类加载机制相对于 Jvm 的类加载机制做了⼀些改变。 没有严格的遵从双亲委派机制,也可以说打破了双亲委派机制
比如:有一个tomcat,webapps下部署了两个应用
app1/lib/a-1.0.jar com.lagou.edu.Abc
app2/lib/a-2.0.jar com.lagou.edu.Abc
不同版本中Abc类的内容是不同的,代码是不一样的
![cb7f0429d1525b7ed76af2388fd27f0e.png](https://img-blog.csdnimg.cn/img_convert/cb7f0429d1525b7ed76af2388fd27f0e.png)
- 引导类加载器 和 扩展类加载器 的作⽤不变
- 系统类加载器正常情况下加载的是 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 下的类。
tomcat 8.5 默认改变了严格的双亲委派机制
首先从 Bootstrap Classloader加载指定的类
如果未加载到,则从 /WEB-INF/classes加载
如果未加载到,则从 /WEB-INF/lib/*.jar 加载
如果未加载到,则依次从 System、Common、Shared 加载(在这最后一步,遵从双亲委派机制)
Nginx笔记
Nginx 是⼀个⾼性能的HTTP和反向代理web服务器,核⼼特点是占有内存少,并发能⼒强
应用场景
- Http服务器(Web服务器) 性能⾮常⾼,⾮常注重效率,能够经受⾼负载的考验。 ⽀持50000个并发连接数,不仅如此,CPU和内存的占⽤也⾮常的低,10000个没有活动的连接才占⽤2.5M的内存。
- 反向代理服务器
- 正向代理 在浏览器中配置代理服务器的相关信息,通过代理服务器访问⽬标⽹站,代理服务器收到⽬标⽹站的响应之后,会把响应信息返回给我们⾃⼰的浏览器客户端
![22df7001c822714eb5ba8997e734a0f9.png](https://img-blog.csdnimg.cn/img_convert/22df7001c822714eb5ba8997e734a0f9.png)
- 反向代理 浏览器客户端发送请求到反向代理服务器(⽐如Nginx),由反向代理服务器选择原始服务器提供服务获取结果响应,最终再返回给客户端浏览器
![ba3f45f116920b66023a44f2bfca52b5.png](https://img-blog.csdnimg.cn/img_convert/ba3f45f116920b66023a44f2bfca52b5.png)
- 负载均衡服务器 负载均衡,当⼀个请求到来的时候(结合上图),Nginx反向代理服务器根据请求去找到⼀个原始服务器来处理当前请求,那么这叫做反向代理。那么,如果⽬标服务器有多台(⽐如上图中的tomcat1,tomcat2,tomcat3...),找哪⼀个⽬标服务器来处理当前请求呢,这样⼀个寻找确定的过程就叫做负载均衡。 ⽣活中也有很多这样的例⼦,⽐如,我们去银⾏,可以处理业务的窗⼝有多个,那么我们会被分配到哪个窗⼝呢到底,这样的⼀个过程就叫做负载均衡。 负载均衡就是为了解决⾼负载的问题。
- 动静分离
![76c50b1b4d0a8b314b462a4b9c218088.png](https://img-blog.csdnimg.cn/img_convert/76c50b1b4d0a8b314b462a4b9c218088.png)
Nginx 的特点
跨平台:Nginx可以在⼤多数类unix操作系统上编译运⾏,⽽且也有windows版本 Nginx的上⼿⾮常容易,配置也⽐较简单 ⾼并发,性能好 稳定性也特别好,宕机概率很低
Nginx核心配置⽂件解读
Nginx的核⼼配置⽂件conf/nginx.conf包含三块内容:全局块、events块、http块
全局块 从配置⽂件开始到events块之间的内容,此处的配置影响nginx服务器整体的运⾏,⽐如worker进程的数量、错误⽇志的位置等 events块 events块主要影响nginx服务器与⽤户的⽹络连接,⽐如worker_connections 1024,标识每个workderprocess⽀持的最⼤连接数为1024 http块 http块是配置最频繁的部分,虚拟主机的配置,监听端⼝的配置,请求转发、反向代理、负载均衡等
Nginx应⽤场景之反向代理
![c63e043784628f1304cc3b43c5db7722.png](https://img-blog.csdnimg.cn/img_convert/c63e043784628f1304cc3b43c5db7722.png)
Nginx应⽤场景之负载均衡
![9ae464e202c1361c674fff5ed07f6a17.png](https://img-blog.csdnimg.cn/img_convert/9ae464e202c1361c674fff5ed07f6a17.png)
Nginx应⽤场景之动静分离
动静分离就是讲动态资源和静态资源的请求处理分配到不同的服务器上,⽐较经典的组合就是Nginx+Tomcat架构(Nginx处理静态资源请求,Tomcat处理动态资源请求),那么其实之前的讲解中,Nginx反向代理⽬标服务器Tomcat,我们能看到⽬标服务器ROOT项⽬的index.jsp,这本身就是Tomcat在处理动态资源请求了。
所以,我们只需要配置静态资源访问即可。
![6d418e95c60ba56c2b61635ea0cb0a9e.png](https://img-blog.csdnimg.cn/img_convert/6d418e95c60ba56c2b61635ea0cb0a9e.png)