前言

JVM系列前5篇文章相对偏向于理论，从这篇开始将会结合实际场景进行分析以及如何对JVM进行调优。

JVM参数

所谓的JVM调优说白了就是去设置一个合理的，适合当前系统的JVM所提供的参数。从总体上来说JVM参数可以分为三大类：标准参数，-X参数，-XX参数。

标准参数

以“-”开头的参数称之为标准参数，标准参数是任何一个JDK版本都支持的参数，比较稳定，一般不会随着jdk版本的变化而变化。
比如：

-version
-help
-server
-cp

-X参数

以-X开头的参数是在特定版本HotSpot支持的命令，jdk版本变化之后，参数可能会发生变化。这个参数用的比较少。如以下几种：

-Xint   解释执行
-Xcomp  第一次使用就编译成本地代码
-Xmixed  混合模式，JVM自己来决定

这种参数用的比较少，了解就可以了，在这里不做演示

-XX参数

-XX是一种不稳定的参数，下一个版本可能会取消。-XX是JVM调优时的主要参数。
-XX参数分为Boolean型和非Boolean型。

Boolean型

Boolean类型的-XX参数使用格式为：

-XX:[+-]<name>      +或-表示启用或者禁用name属性

如：

-XX:+UseConcMarkSweepGC  表示启用CMS类型的垃圾回收器
-XX:+UseG1GC             表示启用G1类型的垃圾回收器
-XX:+PrintFlagsFinal     表示打印出所有的JVM参数信息

打印所有JVM参数

我们用-XX:+PrintFlagsFinal去打印一下所有的参数出来看一下：
任意新建一个Java类：

package com.zwx.jvm;public class TestJVMParam {public static void main(String[] args) {System.out.println(11);}
}

本人用的是IntelliJ IDEA工具，选择：Run–>Edit Configurations，然后点击左边的+号，选择Application，出现如下所示界面，加入JVM参数：

然后运行main方法，就会打印出所有参数（有700多个）：

注意：上图中打印出来的参数中“=”表示默认值，“:=”表示被用户或JVM修改后的值

非Boolean型

非Boolean类型的-XX参数的使用格式为：

-XX<name>=<value>    name表示属性，value表示属性对应的值

如：

-XX:MaxMetaspaceSize=5M    设置最大永久代空间大小(jdk1.8)

其他参数

还有其他一些我们非常常用的参数，比如：-Xms，-Xmx，-Xss，但是实际上这几种参数也是属于-XX参数，这几种写法不过就是一种为了方便而设置的简写形式。所以在上面打印出来的参数中搜索-Xms，-Xmx，-Xss是搜索不到的。

-Xms1000等价于-XX:InitialHeapSize=1000
-Xmx1000等价于-XX:MaxHeapSize=1000
-Xss100等价于-XX:ThreadStackSize=100

常用JVM参数

