Tomcate笔记
最后模块作业是手写代码，实现tomcat的加载webapp目录下的项目，根据访问路径进行访问servlet和静态资源，通过加载子项目的web.xml和自定义classLoader，反射，最终完成。每个作业都附带视频讲解。
https://gitee.com/baiheai/code
1.Tomcat 系统架构与原理剖析
通常配置conf下的server.xml;web.xml是全局的，以各项目配置的为准；work文件夹是jsp编译、存放、运行的文件夹。
浏览器访问服务器的流程
Tomcat处理流程及架构：
Tomcat的两个重要身份1）http服务器，实现核心是连接器（Connector），而连接器的核心是Coyote
2）Tomcat是⼀个Servlet容器，核心是容器（Container），而容器的核心是Container
Coyote功能：
Coyote 是Tomcat 中连接器的组件名称 , 是对外的接⼝。客户端通过Coyote与服务器建⽴连接、发送请求并接受响应 。a.Coyote 封装了底层的⽹络通信（Socket 请求及响应处理）b.Coyote 使Catalina 容器（容器组件）与具体的请求协议及IO操作⽅式完全解耦c.Coyote 将Socket 输⼊转换封装为 Request 对象，进⼀步封装后交由Catalina 容器进⾏处理，处理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流d.Coyote 负责的是具体协议（应⽤层）和IO（传输层）相关内容
Tomcat体系结构
Tomcat Servlet容器处理流程（简）
1）HTTP服务器会把请求信息使⽤ServletRequest对象封装起来2）进⼀步去调⽤Servlet容器中某个具体的Servlet3）在 2）中，Servlet容器拿到请求后，根据URL和Servlet的映射关系，找到相应的Servlet4）如果Servlet还没有被加载，就⽤反射机制创建这个Servlet，并调⽤Servlet的init⽅法来完成初始化5）接着调⽤这个具体Servlet的service⽅法来处理请求，请求处理结果使⽤ServletResponse对象封装6）把ServletResponse对象返回给HTTP服务器，HTTP服务器会把响应发送给客户端
Tomcat Servlet容器处理流程及组件说明（详）
1.http服务器接收到用户请求，Coyote中的EndPoint进行接收处理，EndPoint是通信端点，即通信监听的接⼝，是具体Socket接收和发送处理器，是对传输层的抽象，因此EndPoint⽤来实现TCP/IP协议的
2.Processor接收来⾃EndPoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应⽤层协议的抽象Processor 是Coyote 协议处理接⼝ ，如果说EndPoint是⽤来实现TCP/IP协议的，那么Processor⽤来实现HTTP协议，
3.接收ProtocolHandler发送的请求。由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了⾃⼰的Request类来封装这些请求信息。ProtocolHandler（由EndPoint和Processor组成）接⼝负责解析请求并⽣成Tomcat Request类。但是这个Request对象不是标准的ServletRequest，不能⽤Tomcat Request作为参数来调⽤容器。Tomcat设计者的解决⽅案是引⼊CoyoteAdapter，这是适配器模式的经典运⽤，连接器调⽤CoyoteAdapter的Sevice⽅法，传⼊的是Tomcat Request对象，CoyoteAdapter负责将Tomcat Request转成ServletRequest，再调⽤容器。
4.Tomcat 本质上就是⼀款 Servlet 容器， 因为 Catalina 才是 Tomcat 的核⼼ 。容器接收到ServletRequest后，根据URL和Servlet的映射关系，找到相应的Servlet。如果Servlet还没有被加载，就⽤反射机制创建这个Servlet，并调⽤Servlet的init⽅法来完成初始化。接着调⽤这个具体Servlet的service⽅法来处理请求，请求处理结果使⽤ServletResponse对象封装。
其中⼀个Catalina实例（容器）对应⼀个 Server实例（容器），一个Server实例对应多个Service实例（容器）。
Catalina：负责解析Tomcat的配置⽂件（server.xml） , 以此来创建服务器Server组件并进⾏管理Server：服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝，提供了⼀种优雅的启动和关闭整个系统的⽅式Service：服务是Server内部的组件，⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个Container：容器，负责处理⽤户的servlet请求，并返回对象给web⽤户的模块
Container组件下有⼏种具体的组件，分别是Engine、Host、Context和Wrapper。这4种组件（容器）是⽗⼦关系。Tomcat通过⼀种分层的架构，使得Servlet容器具有很好的灵活性。Engine：表示整个Catalina的Servlet引擎，⽤来管理多个虚拟站点，⼀个Service最多只能有⼀个Engine，但是⼀个引擎可包含多个HostHost：代表⼀个虚拟主机，或者说⼀个站点，可以给Tomcat配置多个虚拟主机地址，⽽⼀个虚拟主机下可包含多个ContextContext：表示⼀个Web应⽤程序， ⼀个Web应⽤可包含多个WrapperWrapper：表示⼀个Servlet，Wrapper 作为容器中的最底层，不能包含⼦容器上述组件的配置其实就体现在conf/server.xml中。
5.Coyote接收到容器返回的Response 对象之后进行返回给用户
2.Tomcat 服务器核⼼配置详解
核⼼配置在tomcat⽬录下conf/server.xml⽂件，server.xml中包含了 Servlet容器的相关配置，即 Catalina 的配置。
Server标签：port：关闭服务器的监听端⼝；shutdown：关闭服务器的指令字符串
Service 标签：该标签⽤于创建 Service 实例，默认使⽤ org.apache.catalina.core.StandardService。默认情况下，Tomcat 仅指定了Service 的名称， 值为 "Catalina"。Service ⼦标签为 ： Listener、Executor、Connector、Engine，其中：Listener ⽤于为Service添加⽣命周期监听器，Executor ⽤于配置Service 共享线程池，Connector ⽤于配置Service 包含的链接器，Engine ⽤于配置Service中链接器对应的Servlet 容器引擎
Executor 标签：默认情况下，Service 并未添加共享线程池配置。 如果我们想添加⼀个线程池， 可以在
Connector 标签：默认情况下，server.xml 配置了两个链接器，⼀个⽀持HTTP协议，⼀个⽀持AJP协议⼤多数情况下，我们并不需要新增链接器配置，只是根据需要对已有链接器进⾏优化
Engine 标签：表示 Servlet 引擎
Host 标签：⽤于配置⼀个虚拟主机
Context 标签：⽤于配置⼀个Web应⽤
3.Tomcat 源码构建及核⼼流程源码剖析
tomcate启动流程图：
Tomcat执行流程：
4.Tomcat 类加载机制剖析
JVM 的类加载机制：
当 JVM 运⾏过程中，⽤户⾃定义了类加载器去加载某些类时，会按照下⾯的步骤（⽗类委托机制） 1） ⽤户⾃⼰的类加载器，把加载请求传给⽗加载器，⽗加载器再传给其⽗加载器，⼀直到加载器树的顶层 2 ）最顶层的类加载器⾸先针对其特定的位置加载，如果加载不到就转交给⼦类 3 ）如果⼀直到底层的类加载都没有加载到，那么就会抛出异常 ClassNotFoundException 因此，按照这个过程可以想到，如果同样在 classpath 指定的⽬录中和⾃⼰⼯作⽬录中存放相同的class，会优先加载 classpath ⽬录中的⽂件。
当某个类加载器需要加载某个.class⽂件时，它⾸先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，⾃⼰才会去加载这个类。
防⽌重复加载同⼀个.class。通过委托去向上⾯问⼀问，加载过了，就不⽤再加载⼀遍。保证数据安全。保证核⼼.class不能被篡改。通过委托⽅式，不会去篡改核⼼.class，即使篡改也不会去加载，即使加载也不会是同⼀个.class对象了。不同的加载器加载同⼀个.class也不是同⼀个.class对象。这样保证了class执⾏安全（如果⼦类加载器先加载，那么我们可以写⼀些与java.lang包中基础类同名的类， 然后再定义⼀个⼦类加载器，这样整个应⽤使⽤的基础类就都变成我们⾃⼰定义的类了。）Object类 -----> ⾃定义类加载器（会出现问题的，那么真正的Object类就可能被篡改了）
Tomcat的类加载：
引导类加载器 和 扩展类加载器 的作⽤不变系统类加载器正常情况下加载的是 CLASSPATH 下的类，但是 Tomcat 的启动脚本并未使⽤该变量，⽽是加载tomcat启动的类，⽐如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下Common 通⽤类加载器加载Tomcat使⽤以及应⽤通⽤的⼀些类，位于CATALINA_HOME/lib下，⽐如servlet-api.jarCatalina 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 加载
5.Tomcat 对 Https 的⽀持及 Tomcat 性能优化策略
HTTPS和HTTP的主要区别HTTPS协议使⽤时需要到电⼦商务认证授权机构（CA）申请SSL证书HTTP默认使⽤8080端⼝，HTTPS默认使⽤8443端⼝HTTPS则是具有SSL加密的安全性传输协议，对数据的传输进⾏加密，效果上相当于HTTP的升级版HTTP的连接是⽆状态的，不安全的；HTTPS协议是由SSL+HTTP协议构建的可进⾏加密传输、身份认证的⽹络协议，⽐HTTP协议安全
Tomcat对HTTPS的支持
1） 使⽤ JDK 中的 keytool ⼯具⽣成免费的秘钥库⽂件(证书)。
keytool -genkey -alias lagou -keyalg RSA -keystore lagou.keystore
2） 配置conf/server.xml
maxThreads="150" schema="https" secure="true" SSLEnabled="true">
certificateKeystoreFile="/Users/yingdian/workspace/servers/apache-tomcat-
8.5.50/conf/lagou.keystore" certificateKeystorePassword="lagou123" type="RSA"
/>
3）使⽤https协议访问8443端⼝（https://localhost:8443）
Tomcat 性能优化策略
系统性能的衡量指标，主要是响应时间和吞吐量。1）响应时间：执⾏某个操作的耗时；2) 吞吐量：系统在给定时间内能够⽀持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，⼀个事务是指⼀个客户机向服务器发送请求然后服务器做出反应的过程。Tomcat优化从两个⽅⾯进⾏1）JVM虚拟机优化（优化内存模型）2）Tomcat⾃身配置的优化（⽐如是否使⽤了共享线程池？IO模型？）
虚拟机运⾏优化（参数调整）：
Java 虚拟机的运⾏优化主要是内存分配和垃圾回收策略的优化：内存直接影响服务的运⾏效率和吞吐量垃圾回收机制会不同程度地导致程序运⾏中断（垃圾回收策略不同，垃圾回收次数和回收效率都是不同的）
JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
垃圾回收（GC）策略垃圾回收性能指标吞吐量：⼯作时间（排除GC时间）占总时间的百分⽐， ⼯作时间并不仅是程序运⾏的时间，还包含内存分配时间。暂停时间：由垃圾回收导致的应⽤程序停⽌响应次数/时间。垃圾收集器串⾏收集器（Serial Collector）单线程执⾏所有的垃圾回收⼯作， 适⽤于单核CPU服务器⼯作进程-----|（单线程）垃圾回收线程进⾏垃圾收集|---⼯作进程继续并⾏收集器（Parallel Collector）参数 描述-XX:+UseSerialGC 启⽤串⾏收集器-XX:+UseParallelGC启⽤并⾏垃圾收集器，配置了该选项，那么 -XX:+UseParallelOldGC默认启⽤-XX:+UseParNewGC年轻代采⽤并⾏收集器，如果设置了 -XX:+UseConcMarkSweepGC选项，⾃动启⽤-XX:ParallelGCThreads年轻代及⽼年代垃圾回收使⽤的线程数。默认值依赖于JVM使⽤的CPU个数-XX:+UseConcMarkSweepGC（CMS）对于⽼年代，启⽤CMS垃圾收集器。 当并⾏收集器⽆法满⾜应⽤的延迟需求是，推荐使⽤CMS或G1收集器。启⽤该选项后， -XX:+UseParNewGC⾃动启⽤。-XX:+UseG1GC启⽤G1收集器。 G1是服务器类型的收集器， ⽤于多核、⼤内存的机器。它在保持⾼吞吐量的情况下，⾼概率满⾜GC暂停时间的⽬标。⼯作进程-----|（多线程）垃圾回收线程进⾏垃圾收集|---⼯作进程继续⼜称为吞吐量收集器（关注吞吐量）， 以并⾏的⽅式执⾏年轻代的垃圾回收， 该⽅式可以显著降低垃圾回收的开销(指多条垃圾收集线程并⾏⼯作，但此时⽤户线程仍然处于等待状态)。适⽤于多处理器或多线程硬件上运⾏的数据量较⼤的应⽤并发收集器（Concurrent Collector）以并发的⽅式执⾏⼤部分垃圾回收⼯作，以缩短垃圾回收的暂停时间。适⽤于那些响应时间优先于吞吐量的应⽤， 因为该收集器虽然最⼩化了暂停时间(指⽤户线程与垃圾收集线程同时执⾏,但不⼀定是并⾏的，可能会交替进⾏)， 但是会降低应⽤程序的性能CMS收集器（Concurrent Mark Sweep Collector）并发标记清除收集器， 适⽤于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应⽤G1收集器（Garbage-First Garbage Collector）适⽤于⼤容量内存的多核服务器， 可以在满⾜垃圾回收暂停时间⽬标的同时， 以最⼤可能性实现⾼吞吐量(JDK1.7之后）
在bin/catalina.sh的脚本中 , 追加如下配置 :JAVA_OPTS="-XX:+UseConcMarkSweepGC"
Tomcat 配置调优：
调整tomcat线程池
调整tomcat的连接器
禁⽤ AJP 连接器
调整 IO 模式
动静分离
可以使⽤Nginx+Tomcat相结合的部署⽅案，Nginx负责静态资源访问，Tomcat负责Jsp等动态资源访问处理（因为Tomcat不擅⻓处理静态资源）