jvm内存配置优化，GC垃圾回收优化
1、jvm内存参数调整，提高tomcat性能
参数 | 参数作用 | 优化建议 |
-server | 启动Server，以服务端模式运行 | 服务端模式建议开启 |
-Xms | 最小堆内存 | 建议与-Xmx设置相同 |
-Xmx | 最大堆内存 | 建议与-Xmx设置相同 |
-XX:MetaspaceSize | 元空间初始值 | |
-XX：MaxMetaspaceSize | 元空间最大内存 | 默认无限 |
-XX：MaxNewSize | 新生代最大内存 | 默认16M |
-XX：NewRatio | 年轻代和老年代大小比值，取值为整数，默认为2. | 不建议修改 |
-XX：SurvivorRatio | Eden区与Survivor区大小的比值，取值为整数，默认为8 | 不建议修改 |
2、GC策略
jvm垃圾回收性能主要指标：
吞吐量：工作时间（排除gc时间）占总时间的百分比，工作时间并不仅是程序运行的时间，还包含内存分配时间
暂停时间：测试时间段内，由垃圾回收导致的应用程序停止响应次数/时间。
垃圾收集器类型
垃圾收集器 | 含义说明 |
串行收集器（Serial Collector） | 采用单线程执行所有的垃圾回收工作，适用于单核CPU服务器，无法利用多核硬件的优势 |
并行收集器（Parallel Collector） | 又称为吞吐量收集器，以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态)。适用于多处理器或多线程硬件上运行的数据量较大的应用 |
并发收集器（Concurrent Collector） | 以并发的方式执行大部分垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应时间优先于吞吐量的应用，因为该收集器虽然最小化了暂停时间（指用户线程与垃圾收集线程同时执行，但不一定是并行的，可能会交替进行），但是会降低应用程序的性能 |
CMS收集器（Concurrent Mark Sweep Collector） | 并发标记清除收集器，适用于那些更愿意缩短垃圾回收暂停时间并负担的起与垃圾回收共享处理器资源的应用 |
G1收集器（Garbage-First Garbage Collector） | 适用于大容量内存的多核服务器，可以在满足垃圾回收暂停时间目标的同时，以最大可能性实现高吞吐量（JDK1.7之后） |
GC参数配置
参数 | 描述 |
-XX:+UseSerialGC | 启用串行收集器 |
-XX：+UseParallelGC | 启用并行垃圾收集器，配置了该选项，那么-XX：-UseParallelOldGC |
-XX：+UseParallelOldGC | FullGC,采用并行收集，默认禁用，如果设置了-XX：+UseParallelGC则自动启动 |
-XX：+UseParNewGC | 年轻代采用并行收集器，如果设置了，-XX：+UseConcMarkSweepGC选项，自动启动 |
-XX：ParallelGCThreads | 年轻代及老年代垃圾回收使用的线程数。默认值依赖于JVM使用的CPU个数 |
-XX：+UseConcMarkSweepGC | 对于老年代，启动CMS垃圾收集器，当并行收集器无法满足应用的延迟需求时，推荐使用CMS或G1收集器，启用该选项后，-XX：+UseParNewGC自动启用 |
--XX：+UseG1GC | 启用G1收集器，G1是服务器类型的收集器，用于多核、大内存的机器。它在保持高吞吐量的情况下，高概率满足GC暂停时间的目标 |
我们可以在测试的时候，将jvm参数调整之后，将gc的信息打印出来，便于为我们进行参数调整提供依据，具体参数如下：
选项 | 描述 |
-XX：+PrintGC | 打印每次GC的信息 |
-XX：+PrintGCApplicationConcurrentTime | 打印最后一次暂停之后所经过的时间，即响应并发执行的时间 |
-XX：+PrintGCApplicationStoppedTime | 打印GC时应用暂停时间 |
-XX:+PrintGCDateStamps | 打印每次GC的日期戳 |
-XX：PrintGCDetails | 打印每次GC的详细信息 |
-XX：+PrintGCTaskTimeStamps | 打印每个GC工作线程任务的时间戳 |
-XX：+PrintGCTimesStamps | 打印每次GC的时间戳 |
2、tomcat配置调优，调整tomcat/conf/server.xml中关于链接器的配置可以提升应用服务器的性能
参数 | 说明 |
maxConnections | 最大连接数，当达到该值后，服务器接收单不会处理更多的请求，额外的请求将会阻塞直到连接数低于maxConnections。可通过ulimit -a查看服务器限制。对于CPU要求更高（计算型）时，建议不要配置过大；对于cpu要求不是特别高时，建议配置在2000左右。当然这个需求服务器硬件的支持 |
maxThreads | 最大线程数，需要根据服务器的硬件情况，进行一个合理的设置 |
acceptCount | 最大排队等待数，当服务器接收的请求数量到大maxConnections，此时Tomcat会将后面的请求，存放在任务队列中进行排序，acceptCount指的就是任务队列中排队等待的请求数。一台Tomcat的最大请求处理数量，是maxConnections+acceptCount |