参数	含义	说明
-XX:CICompilerCount=3	最大并行编译数	大于1时可以提高编译速度，但会影响系统稳定性，增加JVM崩溃的可能
-XX:InitialHeapSize=100M	初始化堆大小	简写-Xms100M
-XX:MaxHeapSize=100M	最大堆大小	简写-Xmx100M
-XX:NewSize=20M	设置年轻代的大小	-
-XX:MaxNewSize=50M	年轻代最大大小	-
-XX:OldSize=50M	设置老年代大小	-
-XX:MetaspaceSize=50M	设置方法区大小	jdk1.8中才有，利用元空间实现方法区
-XX:MaxMetaspaceSize=50M	方法区最大大小	jdk1.8中才有，利用元空间实现方法区
-XX:+UseParallelGC	设置Parallel Scavenge为新生代收集器，系统默认会选择Parallel Old为老年代垃圾收集器	这个组合是jdk1.8中默认组合，吞吐量优先的垃圾收集器
-XX:+UseParallelOldGC	设置Parallel Old为老年代垃圾收集器，系统默认会选择Parallel Scavenge为新生代垃圾收集器	-
-XX:+ParallelGCThreads	设置并行收集垃圾的线程数	一般设置为和cpu个数相同，这个参数也适用于CMS收集器
-XX:+UseConcMarkSweepGC	选择CMS为老年代收集器，同时系统默认会选择ParNew为新生代收集器	如果CMS收集器出现了Concurrent Mode Failure，则会切换到Serial Old为老年代收集器
-XX:+CMSScavengeBeforeRemark	CMS收集器在最终标记前发生一次Young GC	-
-XX:CMSMaxAbortablePrecleanTime	CMS收集器的可中断预清理阶段最长停留时间	默认是5000，单位是毫秒
-XX:+UseG1GC	使用G1作为收集器	同时适用于新生代和老年代，是一款停顿时间优先的垃圾收集器，jdk1.9中默认垃圾收集器
-XX:NewRatio	新老生代的比值	比如-XX:Ratio=4，则表示新生代:老年代=1:4
-XX:SurvivorRatio	两个S区和Eden区的比值	比如-XX:SurvivorRatio=8，也就是(S0+S1):Eden=2:8
-XX:+HeapDumpOnOutOfMemoryError	启动堆内存溢出打印	当JVM堆内存发生溢出时，也就是OOM，自动生成dump文件
-XX:HeapDumpPath=heap.hprof	指定堆内存溢出打印目录	表示在当前目录生成一个heap.hprof文件
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:$CATALINA_HOME/logs/gc.log	打印出GC日志	不同的垃圾收集器总体格式相同，但是会有小差别，G1相比较其他收集器，差别较大
-Xss128k	设置每个线程的堆栈大小	经验值是3000-5000最佳
-XX:MaxTenuringThreshold=6	新生代对象进入年老代的最大临界值	默认15
-XX:InitiatingHeapOccupancyPercent	启动并发GC周期时堆内存使用占比	G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示”一直执行GC循环”. 默认值为 45
-XX:G1HeapWastePercent	允许的浪费堆空间的占比	用于G1垃圾收集器。默认是10%，如果并发标记可回收的空间小于10%,则不会触发MixedGC
-XX:ConcGCThreads=n	并发垃圾收集器使用的线程数量	默认值随JVM运行的平台不同而不同
-XX:G1MixedGCLiveThresholdPercent=65	混合垃圾回收周期中要包括的旧区域设置占用率阈值	默认占用率为 65%
-XX:G1MixedGCCountTarget=8	设置标记周期完成后，对存活数据上限为G1MixedGCLIveThresholdPercent的旧区域执行混合垃圾回收的目标次数	默认8次混合垃圾回收，混合回收的目标是要控制在此目标次数以内
-XX:G1OldCSetRegionThresholdPercent=1	描述Mixed GC时，Old Region被加入到CSet中	默认情况下，G1只把10%的Old Region加入到CSet中

常用命令监控工具

jdk中的bin目录下提供了许多功能强大的工具可以帮助我们监控虚拟机的使用情况，掌握了这些常用工具的使用可以帮助我们更快更直观的分析问题。

工具和参数都是在不断使用的过程中掌握的，并不需要一下子就全部看完，可以大致浏览有个印象，建议大家可以收藏本篇文章，后续需要用到的时候方便查看

以下的演示均是基于linux环境下jdk1.8版本进行演示，不能环境和版本可能会有较大差异。

Java(TM) SE Runtime Environment (build 1.8.0_151-b12)

jps

jps：JVM Process Status Tool，一款用于查看java进程的工具。这款工具的功能非常简单，就是查看当前环境下运行的java服务的进程id和名称，一般其他命令使用前都会先使用jps命令获取java进程信息。
如下图所示：

jps参数主要有如下选项：

选项	说明
-q	只输出进程id
-m	输出虚拟机启动时传递给main()方法的参数
-l	输出主类的全名，如果进行执行的是jar包，则输出jar包路径
-v	输出启动虚拟机的参数

jstat

jstat：JVM Statistics Monitoring，一款用于监视虚拟机各种运行状态统计信息工具。主要可以显示如下信息：虚拟机进程的类装载、内存、垃圾收集、JIT编译等运行数据信息。

查看类装载信息

jstat -class PID 1000 10 //查看某个java进程的类装载信息，每1000毫秒输出一次，共输出10次

查看垃圾收集信息

jstat -gc PID 1000 10

上图中就显示个各个区以及垃圾回收的情况,具体代表含义如下：
注意：C表示Capacity(容量)，U表示Used(已使用大小)

