• 第一个参数 options ：-q 不输出类名、Jar名和传入main方法的参数；-m 输出传入main方法的参数；-l 输出main类或 Jar的全限名；-v 输出传入JVM的参数。
• 第二个参数 hostid ：主机或者是服务器的id，如果不指定，就默认为当前的主机或者是服务器。

• 如果是本地虚拟机进程，VMID和LVMID是一致的。
• 如果是远程虚拟机进程，那么vmid的格式应当是 ：

1.2 jstat：虚拟机统计信息监视工具

虚拟机统计信息监控工具；jstat监视虚拟机各种运行状态信息，可以显示本地或者是远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。语法格式如下：

jstat [ option vmid [interval[s|ms] [count]] ]

• 第一个参数 option：代表着用户希望查询的虚拟机信息，分为类加载、垃圾收集、运行期编译状况3类。

• 参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次。

假设需要每1000毫秒查询一次进程9344垃圾收集状况，一共查询2次，那命令应当是：

jstat -gcutil 9344 1000 2

• 第一个参数：option

• 第二个参数：pid 指定显示的进程id

1.5 jmap：java内存映像工具

生成堆转储快照（heapdump文件）；jmap（Memory Map for Java，内存映像工具），用于生成堆转存的快照，一般是heapdump或者dump文件。如果不适用jmap命令，可以使用-XX:+HeapDumpOnOutOfMemoryError参数，当虚拟机发生内存溢出的时候可以产生快照。或者使用kill -3 pid也可以产生。jmap的作用并不仅仅是为了获取dump文件，它可以查询finalize执行队列，java堆和永久代的详细信息，如空间使用率，当前用的哪种收集器。命令格式如下：

jmap [option] vmid

1.6 jhat：jvm堆转储快照分析工具

分析内存转储快照，不推荐使用，而且慢。由于这个工具功能比较简陋，运行起来也比较耗时，所以这个工具不推荐使用，推荐使用MAT。

1.7 JConsole：java监视与管理控制台

基于JMX的可视化管理工具；这个工具相比较前面几个工具，使用率比较高，很重要。它是一个java GUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。用java写的GUI程序，用来监控VM，并可监控远程的VM，非常易用，而且功能非常强。线程监控还可以检查死锁。

1.7.1 启动JConsole

命令行输入 jconsole，然后从下图选择进程(前提是在IDE工具先建立一个线程运行着)

然后我们选择了相应的选项之后，进入这个工具就会出现下面这个界面:

1.8 VisualVM：多合一故障处理工具

1.9 Arthas：aliyun开源工具

前面说过的jvisualvm等要进行远程连接需要在服务端项目开启时配置很多参数，而且如果线上环境是隔离的，那么本地工具是连接不到线上环境的。

Arthas是阿里开源的性能监控神器。阿尔萨斯在远程连接时不需要进行复杂的参数配置，可以在线排除问题，无需重启应用，可以动态跟踪java代码，实时监控JVM状态。

Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load(负载)、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。

开发文档：Arthas Install | arthas

1.9.1 Arthas Install

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

1.9.2 通过浏览器连接 arthas

Arthas 目前支持 Web Console，用户在 attach 成功之后，可以直接访问：http://127.0.0.1:8563/。

可以填入 IP，远程连接其它机器上的 arthas。

1.9.3 使用arthas定位问题

1.9.4 退出 arthas

如果只是退出当前的连接，可以用quit或者exit命令。Attach 到目标进程上的 arthas 还会继续运行，端口会保持开放，下次连接时可以直接连接上。

如果想完全退出 arthas，可以执行stop命令。

启动arthas之后， 选择要attach的进程之后控制台报错内容如下:

上一次没有通过stop完全退出arthas，然后再次attach与上一次不同的进程之后就会出现这个错误。

1.10 GCViewer 日志分析工具

git clone https://github.com/chewiebug/GCViewer.git
//或者用 IDEA打开项目后，用 maven进行打包
mvn clean pacakge
//得到一个 jar包
cd target

