一起说说JVM参数及调优，之前JDK的命令工具也说过，今天一起搞个程序试一把看看如何调优，从哪些方面来调。

（一）调优的基本概念

① 介绍

切记：JVM调优没有什么必要，不要瞎搞，这是很忌讳的事情，毕竟JVM是个很成熟的产品。

② 在调整性能时，JVM有三个组件堆大小调整（内存最够大的话，尽量搞大点）垃圾收集器调整JIT 编译器（比较深，需要掌握源码才能更好的优化更加底层）

大多数调优选项都与调整堆大小和为您的情况选择最合适的垃圾收集器有关。JIT编译器对性能也有很大影响，但很少需要使用较新版本的JVM进行调优。

通常，在调优Java应用程序时，重要是以下两个主要目标之一：
响应性：应用程序或系统对请求的数据进行相应的速度，对于专注于响应性的应用程序，长的暂停时间是不可接受的，重点是在短时间内做出回应。
吞吐量：（批处理任务，大数据量任务）侧重于在特定时间段内最大化应用程序的工作量，对于专注于吞吐量的应用程序，高暂停时间是可接受的。由于高吞吐量应用程序在较长时间内专注于基准测试，因此不需要考虑响应时间。

注意：系统瓶颈核心还是在应用代码，一般情况下无需过多调优，JVM本身在不断优化。

② 示例

只有一个类，这个类并不是需要把整个场景给模拟出来，一定要搞什么大型项目，就像每年双11都说做了全量业务的压测，实际上上线还是要卡，但是到双11那天也会卡，也不可能做到完完全全跟生产环境成比例的， 要做的像数学一样，同理可得，只需要按这个推理，套路去做就可以了。生产环境其实就是操作一个更大的环境而已。

启动程序，模拟用户请求，每100毫秒钟创建1000线程，每个线程创建一个512kb的对象，最多100毫秒内同时存在1000线程，并发量1000/s，吞吐量6000/s，查看GC的情况。

import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import java.util.Random;import java.util.concurrent.Executors;import java.util.concurrent.TimeUnit;// 启动程序，模拟用户请求// 每100毫秒钟创建1000线程，每个线程创建一个512kb的对象，最多100毫秒内同时存在1000线程，并发量1000/s，吞吐量6000/s，查看GC的情况@SpringBootApplicationpublic class PerformanceApplication { public static void main(String[] args) { SpringApplication.run(PerformanceApplication.class, args); Executors.newScheduledThreadPool(1).scheduleAtFixedRate(() -> { new Thread(() -> { for (int i = 0; i < 1000; i++) { try { // 不干活，专门512kb的小对象 byte[] temp = new byte[1024 * 512]; Thread.sleep(new Random().nextInt(100)); // 随机睡眠200毫秒秒以内 } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); }, 100, 100, TimeUnit.MILLISECONDS); }}// 打包 mvn clean package// 服务器上运行 performance-1.0.0.jar

pom.xml

<?xml version="1.0" encoding="UTF-8"?><project xmlns="; xmlns:xsi="; xsi:schemaLocation=" ;> <modelVersion>4.0.0</modelVersion> <groupId>com.study.chapter-3</groupId> <artifactId>performance</artifactId> <version>1.1.0</version> <name>chapter-3</name> <description>性能优化章节代码</description> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.6.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-configuration-processor</artifactId> <optional>true</optional> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build></project>

application.yml

server: port: 8080

打包成jar，maven clean install;

（二）调优演示

① 虚拟机信息

4G内存双核 Centos7

② 配置环境 && 安装jdk环境

配置dns

安装阿里云仓库的yum

cd /etc/yum.repos.d/wget  CentOS-Base.repo CentOs-Base.repo.bak mv Centos-7.repo CentOs-Base.repo

安装jdk

vi pro.sh

shell脚本内容

