【Tomcat】Apache Tomcat Web应用服务器(三)
Apache Tomcat Web应用服务器(三)
文章目录
第四部分：Tomcat 核心流程源码剖析
第一节：Tomcat启动流程
Tomcat中的各容器组件都会涉及创建、销毁等，因此设计了生命周期接口Lifecycle进⾏统⼀规范，各容器组件实现该接口。
初始化流程关键方法：
-
473-daemon.load(args);//daemon当前的bootstarp对象本身
-
303-method.invoke(catalinaDaemon,param);//调用Catalina.load方法
-
640-getServer.init();//根据创建好的server，调用init方法
LifecycleBase下的模板方法：136-initInteral()开启初始化
-
848-services[i].init();//根据services，循环调用初始化方法
-
534-engine.init();//engine初始化，循环调用初始化方法
-
542-execuor.init();//execuor初始化，循环调用初始化方法
-
552-connector.init();//connector初始化，循环调用初始化方法
- 969-new CoyoteAdapter(this);//初始化CoyoteAdapter
- 970-protocolHandler.setAdaper(adaper);//设值，供endPoint和processtor使用
- 993-protocolHandler.init();//初始化protocolHandler
- 581-endPoint.init();
- 1118-bind();//完成socket端口和IO对象的绑定
- 581-endPoint.init();
启动流程关键方法：
-
474-daemon.start();
-
343-method.invoke(catalinaDaemon,(Object[] null));//调用Catalina.start方法
-
157-getServer.start();//根据创建好的server，调用start方法
抽象类LifecycleBase下的模板方法：183-startInteral()开启start方法;
-
766-services[i].start;//services启动，循环调用启动方法
-
422-engine.start();//engine启动，循环调用启动方法
-
428-execuor.start();//execuor启动，循环调用启动方法
-
440-connector.start();//connector启动，循环调用启动方法
- 1018-protocolHandler.start();
- 591-endPoint.start();
- 285-startAcceptorThreads();//启动线程，对端口进行监听
- 1018-protocolHandler.start();
第二节：Tomcat请求处理流程
- 请求处理流程分析
Mapper组件体系的结构，通过此组件完成容器中组件的组合关系
- 请求处理流程示意图
第五部分：Tomcat 类加载机制剖析
Tomcat 的类加载机制相对于 Jvm 的类加载机制做了一些改变。没有严格的遵从双亲委派机制，也可以说打破了双亲委派机制
例如：有一个tomcat，webapps下部署了两个应用
app1/lib/a-1.0.jar com.ch.demo.Abc
app2/lib/a-2.0.jar com.ch.demo.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 下的类。
Tomcat 8.5 默认改变了严格的双亲委派机制
-
优先从 Bootstrap Classloader加载指定的类
-
如果未加载到，则从 /WEB-INF/classes加载
-
如果未加载到，则从 /WEB-INF/lib/*.jar 加载
-
如果未加载到，则依次从 System、Common、Shared 加载（在这最后一步，遵从双亲委派机制）
第六部分：Https 的理解及 Tomcat 性能优化策略
第一节 HTTPS 的理解
https的工作原理
HTTPS和HTTP的主要区别：
- HTTPS协议使⽤时需要到电⼦商务认证授权机构（CA）申请SSL证书HTTP默认使⽤8080端⼝
- HTTPS默认使⽤8443端⼝
- HTTPS则是具有SSL加密的安全性传输协议，对数据的传输进行加密，效果上相当于HTTP的升级版
- HTTP的连接是无状态的，不安全的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全
第二节 Tomcat 性能优化策略
系统性能的衡量指标，主要是响应时间和吞吐量。
- 响应时间：执行某个操作的耗时；
- 吞吐量：系统在给定时间内能够维持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，每个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
虚拟机运行优化（后期我详细出一版优化专题）
1）Java 虚拟机所管理的内存及其类加载流程
对Java 虚拟机的运行优化主要是内存分配和垃圾回收策略的优化：
内存直接影响服务的运行效率和吞吐量，垃圾回收机制会不同程度地导致程序运行中断
（垃圾回收策略不同，垃圾回收次数和回收效率都是不同的）
2）Java 虚拟机内存相关参数
3）垃圾回收（GC）策略垃圾回收性能指标
吞吐量：工作时间（排除GC时间）占总时间的百分比，工作作时间并不仅是程序运行的时间，还包含内存分配时间。
暂停时间：由垃圾回收导致的应用程序停止响应次数/时间。
垃圾收集器
串行收集器（Serial Collector）
单线程执行所有的垃圾回收动作， 适用于单核CPU服务器
工作进程-----|（单线程）垃圾回收线程进行垃圾收集|—工作进程继续
并行收集器（Parallel Collector）
称为吞吐量收集器（关注吞吐量）， 以并行的方式执⾏年轻代的垃圾回收， 该方式可以显著降低垃
圾回收的开销(指多条垃圾收集线程并行工作，但此时⽤户线程仍然处于等待状态)。适用于多核处理器
或多线程硬件上运行的数据量较⼤的应用
工作进程-----|（多线程）垃圾回收线程进行垃圾收集|—工作进程继续
并发收集器（Concurrent Collector）
以并发的方式执行⼤部分垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应时间优先于
吞吐量的应用，因为该收集器虽然最小化了暂停时间(指用户线程与垃圾收集线程同时执行,但不一定
是并行的，可能会交替进行)， 但是会降低应⽤程序的性能
CMS收集器（Concurrent Mark Sweep Collector）
并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应用
G1收集器（Garbage-First Garbage Collector）
适用于大容量内存的多核服务器， 可以在满足垃圾回收暂停时间目标的同时， 以最大可能性实现
高吞吐量( JDK1.7之后)
垃圾回收器参数
1）垃圾回收（GC）流程
Tomcat 自身配置调优
Tomcat⾃身相关的调优调整tomcat线程池
- 调整tomcat的连接器
调整tomcat/conf/server.xml 中关于链接器的配置可以提升应用服务器的性能。
- 禁用AJP 连接器
- 调整 IO 模式
Tomcat8之前的版本默认使用BIO（阻塞式IO），对于每一个请求都要创建一个线程来处理，不适
合用并发；Tomcat8以后的版本默认使用NIO模式（非阻塞式IO）
-
当Tomcat并发性能有较高要求或者出现瓶颈时，我们可以尝试使用APR模式，APR（Apache Portable Runtime）是从操作系统级别解决异步IO问题，使⽤时需要在操作系统上安装APR和Native（因为APR原理是使用JNI技术调用操作系统底层的IO接⼝）
-
动静分离
可以使用Nginx+Tomcat相结合的部署方案，Nginx负责静态资源访问，Tomcat负责Jsp等动态资
源访问处理（因为Tomcat不擅长处理静态资源）
写在最后：内容来源拉勾教育高薪训练营，整合个人总结内容持续输出！
天空不留下鸟儿的痕迹，但我已飞过！-- 泰戈尔