java -jar gcviewer-1.36.jar

-Xms60M -Xmx60M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/Users/xxx/Documents/logs/gc.log

1）图表

GCViewer 在图表（第一个选项卡）中显示多条线等，可以点击 View 按钮选择显示哪些线条，具体每个曲线的地方代表什么意思官网都讲的很清楚了。https://github.com/chewiebug/GCViewer GitHub - chewiebug/GCViewer: Fork of tagtraum industries' GCViewer. Tagtraum stopped development in 2008, I aim to improve support for Sun's / Oracle's java 1.6+ garbage collector logs (including G1 collector)

其中黑色的竖线表示 Full GC，这样的线越少越好。就像上图所示，Full GC 后老年代并没有释放多少空间，所以才会抛出 OOM 异常。

图表需要参照 这个view中的信息，其中包含full gc等相关信息，这个在本地开发的时候可以时不时拉出来看下是不是有问题，性能或者一些关键的参数都可以在图标上面一目了然：

2）数据面板

点击 Summary：

如果你的 Full GC 平均的暂停时间很长（大于1s），或者平均暂停间隔非常的短（小于10s），说明可能你的 GC 回收是有问题的，可能需要优化。

二、GC日志获取

在生产环境中，根据需要配置相应的参数来监控JVM运行情况。

三、gc日志分析

JVM和GC调优,总结下CMS的一些特点和要点,让我们先简单的看下整个堆年轻代和年老代的垃圾收集器组合（以下配合java8完美支持，其他版本可能稍有不同），其中标红线的则是我们要着重讲的内容：

3.1 ParNew and CMS

"Concurrent Mark and Sweep" 是CMS的全称，官方给予的名称是：“Mostly Concurrent Mark and Sweep Garbage Collector”;

年轻代：采用 stop-the-world mark-copy 算法(ParNew)；

年老代：采用 Mostly Concurrent mark-sweep 算法(CMS)；

设计目标：年老代收集的时候避免长时间的暂停；

3.1.1 Minor GC

我们来分析下对象晋升问题（原文中的计算方式有问题）：

开始的时候：整个堆的大小是 10885349K，年轻代大小是613404K，这说明老年代大小是 10885349-613404=10271945K，

收集完成之后：整个堆的大小是 10880154K，年轻代大小是68068K，这说明老年代大小是 10880154-68068=10812086K，

老年代的大小增加了：10812086-10271945=608209K，也就是说 年轻代到年老代promot了608209K的数据；

3.1.2 Full/Major GC

Phase 1: Initial Mark(初始标记)

这是CMS中两次stop-the-world事件中的一次。它有两个目标：一是标记老年代中所有的GC Roots；二是标记被年轻代中活着的对象引用的对象。

标记结果如下：

Phase 2: Concurrent Mark(并发标记)

这个阶段会遍历整个老年代并且标记所有存活的对象，从“初始化标记”阶段找到的GC Roots开始。并发标记的特点是和应用程序线程同时运行。并不是老年代的所有存活对象都会被标记，因为标记的同时应用程序会改变一些对象的引用等。

在上边的图中，一个引用的箭头已经远离了当前对象（current obj）。

四、性能调优

4.1 性能调优的层次

进行jvm调优之前，我们假设项目的架构调优和代码调优已经进行过或者是针对当前项目是最优的。这两个是jvm调优的基础，并且架构调优是对系统影响最大的 ，我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过jvm调优令其达到一个质的飞跃，这是不可能的。其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨”。

另外，在调优之前，必须得有明确的性能优化目标， 然后找到其性能瓶颈。之后针对瓶颈的优化，还需要对应用进行压力和基准测试，通过各种监控和统计工具，确认调优后的应用是否已经达到相关目标。

4.1.1 JVM调优前提

4.2 JVM调优流程（VisualVM+gc插件 / gcviewer日志分析工具）