• 1、S0C、S1C表示的是Survive区的S0和S1大小(Capacity)
• 2、S1U、S2U表示已使用空间大小(Used)
• 3、EC、EU分别表示Eden区总容量和已使用容量大小
• 4、OC、OU分别表示老年代总空间大小和已使用大小
• 5、MC、MU：表示方法区(jdk1.8中通过Metaspace实现)的总空间大小和已使用大小
• 6、CCSC、CCSU：表示压缩类空间总大小和已使用大小
• 7、YGC、YGT：新生代GC次数和GC总耗时
• 8、FGC、FGCT：Full GC次数和Full GC总耗时
• 9、GCT：GC总消耗时间

如果对上面含义中涉及到的各种分区不了解的，可以点击这里详细了解。

jstat参数常用选项

参数	说明
-class	查看类加载/卸载数量和大小，以及所耗费的时间
-gc	统计堆内各个分区的总大小及已使用大小，以及不同分区的次数和耗时等信息
-gccapacity	同-gc相似，但是主要统计Java堆各个区域使用到的最大和最小空间
-gcutil	同-gc类似，但是主要统计已使用空间占总空间的大小
-gccause	同-gcutil一样，只是会额外输出上一次发生GC原因
-gcnew	统计新生代的GC情况
-gcnewcapacity	同-gcnew类似，但是主要统计使用到的最大和最小空间
-gcold	统计老年代的GC情况
-gcoldcapacity	同-gcold类似，但是主要统计使用到的最大和最小空间
-gcpermcapaticy	统计永久代使用到的最大和最小空间
-compiler	输出JIT编译器编译过得方法和耗时等信息
-printcompilation	输出已经被JIT编译的方法

jstack

jstack：Stack Trace for Java，一款用于生成当前时刻的线程状态信息的快照工具。这个对于用来分析当前线程状态时非常有用的，比如说是否有哪个线程阻塞了，或者说是否发生死锁等信息。
如：

jstack PID

可以清晰的看到当前线程的状态。另外线程的名字也会打印出来，所以在我们自己创建线程的时候建议是采用自定义的名称，这样如果有异常我们可以很容易的知道是哪个线程出了问题。

jstack参数常用选项

参数	说明
-F	当正常请求不被响应时，强制输出线程堆栈
-l	除堆栈外，显示关于锁的附加信息
-m	当调用本地方法时，可以显示C/C++的堆栈

jinfo

jinfo：Configuration Info For Java，一款用于实时查看和修改JVM参数的工具。

注意，如果是修改的话，只能用我们上面使用命令打印出来参数中的manageable类型才可以被修改。

jinfo -flag name PID 查看某个java进程的name属性的值
jinfo -flags PID 查看已经赋值的JVM参数

针对Boolean类型的-XX参数修改命令为：

jinfo -flag [+|-]name PID

针对非Boolean类型的-XX参数修改命令为：

jinfo -flag name=value PID

如：

jmap

jmap：Memory Map for Java，一款用于生成堆转储快照即dump文件的命令。
如：

jmap -heap PID  //打印出堆内存相关信息

jmap -dump:format=b,file=/usr/heap.hprof PID //生成dump文件

但是其实上面的常用参数中也有一个参数可以设置，一旦发生OutOfMemoryError之后就会自动生成dump文件，这对我们分析生产环境发生OOM的原因是非常重要的。
如下，我们再idea中进行设置自动生成dump文件：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heap.hprof

我们利用在JVM系列文章1中所提供的一个堆内存的例子来进行演示一下：


运行之后发生OOM异常，然后可以找到对应目录下已经生成了dump文件。

既然我们生成了dump文件，肯定是要对文件进行分析的，但是我们怎么分析这个文件呢？因为直接打开时乱码的，所以我们肯定需要一款工具来对dump文件进行分析

jhat

jhat：JVM Heap Analysis Tool，一款用来分析dump文件的工具。
如：

jhat heap.hprof

然后访问地址：http://localhost:7000/。

可以看到，这款工具所展示的信息比较简单，而且因为是命令形式的，所以很难直接分析出问题，一般情况如果有其他工具可以选择的话，并不建议使用这款工具来分析，接下来我们就来看一看可视化工具的使用

可视化监控工具

JConsole工具

JConsole：Java Monitoring and Management Console，是一款JDK自带的可视化监控工具。其实就是把上面的比如jstat,jstack等命令工具统计的信息可视化了，主要可以查看java应用程序的运行概况、监控堆信息、永久区使用情况、类加载情况等信息。

