我们业界评判系统性能的指标一般为响应时间和吞吐量。响应时间就是说我们系统执行某个操作所消耗的时长，吞吐量是指系统在给定时间内能够支持的事务数量（单位是TPS Transactions Per Second）。

那么，Tomcat的优化也会按照上述评判标准从两个方面来进行。分别是JVM虚拟机优化（优化内存模型）和Tomcat自身配置的优化（配置线程池、IO模型等等）。

虚拟机运行优化

Java虚拟机的运行优化主要是内存分配和垃圾回收策略的优化：

内存调优

Java虚拟机内存相关的参数如下表所示：

参数	参数作用	优化建议
-server	启动Server，以服务端模式运行	服务端模式建议开启
-Xms	最小堆内存	建议与-Xmx设置相同，防止内存容量在运行时发生动态扩容
-Xmx	最大堆内存	建议设置为可用内存的80%
-XX:MetaspaceSize	元空间初始值	无需修改
-XX:MaxMetaspaceSize	元空间最大内存	默认无限，无需修改
-XX:NewRatio	年轻代和老年代大小比值，取值为整数，默认为2	无需修改
-XX:SuvivorSatio	Eden区与Survivor区大小的比值，取值为整数，默认为8	无需修改

JVM的内存模型如下图：

参数调整示例：

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

垃圾回收的性能指标主要分为以下两个：

垃圾回收器有以下几种：

串行收集器（Serial Collector）：单线程执行所有的垃圾回收工作，适用于单核CPU服务器
并行收集器（Parallel Collector）：又称为吞吐量收集器，以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾回收的开销。适用于多核处理器或多线程硬件上运行的数据量较大的应用。
并发收集器（Concurrent Collector）：以并发的方式执行大部分的垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应时间优先于吞吐量的应用。因为此收集器虽然最小化了暂停时间（指用户线程与垃圾回收线程同时执行，但不一定是并行的，可能会交替进行），但是会降低应用程序的性能
CMS收集器（Concurrent Mark Sweep Collector）：并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应用
G1收集器（Garbage-First Garbage 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暂停时间的目标

在bin/catalina.sh的脚本中 , 追加如下配置 :

JAVA_OPTS="-XX:+UseConcMarkSweepGC"

调整Tomcat线程池：

调整Tomcat的连接器，配置项如下表：

参数	说明
maxConnections	最大连接数，当达到该值后，服务器接受但不会处理更多的请求，额外的请求将会阻塞直到连接数低于 `maxConnections` 。可以通过`ulimit -a`查看服务器限制。对于CPU要求更高（计算密集型）时，建议不要配置过大；对于CPU要求不是特别高是，建议配置在2000左右。这个也可以根据服务器性能做调整
maxThreads	最大线程数，需要根据服务器的硬件情况，进行一个合理的设置
acceptCount	最大排队等待数。当服务器接受的请求达到上限之后，此时Tomcat就会将多余的请求放在任务队列中进行排序，该参数就是设置的任务队列的最大值。也就是说Tomcat的最大请求数量=maxConnections + acceptCount

禁用AJP连接器：