调优的最终目的都是为了令应用程序使用最小的硬件消耗来承载更大的吞吐。jvm的调优也不例外，jvm调优主要是针对垃圾收集器的收集性能优化，令运行在虚拟机上的应用能够使用更少的内存以及延迟获取更大的吞吐量。当然这里的最少是最优的选择，而不是越少越好。

4.2.1 性能定义

要查找和评估器性能瓶颈，首先要知道性能定义，对于jvm调优来说，我们需要知道以下三个定义属性，依作为评估基础:

这三个属性中，其中一个任何一个属性性能的提高，几乎都是以另外一个或者两个属性性能的损失作代价，不可兼得，具体某一个属性或者两个属性的性能对应用来说比较重要，要基于应用的业务需求来确定。

4.2.2 性能调优原则

在调优过程中，我们应该谨记以下3个原则，以便帮助我们更轻松的完成垃圾收集的调优，从而达到应用程序的性能要求。

4.2.3 性能调优流程

以上就是对应用程序进行jvm调优的基本流程，我们可以看到，jvm调优是根据性能测试结果不断优化配置而多次迭代的过程。在达到每一个系统需求指标之前，之前的每个步骤都有可能经历多次迭代。有时候为了达到某一方面的指标，有可能需要对之前的参数进行多次调整，进而需要把之前的所有步骤重新测试一遍。

另外调优一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。以下我们针对每个步骤进行详细的示例讲解。

在JVM的运行模式方面，我们直接选择server模式，这也是jdk1.6以后官方推荐的模式。

在垃圾收集器方面，我们直接采用了jdk1.6-1.8 中默认的parallel收集器（新生代采用parallelGC,老生代采用parallelOldGC）。

4.2.3.1 确定内存占用

1）运行阶段

应用程序的运行阶段，我可以划分为以下三个阶段：

确定内存占用以及活跃数据的大小，我们应该是在程序的稳定阶段来进行确定，而不是在项目起初阶段来进行确定，如何确定，我们先看以下jvm的内存分配。

jvm堆中主要的空间，就是以上新生代、老生代、永久代组成，整个堆大小=新生代大小 + 老生代大小 + 永久代大小。 具体的对象提升方式，这里不再过多介绍了，我们看下一些jvm命令参数，对堆大小的指定。如果不采用以下参数进行指定的话，虚拟机会自动选择合适的值，同时也会基于系统的开销自动调整。

在设置的时候，如果关注性能开销的话，应尽量把永久代的初始值与最大值设置为同一值，因为永久代的大小调整需要进行FullGC 才能实现。

如前所述，活跃数据应该是基于应用程序稳定阶段时，观察长期存活与对象在java堆中占用的空间大小。

采用jvm默认参数启动，是为了观察应用程序在稳定阶段的所需要的内存使用。

如何才算稳定阶段？

一定得需要产生足够的压力，找到应用程序和生产环境高峰符合状态类似的负荷，在此之后达到峰值之后，保持一个稳定的状态，才算是一个稳定阶段。所以要达到稳定阶段，压力测试是必不可少的。

在确定了应用出于稳定阶段的时候，要注意观察应用的GC日志，特别是Full GC 日志。

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -Xloggc:/Users/wangjiafu/logs/gc.log

必须得有FullGC 日志，如果没有的话，可以采用监控工具强制调用一次，或者采用以下命令，亦可以触发：jmap -histo:live pid

在稳定阶段触发了FullGC我们一般会拿到如下 GC 日志信息:

以上是发生 Minor GC 的 GC 是日志，如果发生 Full GC 呢，格式如下:

知道了 GC 日志怎么看，我们就可以根据 GC 日志有效定位问题了，如我们发现 Full GC 发生时间过长，则结合我们上文应用中打印的 OOM 日志可能可以快速定位到问题。