#!/bin/bashSOFT_PATH=/opt/softif [ ! -d $SOFT_PATH ];thenmkdir $SOFT_PATHelseecho "文件夹已经存在"fiyum install -y wget #install jdk1.8cd $SOFT_PATHwget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2F; oraclelicense=accept-securebackup-cookie" ";tar -zxvf jdk* -C $SOFT_PATHcd jdk*JAVA_HOME=`pwd` #install maven3.2.3cd $SOFT_PATHwget  -zxvf apache-maven-3.2.3-bin.tar.gz -C $SOFT_PATHmv apache-maven-3.2.3 maven-3.2.3cd maven*MAVEN_HOME=`pwd`#install git 2.8.0cd $SOFT_PATHyum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel curl-devel perl-ExtUtils-CBuilder perl-ExtUtils- MakeMakerwget  -zxvf git-2.8.0.tar.gz -C $SOFT_PATHcd git*./configuremake installln -s /usr/local/bin/git /usr/bin/git#追加环境变量echo "export JAVA_HOME=${JAVA_HOME}" >> /etc/profileecho "export PATH=$""JAVA_HOME/bin:$""PATH" >> /etc/profileecho "export MAVEN_HOME=${MAVEN_HOME}" >> /etc/profileecho "export PATH=$""MAVEN_HOME/bin:$""PATH" >> /etc/profilesource /etc/profile#输出信息echo "-----source update-----"echo "java version"java -versionecho "maven version"mvn -vecho "-----path-----"echo "JAVA_HOME:"$JAVA_HOMEecho "MAVEN_HOME:"$MAVEN_HOMEsource /etc/profile

设置权限，通过脚本的方式安装jdk，maven

chmod 777 pro.sh./pro.shsource /etc/profile

安装 lrzsz 方便通过crt上传jar包

 yum -y install lrzsz

rz 上传jar包

② 启动jar包

设置1G的内存

java -Xmx1024m -jar performance-1.1.0.jar

③ 监控这个程序

jcmd查看正在运行的java程序

查看堆的使用情况，To Space中的used 是空的，因为总会有一个复制算法。使用率已经99%了。

jmap -heap 19587

如何去调优呢？调优的思路是什么？

④ GC 调优思路
1.分析场景

例如：启动速度慢；偶尔出现响应慢于平均水平或者出现卡顿。

2.确定目标

内存占用，低延时（web程序），吞吐量。

3.收集日志

通过参数配置收集GC日志（事后分析，一步一卡卡的潇洒），通过JDK（jstat）工具查看GC状态。

4.分析日志

使用工具辅助分析日志，查看GC次数，GC时间。

5.调整参数

切换垃圾收集器或者调整垃圾收集器参数。

（三）通用GC参数

-XX:ParallelGCThreads 并行GC线程数量（并行搞个跟CPU的数量一样多没关系）
-XX:ConcGCThreads 并发GC线程数量（GC在操作，业务代码也在抢）
不能设置的GC线程数和应用的线程数一样，大家都是抢资源的，抢一抢都没了。

-XX:MaxGCPauseMillis=n，最大GC停顿时间，这是个软目标，JVM将尽可能（但不保证）停顿小于这个时间，这个时间不能设置太大，如果设置10秒，就意味着程序10秒的时间程序都不在运行。本来停顿1秒，结果你设置1ms，GC也做不到，它只能尽量的调整新生代，老年代，survivior等的尽量靠拢你设置的时间。一般起不到什么大的效果。

-XX:GCTimeRatio:设置吞吐量大小，它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n，那么系统将花费不超过 1/(1+n) 的时间用于垃圾收集。如果你设置99秒。1秒GC，但是99秒生成的数据量比较大，1秒的GC解决不完，其实也是白扯。一般起不到什么大的效果。

-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例，默认8，如果新生代有100m，survivior就有10m，Eden区是80m。这个作用不大，很多时候GC需要自适应。

-XX:NewRatio:新生代和老年代的比，默认4，新生代:老年代=1:4，新生代占五分之一。这个作用不大，很多时候GC需要自适应。

-verbose:gc 、-XX:+printGC 打印GC的简要信息。
-XX:+PrintGCDetails 打印GC详细信息。已经被舍弃。
-XX:+PrintGCTimeStamps 打印GC发生的时间戳。已经被舍弃。
-Xloggc:log/gc.log 指定GC log的位置，以文件输出。（不可能跟控制台一起打印的，都是以文件的形式存储）。
XX:+PrintHeapAtGC 每次一次GC后，都打印堆信息。

（四）事后打印gc日志分析gc

① 命令收集gc信息

java -Xmx1024m -Xloggc:gc1.log -jar performance-1.1.0.jar

② 查看日志发现很多full gc

more gc1.log

③ 工具的方式查看gc

下载gc1.log到本地

#下载到默认的下载目录，在crt有设置sz gc1.log

④ 工具下载

GCViewer工具，辅助分析GC日志文件