JConsole使用方式可以直接在命令行中输入命令：jconsole，或者直接找到jdk安装目录下找到jconsole.exe执行文件，双击打开即可。

本地连接的话很简单，选中一个服务双击即可，如果是远程连接，需要远程的Java服务在启动的时候就配置JMX相关连接参数。
进入之后看到如下界面：

可以看到顶部有6个标签可以切换，在这里就不详细去介绍每个地方有什么用了，自己去尝试的话其实是一目了然的，可以看到内存各个区间的使用情况，线程信息(线程名字都会展示)，以及类加载等信息。

VisualVM工具

VisualVM：All-in-one Java TroubleshootingTool，是JDK发布的一款功能最强大的运行监控故故障处理工具，正如名字所说的All-in-one，可以预见这是一款功能非常齐全的工具。
VisualVM主要功能如下：

• 显示虚拟机进程及进程的配置环境信息(jps、jinfo功能)。
• 监视应用程序的CPU、GC、堆、方法区和线程信息(jstat、jstack功能)。
• dump文件生成及分析(jmap、jhat功能)。
• 方法级的程序性能分析，可以找出被调用最多，运行时间最长的方法。
• 离线程序快照：收集程序运行时配置、线程dump、内存dump等信息建立一个快照，并可以将快照发送开发者处进行Bug反馈
• 插件化处理，可以有无限扩展的可能性

打开VisualVM工具的方式可以直接在命令行中输入命令：jvisualvm，或者直接找到jdk安装目录下找到jvisualvm.exe执行文件，双击打开即可。

打开之后在左边选择自己的本地或者远程应用(同样需要远程服务支持JMX服务)之后，可以看到右边界面，注意，默认只有前面5个页签，最后一个页签是插件加入进来的，不同的插件可以看到不同的功能，我这边选择的插件是com-sun-tools-visualvm-modules-visualgc.nbm插件，这是一个比较有意思的插件，我们在之前分析Java堆内存划分的一篇文章中提到了一个对象的在堆内的流转图，这个插件打开之后可以动态演示堆内各个区域内存变化，感兴趣的可以尝试下。

插件使用和下载

点击主界面工具栏内：工具–>插件–>已下载–>添加插件，然后安装即可，如下图：

安装之后重新打开就可以看到多了一个页签，打开之后可以实时监控内存变化

在插件页面点击设置可以看到最新的插件下载地址(需要vpn才能连接)：

分析dump文件

假如生产环境发生OutOfMemoryError，我们拿到dump文件之后，就可以借助VisualVM来使用，点击工具栏中文件–>装入(注意要选择文件类型)，然后找到对应的dump文件就可以打开了

打开之后点击“类”：

可以看到是Integer对象撑爆了内存，因为上面的例子是是一个非常简单的demo，就是不断地往list中添加了Integer数据，所以结合工具可以非常清晰的看到是这个对象出了问题，从而定位到问题所在。

这个工具也可以直接dump文件：

这个工具也可以实时设置自动dump文件分析：

总之这是款非常强大的工具，还有其他许多功能，而且插件化工作原理使得其提供了无限的功能扩展，有兴趣的可以自己去官网下载不同的插件下来进行试用

其他工具

除了JVM官方提供的工具，还有其他第三方也提供了一些非常优秀的工具可以帮助我们更好的分析dump文件，比如说阿里巴巴提供的在线实时分析工具Arthas，还有 MAT，Histogram等都是非常优秀的工具。

总结

本文主要介绍了一些JVM的一些常用参数的使用，以及JVM提供的一些常用的监控工具，并且利用一个OOM例子结合工具来讲述了如何分析OOM时的dump文件，当然，本文的主要目的是告诉大家有哪些工具可以使用，但是对一个工具的使用并没有非常详细的介绍，大家都是程序员，相信只要知道了有这么一款工具，使用的时候也可以非常容易上手，关键在于实践，多使用才能积累经验。工具毕竟只是工具，只是可以更好的帮助我们分析问题，更重要的是发现问题之后该如何针对问题进行修改和优化，这才是使用工具的目的。
下一篇，将介绍一下如何分析GC日志，毕竟要想对JVM调优，GC日志是必须要学会进行查看分析的。
请关注我，和孤狼一起学习进步。