从以上gc日志中，我们大概可以分析到，在发生fullGC之时，整个应用的堆占用以及GC时间，当然了，为了更加精确，应该多收集几次，获取一个平均值。或者是采用耗时最长的一次FullGC来进行估算。在上图中，fullGC之后，老年代空间占用在93168kb（约93MB），我们以此定为老年代空间的活跃数据。

其他堆空间的分配，基于以下规则来进行：

java -Xms373m -Xmx373m -Xmn140m -XX:PermSize=5m -XX:MaxPermSize=5m

4.2.3.2 延时调优

在确定了应用程序的活跃数据大小之后，我们需要再进行延迟性调优，因为对于此时堆内存大小，延迟性需求无法达到应用的需要，需要基于应用的情况来进行调试。

在这一步进行期间，我们可能会再次优化堆大小的配置，评估GC的持续时间和频率、以及是否需要切换到不同的垃圾收集器上。

1）系统延时需求

在调优之前，我们需要知道系统的延迟需求是那些，以及对应的延迟可调优指标是那些。

以上中，平均停滞时间和最大停顿时间，对用户体验最为重要，可以多关注。

基于以上的要求，我们需要统计以下数据：

2）优化新生代的大小

比如如上的gc日志中，我们可以看到Minor GC的平均持续时间=0.069秒，MinorGC 的频率为(3.113-0.388)/7=0.389秒一次。

为了降低改变新生代的大小对其他区域的最小影响。在改变新生代空间大小的时候，尽量保持老年代空间的大小。比如此次减少了新生代空间10%的大小，应该保持老年代和永久代的大小不变化，第一步调优后的参数如下变化：

3）优化老年代的大小

同上一步一样，在优化之前，也需要采集gc日志的数据。此次我们关注的是FullGC的持续时间和频率。

上图中，我们可以看到：

没有FullGC日志时，可以通过 对象提升率 计算FullGC的持续时间和频率：比如上述中启动参数中，我们的老年代大小=233Mb。那么需要多久才能填满老年代中这233Mb的空闲空间取决于新生代到老年代的提升率。

每次提升老年代占用量=每次MinorGC 之后 java堆占用情况 减去 MinorGC后新生代的空间占用

对象提升率=平均值（每次提升老年代占用量) / 老年代空间

有了对象提升率，我们就可以算出填充满老年代空间需要多少次minorGC，大概一次fullGC的时间就可以计算出来了。

比如：

FullGC的预期最差频率时长可以通过以上两种方式估算出来，可以调整老年代的大小来调整FullGC的频率，当然了，如果FullGC持续时间过长，无法达到应用程序的最差延迟要求，就需要切换垃圾处理器了。具体如何切换，下篇再讲，比如切换为CMS，针对CMS的调优方式又有会细微的差别。

4.2.3.3 吞吐量调优

吞吐量=运行用户代码时间 / (运行用户代码时间+垃圾收集时间)；虚拟机总共运行100分钟，其中gc花掉1分钟，则吞吐量就是 99% 。

经过上述漫长 调优过程，最终来到了调优的最后一步，这一步对上述的结果进行吞吐量测试，并进行微调。

吞吐量调优主要是基于应用程序的吞吐量要求而来的，应用程序应该有一个综合的吞吐指标，这个指标基于真个应用的需求和测试而衍生出来的。当有应用程序的吞吐量达到或者超过预期的吞吐目标，整个调优过程就可以圆满结束了。

如果出现调优后依然无法达到应用程序的吞吐目标，需要重新回顾吞吐要求，评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。

对于垃圾收集器来说，提升吞吐量的性能调优的目标就是就是尽可能避免或者很少发生FullGC 或者Stop-The-World压缩式垃圾收集（CMS），因为这两种方式都会造成应用程序吞吐降低。尽量在MinorGC 阶段回收更多的对象，避免对象提升过快到老年代。

五、JVM常用设置参数

5.1 栈、堆设置的常用参数

5.2 收集器设置

5.3 垃圾回收统计信息

5.4 并行收集器设置

5.5 并发收集器设置