java -jar gcviewer-1.36-SNAPSHOT.jar 

⑤ 加载gc日志文件⑥ 分析gc文件结果

gc 停顿时间26秒，gc次数3962次。没有并行gc的情况偶有都是0，full gc 3秒。full gc次数56 次。也就是整个gc耗时26+3 =29秒。

右下角是一个汇总，内存，停顿情况。停顿了29秒。暂停了4018次。 最大耗时133毫秒。full gc 综合23秒。gc paunses 年轻代 的情况。

总的内存713.5M，最大full gc后还有59.6M 释放了，fullgc 9.313MB 差不多9个G的内存被释放。年轻代一共释放了1276G的内存。最多的时候1秒有750MB的内存占用，年轻代就释放了。

比用肉眼看，界面更明显了。其实都是很好理解的。直接看官网看有解释的。

.

（五）实时打印gc日志分析gc

① 介绍

获取实时的gc信息情况。

② 命令

# 查找到performance-1.0.0.jar的进程号jcmd | grep "jar" | awk '{print $1}'# jmap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况jmap -heap $(jcmd | grep "jar" | awk '{print $1}')  jstat -gc -h10 $(jcmd | grep "jar" | awk '{print $1}') 1000

默认情况，实时监控结果：10秒内163（641-478）次YGC，11（33-24）次FullGC，总耗时2.185-1.602秒

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 38912.0 38400.0 33345.0 0.0 245760.0 0.0 210944.0 172272.4 35120.0 33550.8 4656.0 4334.2 478 7.215 24 1.602 8.81736352.0 36352.0 32321.0 0.0 249856.0 0.0 215040.0 197339.4 35120.0 33550.8 4656.0 4334.2 496 7.447 25 1.662 9.10936864.0 37376.0 0.0 30720.9 247808.0 0.0 212992.0 205039.2 35376.0 33555.5 4656.0 4334.2 513 7.665 27 1.727 9.39335328.0 35328.0 29248.9 0.0 251392.0 62523.4 236032.0 56434.7 35376.0 33555.5 4656.0 4334.2 530 7.872 28 1.857 9.72934816.0 34816.0 30720.9 0.0 253952.0 0.0 240128.0 54903.1 35376.0 33555.8 4656.0 4334.2 548 8.118 29 1.926 10.04333280.0 33792.0 0.0 0.0 256000.0 0.0 246272.0 54396.0 35376.0 33555.8 4656.0 4334.2 566 8.344 30 1.989 10.33333792.0 34304.0 0.0 27648.8 254464.0 0.0 246272.0 236809.6 35376.0 33555.8 4656.0 4334.2 585 8.571 31 1.989 10.56032768.0 32768.0 28736.9 0.0 256512.0 55225.3 255488.0 236302.0 35376.0 33555.8 4656.0 4334.2 604 8.800 31 2.052 10.85132256.0 32256.0 0.0 25152.8 258048.0 0.0 261632.0 229634.7 35376.0 33555.8 4656.0 4334.2 623 9.034 32 2.120 11.15432256.0 32256.0 22528.7 0.0 258560.0 86025.6 273408.0 175333.9 35376.0 33555.8 4656.0 4334.2 641 9.262 33 2.185 11.447

（六）调优操作

① 查看配置参数

调整配置，让gc更加高效。本质上调优就是不断的调整下的小参数，让我们程序更加平稳。

jpsjinfo -flags 11367

② 垃圾收集Parallel参数调优JDK 默认的收集器吞吐量优先

-XX:+UseParallelGC 新生代使用并行收集器-XX:+UseParallelOldGC 老生代使用并行收集器-XX:ParallelGCThread 设置用于垃圾回收的线程数-XX:+UseAdaptiveSizePollicy 打开自适应GC策略

查看默认自适应是否打开，发现是默认打开的。

java -XX:+PrintFlagsFinal -version| grep UseAdaptiveSizePolicy

调整GC的线程数，先查看当前gc线程的数量，当前是2

java -XX:+PrintFlagsFinal -version| grep ParallelGCThreads

调整GC的线程数为4

java -Xmx1024m -Xloggc:gc1.log -XX:ParallelGCThreads=4 -jar performance-1.1.0.jar

jstat -gc -h10 $(jcmd | grep "jar" | awk '{print $1}') 1000

