文章目录

前言

系统性能的衡量指标，主要是响应时间和吞吐量 1)响应时间:执行某个操作的耗时（rt）; 2) 吞吐量:系统在给定时间内能够支持的事务数量，单位为TPS(Transactions PerSecond的缩写，也就是事务数/秒，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。

Tomcat优化从两个方面进行 1)JVM虚拟机优化(优化内存模型) 2)Tomcat自身配置的优化(比如是否使用了共享线程池?IO模型?)

优化的原则：没有说有明确的参数值可以直接去使用，必须根据自己的真实生产环境来进行调整，调优是一个过程

一、虚拟机运行优化(参数调整)

1）内存：内存直接会影响到服务的运行效率和吞吐量 2）垃圾回收机制：垃圾回收机制会不同程度的导致程序运行中断（垃圾回收的策略不同，垃圾回收次数和回收的效率都是不同的）

1.1内存优化

JVM内存模型回顾 java虚拟机内存相关参数

参数	作用	使用建议
-server	启动server，以服务端模式运行	服务端模式建议开启
-Xms	最小堆内存	建议与-Xmx设置相容
-Xmx	最大堆内存	建议设置为可用内存的80%
-XX:MetaspaceSize	元空间初始值
-XX:MaxMetaspaceSize	元空间最大内存	默认无限
-XX:NewRatio	年轻代和老年代大小比值，取值为整数，默认为2	不需要修改
-XX:SurvivorRatio	Eden区与Survivor区大小的比值，取值为整数，默认为8	不需要修改

配置参数

JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"

直接配置到catalina.sh（Mac系统）中

2.垃圾回收（GC）策略

垃圾回收性能指标 1）吞吐量：工作时间（排除GC时间）占总时间的百分比，工作时间并不仅是程序运行的时间，还包含内存分配时间 2）暂停时间：由垃圾回收导致的应用程序停止响应次数/时间

2.1垃圾收集器的发展

1）串行收集器(Serial Collector)：单线程执行所有的垃圾回收工作，适用于单核CPU服务器也是最早的垃圾回收器 工作原理：工作进程暂停—->垃圾回收进程进行垃圾收集（单线程）—->工作进程继续 2）并行收集器(Parallel Collector)：又称为吞吐量收集器(关注吞吐量)，以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态)。适用于多处理器或多线程硬件上运行的数据量较大的应用 工作原理：工作进程暂停—->垃圾回收进程进行垃圾收集（多线程）—->工作进程继续 3）并发收集器(Concurrent Collector)：以并发的方式执行大部分垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应时间优先于吞吐量的应用，因为该收集器虽然最小化了暂停时间(指用户线程与垃圾收集线程同时执行,但不一定是并行的，可能会交替进行)，但是会降低应用程序的性能 4）CMS收集器(Concurrent Mark Sweep Collector)：并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应用 5）G1收集器(Garbage-First Garbage Collector)：适用于大容量内存的多核服务器，可以在满足垃圾回收暂停时间目标的同时，以最大可能性实现高吞吐量( JDK1.7之后)

2.2垃圾收集器参数

参数	描述
-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暂停时间的目标。

2.3查看和修改垃圾收集器参数

使用jconsole查看当前垃圾收集器（jconsole在jdk的bin目录下）选择我们本地打开的tomcat进程查看（jdk版本是11）可以看到这里有两个垃圾收集器，都是G1收集器（jdk1.9以后默认是G1收集器）

接下来我们来切换一下垃圾收集器-换成CMS收集器在tomcat的在bin/catalina.sh的脚本中 , 追加如下配置 :

JAVA_OPTS="-XX:+UseConcMarkSweepGC"

重新启动tomcat。再重新使用jconsole打开对应的进程，可以看到，垃圾回收器切换成功啦

二、Tomcat配置调优

2.1Tomcat自身相关的调优

2.1.1 调整tomcat线程池

2.1.2 调整tomcat的连接器

调整tomcat/conf/server.xml 中关于链接器的配置可以提升应用服务器的性能

参数	说明
maxConnections	最大连接数，当到达该值后，服务器接收但不会处理更多的请求，额外的请求将会阻塞直到连接数低于maxConnections 。可通过ulimit -a 查看服务器限制。对于CPU要求更高(计算密集型)时，建议不要配置过大 ; 对于CPU要求不是特别高时，建议配置在2000左右(受服务器性能影响)。当然这个需要服务器硬件的支持
maxThreads	最大线程数,需要根据服务器的硬件情况，进行一个合理的设置
acceptCount	最大排队等待数,当服务器接收的请求数量到达maxConnections ，此时 Tomcat会将后面的请求，存放在任务队列中进行排序， acceptCount指的就是任务队列中排队等待的请求数。一台Tomcat的最大的请求处理数量，是maxConnections+acceptCount

2.1.3 禁用AJP连接器

AJP连接器是在跟apache进行集成的时候需要的，没有这个需求的话就没必要开启来浪费性能

2.1.4 调整IO模式

Tomcat8之前的版本默认使用BIO(阻塞式IO)，对于每一个请求都要创建一个线程来处理，不适合高并发;Tomcat8以后的版本默认使用NIO模式(非阻塞式IO) 具体的操作呢就是修改Connector的protocol具体实现

当Tomcat并发性能有较高要求或者出现瓶颈时，我们可以尝试使用APR模式，APR(Apache Portable Runtime)是从操作系统级别解决异步IO问题，使用时需要在操作系统上安装APR和Native(因为APR 原理是使用使用JNI技术调用操作系统底层的IO接口) 具体的操作呢也是修改Connector的protocol为APR相关的一些protocol实现