一、优化策略

系统性能的衡量指标，主要是响应时间和吞吐量。

1）响应时间：执行某个操作的耗时；

2) 吞吐量：系统在给定时间内能够支持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。

Tomcat优化从两个方面进行

1）JVM虚拟机优化（优化内存模型）

2）Tomcat自身配置的优化（比如是否使用了共享线程池？IO模型？）

调优是一个过程，不是目的也不是一蹴而就的，必须根据自己的真实生产环境来进行调整。

二、Jvm虚拟机运行优化

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

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

1） Java 虚拟机内存模型和相关参数

参数调整示例：

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

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

2）垃圾回收（GC）策略垃圾回收性能指标吞吐量：

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

垃圾收集器

串行收集器（Serial Collector）

单线程执行所有的垃圾回收工作，适用于单核CPU服务器工作进程
工作进程-----|（单线程）垃圾回收线程进行垃圾收集|---工作进程继续

并行收集器（Parallel Collector）

工作进程-----|（多线程）垃圾回收线程进行垃圾收集|---工作进程继续
又称为吞吐量收集器（关注吞吐量），以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态)。
适用于多处理器或多线程硬件上运行的数据量较大的应。

并发收集器（Concurrent Collector）

以并发的方式执行大部分垃圾回收工作，以缩短垃圾回收的暂停时间。
适用于那些响应时间优先于吞吐量的应用，因为该收集器虽然最小化了暂停时间(指用户线程与垃圾收集线程同时执行,但不一定是并行的，可能会交替进行)，但是会降低应用程序的性能。

CMS收集器（Concurrent Mark Sweep Collector）

并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应用。

G1收集器（Garbage-First Garbage Collector）

适用于大容量内存的多核服务器，可以在满足垃圾回收暂停时间目标的同时，以最大可能性实现高吞吐量( JDK1.7之后)。

工作在新生代的垃圾回收器：SerialGC、ParallelGC、ParNewGC。

工作在老年代的垃圾回收器：ConcMarkSweepGC(CMS)、SerialGC、ParallelOldGC。

G1同时工作在新生代和老年代。

使用jstat -gc pid或jstat -gcutil pid查看java堆情况。

**垃圾回收器参数**
参数	描述
-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:+UeeConcMarkSweepGC"

三、Tomcat配置调优

调整tomcat线程池

调整tomcat的连接器

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

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

禁用 AJP 连接器

<!-- Define an AJP 1.3 Connector on port 8089 -->
<!-- 禁用AJP协议 -->
<!-- 
<Connector port="8009" protocol="AIP/1.3" executor="comnonThreadpoal" redirectPort="443"/>
-->

调整 IO 模式

Tomcat8之前的版本默认使用BIO（阻塞式IO），对于每一个请求都要创建一个线程来处理，不适合高并发；Tomcat8以后的版本默认使用NIO模式（非阻塞式IO）

<!--org.apache.coyote.http11.Http11NioProtocal，非阻塞式Java NIO链接器 -->
<Connector port="8080"protocol="HTTP/1.1" executor="commonThreadPool"
        connectionTmeout="2000"
        redirectPort="8443" />

当Tomcat并发性能有较高要求或者出现瓶颈时，我们可以尝试使用APR模式，APR（Apache PortableRuntime）是从操作系统级别解决异步IO问题，使用时需要在操作系统上安装APR和Native（因为APR原理是使用使用JNI技术调用操作系统底层的IO接口）