调整GC线程数后，实时监控结果：10秒内148（2208 -2060 ）次YGC，0（56-56）次FullGC，总耗时28.545- 27.687 ≈ 0.9秒，比之前的还是有效果的。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 512.0 512.0 32.0 0.0 348160.0 45472.1 520192.0 46763.4 35120.0 33567.4 4656.0 4334.2 2060 23.275 56 4.412 27.687512.0 512.0 0.0 0.0 348160.0 325320.0 520192.0 67372.0 35120.0 33567.4 4656.0 4334.2 2077 23.363 56 4.412 27.776512.0 512.0 0.0 0.0 348160.0 272380.3 520192.0 91036.7 35120.0 33567.4 4656.0 4334.2 2093 23.465 56 4.412 27.877512.0 512.0 32.0 0.0 348160.0 0.0 520192.0 108533.2 35120.0 33567.4 4656.0 4334.2 2110 23.560 56 4.412 27.973512.0 512.0 0.0 0.0 348160.0 33031.4 520192.0 122469.6 35120.0 33567.4 4656.0 4334.2 2126 23.643 56 4.412 28.055512.0 512.0 0.0 64.0 348160.0 0.0 520192.0 137398.1 35120.0 33567.4 4656.0 4334.2 2143 23.737 56 4.412 28.149512.0 512.0 0.0 64.0 348160.0 0.0 520192.0 151846.5 35120.0 33567.4 4656.0 4334.2 2159 23.829 56 4.412 28.241512.0 512.0 0.0 32.0 348160.0 11482.9 520192.0 163718.9 35120.0 33567.4 4656.0 4334.2 2175 23.925 56 4.412 28.337512.0 512.0 32.0 0.0 348160.0 0.0 520192.0 164342.9 35120.0 33567.4 4656.0 4334.2 2192 24.033 56 4.412 28.445512.0 512.0 32.0 0.0 348160.0 7353.5 520192.0 165983.0 35120.0 33567.4 4656.0 4334.2 2208 24.133 56 4.412 28.545

在调整下，让gc的线程数为1

调整GC线程数后，实时监控结果：10秒内147（1237 -1090 ）次YGC，2（27-25）次FullGC，总耗时14.822- 13.764 ≈ 1秒，没有线程数量为4的时候好。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 8192.0 8192.0 5120.2 0.0 332800.0 0.0 185856.0 173817.8 35120.0 33532.8 4656.0 4336.3 1090 11.542 25 2.222 13.7647680.0 8192.0 6144.2 0.0 331776.0 157355.3 190976.0 34890.6 35120.0 33532.8 4656.0 4336.3 1105 11.623 26 2.296 13.9208704.0 8704.0 0.0 5664.2 331776.0 0.0 190976.0 54939.2 35120.0 33532.8 4656.0 4336.3 1121 11.749 26 2.296 14.0458192.0 8704.0 6176.2 0.0 330752.0 15717.3 190976.0 79595.9 35120.0 33532.8 4656.0 4336.3 1138 11.850 26 2.296 14.1478704.0 8704.0 6656.2 0.0 331776.0 34081.6 190976.0 102204.6 35120.0 33532.8 4656.0 4336.3 1154 11.953 26 2.296 14.2499216.0 9216.0 0.0 6688.2 329728.0 0.0 190976.0 124813.3 35120.0 33532.8 4656.0 4336.3 1171 12.053 26 2.296 14.3499216.0 9216.0 6176.2 0.0 330752.0 0.0 190976.0 144861.9 35120.0 33532.8 4656.0 4336.3 1188 12.155 26 2.296 14.4519216.0 9216.0 7200.2 0.0 330752.0 263039.0 190976.0 162862.4 35120.0 33532.8 4656.0 4336.3 1204 12.258 26 2.296 14.5548704.0 8704.0 0.0 0.0 330752.0 0.0 198144.0 24643.6 35120.0 33532.8 4656.0 4336.3 1220 12.361 27 2.371 14.7329216.0 9216.0 0.0 8224.2 330752.0 52984.5 198144.0 41620.2 35120.0 33532.8 4656.0 4336.3 1237 12.451 27 2.371 14.822

③ CMS改用CMS回收器

重要参数

CMSInitiatingOccupancyFraction： 触发CMS收集器的内存比例。比如60%的意思就是说，当内存达到60%，就会开始进行CMS并发收集。UseCMSCompactAtFullCollection： 这个前面已经提过，用于在每一次CMS收集器清理垃圾后送一次内存整理。CMSFullGCsBeforeCompaction： 设置在几次CMS垃圾收集后，触发一次内存整理。

调整成并发gc回收

java -Xmx1024m -Xloggc:gc1.log -XX:+UseConcMarkSweepGC -jar performance-1.1.0.jar

调整GC线程数后，实时监控结果：10秒内94（3088 -2794 ）次YGC，0（86-86）次FullGC，总耗时29.437- 27.304 ≈2秒，少量多次，高频回收，会抢占用户线程，根据实际需要进行调优。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 17024.0 17024.0 8709.4 0.0 136320.0 0.0 878208.0 98880.4 35220.0 33554.0 4756.0 4336.8 2794 25.993 86 1.311 27.30417024.0 17024.0 11266.7 0.0 136320.0 26893.3 878208.0 170056.3 35220.0 33554.0 4756.0 4336.8 2826 26.255 86 1.311 27.56617024.0 17024.0 9728.3 0.0 136320.0 0.0 878208.0 235086.6 35220.0 33554.0 4756.0 4336.8 2860 26.513 86 1.311 27.82417024.0 17024.0 0.0 10754.7 136320.0 18634.4 878208.0 300630.4 35220.0 33554.0 4756.0 4336.8 2893 26.771 86 1.311 28.08217024.0 17024.0 7680.2 0.0 136320.0 0.0 878208.0 367196.7 35220.0 33554.0 4756.0 4336.8 2926 27.014 86 1.311 28.32517024.0 17024.0 10752.3 0.0 136320.0 5167.9 878208.0 431716.0 35220.0 33554.0 4756.0 4336.8 2958 27.230 86 1.311 28.54117024.0 17024.0 8704.3 0.0 136320.0 0.0 878208.0 505963.0 35220.0 33554.0 4756.0 4336.8 2990 27.457 86 1.311 28.76817024.0 17024.0 9728.3 0.0 136320.0 0.0 878208.0 570993.8 35220.0 33554.0 4756.0 4336.8 3023 27.688 86 1.311 28.99917024.0 17024.0 6656.2 0.0 136320.0 0.0 878208.0 643192.8 35220.0 33554.0 4756.0 4336.8 3056 27.919 86 1.311 29.23017024.0 17024.0 10756.7 0.0 136320.0 0.0 878208.0 699007.2 35220.0 33554.0 4756.0 4336.8 3088 28.126 86 1.311 29.437

调整cms的并发数量。

java -Xmx1024m -Xloggc:gc1.log -XX:+UseConcMarkSweepGC -XX:ConcGCThreads=2 -jar performance-1.1.0.jar

调整GC线程数后，实时监控结果：10秒内79（4246 -3967）次YGC，0（81-81）次FullGC，总耗时40.011- 37.468 ≈3秒，加大了数量没有带来很显著的提升。因为线程有用户线程，GC线程，他们老发生争抢，

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 17024.0 17024.0 5635.3 0.0 136320.0 136237.3 878208.0 437623.5 35344.0 33560.9 4652.0 4338.5 3967 36.037 81 1.431 37.46817024.0 17024.0 0.0 9219.0 136320.0 125763.7 878208.0 445308.8 35344.0 33560.9 4652.0 4338.5 3997 36.325 81 1.431 37.75617024.0 17024.0 5637.7 5637.7 136320.0 0.0 878208.0 462209.5 35344.0 33560.9 4652.0 4338.5 4028 36.601 81 1.431 38.03217024.0 17024.0 9220.1 0.0 136320.0 62110.0 878208.0 475526.2 35344.0 33560.9 4652.0 4338.5 4059 36.875 81 1.431 38.30617024.0 17024.0 0.0 6144.2 136320.0 0.0 878208.0 484236.0 35344.0 33560.9 4652.0 4338.5 4089 37.156 81 1.431 38.58717024.0 17024.0 0.0 7680.2 136320.0 0.0 878208.0 496017.6 35344.0 33560.9 4652.0 4338.5 4120 37.453 81 1.431 38.88417024.0 17024.0 0.0 5632.2 136320.0 0.0 878208.0 506774.8 35344.0 33560.9 4652.0 4338.5 4153 37.710 81 1.431 39.14117024.0 17024.0 0.0 7683.0 136320.0 68343.6 878208.0 514971.7 35344.0 33560.9 4652.0 4338.5 4185 37.968 81 1.431 39.39917024.0 17024.0 0.0 8195.4 136320.0 0.0 878208.0 528288.3 35344.0 33560.9 4652.0 4338.5 4216 38.275 81 1.431 39.70617024.0 17024.0 0.0 9219.0 136320.0 0.0 878208.0 541605.8 35344.0 33560.9 4652.0 4338.5 4246 38.580 81 1.431 40.011

③ G1参数调优

JDK8以后主流的垃圾回收器，兼容吞吐量，超过50%的Java堆被实时数据占用，建议大堆（大小约为6GB或更大），且GC延迟要求有限的应用（稳定且可预测的暂停时间低于0.5秒）

java -Xmx1024m -Xloggc:gc1.log -XX:+UseG1GC -jar performance-1.1.0.jar

调整GC线程数后，实时监控结果：10秒内38（69 -31）次YGC，0次FullGC，总耗时0.577- 0.429 ≈100毫秒。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT  0.0 1024.0 0.0 1024.0 659456.0 28672.0 388096.0 381451.3 35196.0 33479.6 4732.0 4332.9 31 0.429 0 0.000 0.429 0.0 0.0 0.0 0.0 660480.0 26624.0 388096.0 159753.1 35196.0 33484.1 4732.0 4334.0 34 0.439 0 0.000 0.439 0.0 1024.0 0.0 1024.0 659456.0 31744.0 388096.0 337736.3 35196.0 33484.1 4732.0 4334.0 37 0.449 0 0.000 0.449 0.0 1024.0 0.0 1024.0 659456.0 27648.0 388096.0 181066.6 35196.0 33484.7 4732.0 4334.0 41 0.462 0 0.000 0.462 0.0 1024.0 0.0 1024.0 659456.0 9216.0 388096.0 109389.5 35196.0 33484.9 4732.0 4334.0 45 0.480 0 0.000 0.480 0.0 1024.0 0.0 1024.0 659456.0 21504.0 388096.0 160088.2 35196.0 33487.6 4732.0 4334.0 49 0.500 0 0.000 0.500 0.0 1024.0 0.0 1024.0 659456.0 34816.0 388096.0 373093.0 35196.0 33487.6 4732.0 4334.0 53 0.515 0 0.000 0.515 0.0 0.0 0.0 0.0 660480.0 32768.0 388096.0 238949.6 35196.0 33487.6 4732.0 4334.0 58 0.533 0 0.000 0.533 0.0 1024.0 0.0 1024.0 573440.0 35840.0 474112.0 473973.9 35196.0 33487.6 4732.0 4334.0 63 0.551 0 0.000 0.551 0.0 0.0 0.0 0.0 55296.0 3072.0 993280.0 138607.9 35196.0 33487.6 4732.0 4334.0 69 0.577 0 0.000 0.577

（六）运行时JIT编译器优化参数

① 介绍

JIT 编译指的是字节码编译为本地代码（汇编）执行，只有热点代码才会编译为本地代码。解释器执行借阅内存，反之可以使用编译执行来提升效率。

② 参数设置

-XX:+AggressiveOpts 允许jvm使用积极的性能优化功能-XX:-TieredCompilation 分层编译jdk8默认开启，jdk7默认关闭 client-Xmaxjitcodesize、-XX:ReservedCodeCacheSize 指定JIT编译代码的最大代码告诉缓存最大值-Xmixed 除了热方法之外，解释器执行所有字节码，热方法被便以为本机代码-XX:InitialCodeCacheSize 初始化编译后的汇编指令，缓存区大小，字节-XX:+PrintCompilation 打开编译日志 jstat -compiler pid-XX:CiCompilerCount JIT编译锁使用的线程数量-XX:+DoEscapeAnalysis 逃逸分析，默认打开。对代码的深度优化-XX:-inline 方法内敛，默认打开

PS：JVM参数调优是个很细心很耐心的工作，夜深人静的时候写文章的时候演示，平常的时候根本写不出来，太心累了，一个参数一个试穷举法，非java范畴，调优永远都是慢悠悠的，很多时候发现跟谈恋爱一样，初恋可能是最美好的，最可悲的是可能还没开始恋爱，都30多岁到了单身汉的年龄。调优主要是从线程的个数和空间的大小来进行。如果全部演示真的太多了。更多的时候代码的优化，平台，服务器，能做的事情还是比较少的，代码算法的优化才是主要的。