一直没有做过jvm监控， 总以为要找些专门的工具才能做jvm监控， 如jprofile之类的工具， 但这类工具都是收费的。

经过查找，发现其实sun的jdk中就带有这类工具，从jdk5开始命令行有了jstat，jps，jstatd，图形监控有了jconsole；而到了jdk6，命令有了jmap, jinfo, jstack，图形有了jvisualvm。经过简单试用，这些命令+图形工具 已经足够强大， 能满足一般的监控要求了，如对各类内存、垃圾回收、线程状态的监控。

命令：

以下转自：http://hqman.iteye.com/blog/167796

jstatd
启动jvm监控服务。它是一个基于rmi的应用，向远程机器提供本机jvm应用程序的信息。默认端口1099。
实例：jstatd -J-Djava.security.policy=my.policy

my.policy文件需要自己建立，内如如下：
grant codebase “file:$JAVA_HOME/lib/tools.jar” {
permission java.security.AllPermission;
};
这是安全策略文件，因为jdk对jvm做了jaas的安全检测，所以我们必须设置一些策略，使得jstatd被允许作网络操作

jps
列出所有的jvm实例
实例：
jps
列出本机所有的jvm实例

jps 192.168.0.77
列出远程服务器192.168.0.77机器所有的jvm实例，采用rmi协议，默认连接端口为1099
（前提是远程服务器提供jstatd服务）

输出内容如下：
jones@jones:~/data/ebook/java/j2se/jdk_gc$ jps
6286 Jps
6174  Jstat

jconsole
一个图形化界面，可以观察到java进程的gc，class，内存等信息。虽然比较直观，但是个人还是比较倾向于使用jstat命令（在最后一部分会对jstat作详细的介绍）。

jinfo（linux下特有）
观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数
实例：jinfo 2083
其中2083就是java进程id号，可以用jps得到这个id号。
输出内容太多了，不在这里一一列举，大家可以自己尝试这个命令。

jstack（linux下特有）
可以观察到jvm中当前所有线程的运行情况和线程当前状态
jstack 2083
输出内容如下：

jmap（linux下特有，也是很常用的一个命令）
观察运行中的jvm物理内存的占用情况。
参数如下：-heap：打印jvm heap的情况
*-histo：*打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
*-histo：live ：*同上，但是只答应存活对象的情况
*-permstat：*打印permanent generation heap情况

命令使用：
jmap -heap 2083
可以观察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的内存使用情况
输出内容：

jmap -histo 2083 ｜ jmap -histo:live 2083
可以观察heap中所有对象的情况（heap中所有生存的对象的情况）。包括对象数量和所占空间大小。
输出内容：

写个脚本，可以很快把占用heap最大的对象找出来，对付内存泄漏特别有效。

jstat
最后要重点介绍下这个命令。
这是jdk命令中比较重要，也是相当实用的一个命令，可以观察到classloader，compiler，gc相关信息
具体参数如下：
-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
-printcompilation：不知道干什么的，一直没用过。

jstat也提供远程能力，

a)使用 jps 查看远端机器有哪些 JVM 进程在使用当中，命令如下：

jps 172.25.1.24 // 远端机器的 IP 地址或名称

屏幕输入如下：

13686 Jstatd

14115 XXXJavaServer

15117 Jserver

b)从上面可以看到远端机器的 Jstatd 进程已经启动起来了。我们就可以使用 jstat 对相关进程的具体情况进行查看。

Jstat 命令用法如下：

jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

解释如下：

Option 包括以下选项：

-class

-compiler

-gc

-gccapacity

-gccause

-gcnew

-gcnewcapacity

-gcold

-gcoldcapacity

-gcpermcapacity

-gcutil

-printcompilation

Vmid 就是 jps 查看到的进程 id ，如上 Jserver 的进程 id 是 15117 。

Interval 是时间间隔，单位为毫秒， 1000 就是一秒。

Count 就是需要查看的次数。

例子假设我们需要查看 172.25.1.24 机器 vmid 为 15117 的 gc 的情况，可以输入下面的命令：

jstat -gc 15117@172.25.1.24 1000 3

然后你能看到四行信息（一行为 title ，剩下的就是你要的信息了），仔细看看就可以发现很多信息的了。

c) jstat还有一个可视化的监控包， 叫做jvmstat ，可以从sun的主页下载到。下载好了后，解压到任意目录。

执行 visualgc <pid> ，其实命令跟jstat很像，也可以监控到远程主机。然后就可以看到可视化的监控窗口。还挺酷的。

一般比较常用的几个参数是：
jstat -class 2083 1000 10 （每隔1秒监控一次，一共做10次）
输出内容含义如下：

jstat -gc 2083 2000 20（每隔2秒监控一次，共做10）
输出内容含义如下：

输出内容：

图形：

visualvm

http://www.iteye.com/topic/516447

如果是本地监控，则可以直接在本地的 窗口中看到java应用程序。双击点开即可打开监控窗口。

我们再看一下图1，左边的窗口中，第二个节点—Remote，它可以用来操作远程机器。远程机器需要启动一个daemon:jstatd

1、远程机器启动jstatd

1.1、        首先需要准备一个java.policy文件，保存到如/home/admin/jstatd.java.policy

jps 192.168.0.77
列出远程服务器192.168.0.77机器所有的jvm实例，采用rmi协议，默认连接端口为1099
（前提是远程服务器提供jstatd服务）

输出内容如下：
jones@jones:~/data/ebook/java/j2se/jdk_gc$ jps
6286 Jps
6174  Jstat

jconsole 
一个图形化界面，可以观察到java进程的gc，class，内存等信息。虽然比较直观，但是个人还是比较倾向于使用jstat命令（在最后一部分会对jstat作详细的介绍）。

jinfo （linux下特有）
观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数
实例：jinfo 2083
其中2083就是java进程id号，可以用jps得到这个id号。
输出内容太多了，不在这里一一列举，大家可以自己尝试这个命令。

jstack （linux下特有）
可以观察到jvm中当前所有线程的运行情况和线程当前状态
jstack 2083
输出内容如下：

jmap （linux下特有，也是很常用的一个命令）
观察运行中的jvm物理内存的占用情况。
参数如下：-heap ：打印jvm heap的情况
-histo： 打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
-histo：live ： 同上，但是只答应存活对象的情况
-permstat： 打印permanent generation heap情况

命令使用：
jmap -heap 2083
可以观察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的内存使用情况
输出内容：

jmap -histo 2083 ｜ jmap -histo:live 2083
可以观察heap中所有对象的情况（heap中所有生存的对象的情况）。包括对象数量和所占空间大小。
输出内容：

写个脚本，可以很快把占用heap最大的对象找出来，对付内存泄漏特别有效。

jstat 
最后要重点介绍下这个命令。
这是jdk命令中比较重要，也是相当实用的一个命令，可以观察到classloader，compiler，gc相关信息
具体参数如下：
-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
-printcompilation：不知道干什么的，一直没用过。

一般比较常用的几个参数是：
jstat -class 2083 1000 10 （每隔1秒监控一次，一共做10次）
输出内容含义如下：

jstat -gc 2083 2000 20（每隔2秒监控一次，共做10）
输出内容含义如下：

输出内容：

JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jstat

一、What

JDK 本身提供了很多很方便的 JVM 性能调优工具，如 VisualVM、Jconsole、jps、jstack、jmap、jhat、Jstat、jprof等。

可以帮我们解决下列问题：

• OutofMemory 内存不足
• 内存泄漏
• 线程死锁
• 锁争用（Lock Contention）
• java 进程消耗 CPU 过高

1.   Jstack（查看线程）

1.1 作用：

jstack主要用来抓取 Java JVM 中 某个进程 某一时刻 线程堆栈信息。其实就是抓取 thread dump 文件。

    thread dump： 诊断 java 应用问题的工具，可以显示 Java JVM中的所有线程在某一个时间点的快照文件。

1.2 内容：

线程标识，运行状态，调用的堆栈、调用的堆栈包含完整的类名、所执行的方法、还有源代码的行数。

Sun JVM 常见线程状态：

Runnable（R）: 当前可以运行的线程。

Waiting on monitor（CW）： 线程主动 wait

Waiting for monitor entry（MW）：线程等锁

JVM 中的 thin lock, fat lock, spin lock, tasuki lock:

1.3 Demo：

“process reaper” daemon prio=10 tid=0x00007f3d7014b800 nid=0x8b80a waiting on condition [0x00007f3dc68f0000]

java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

– parking to wait for  <0x00000000f007cfb0> (a java.util.concurrent.SynchronousQueue$TransferStack)

at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)

at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)

at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)

at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)

process reaper: 线程名称

daemon: 线程类型，守护线程

prio: 线程优先级

tid: thread id，JVM 中线程唯一标识

nid: native thread id，系统中线程唯一标识

waiting on condition: 线程状态

at…: 堆栈信息

Jstack 的目的主要是抓取 thread dump 文件然后使用工具进行分析。

1.4 常见线程：

    Attach Listener：负责接收外部命令，用户第一次执行 JVM 命令的时候得到启动。

    Signal Dispather：Attach Listener 接收到外部命令交给 Signal Dispather 进行分发到各个不同的模块处理，并且返回处理结果。

    CompilerThread0：实时编译卸载 class，JVM 会启动多个线程来处理这部分工作，线程名称后面的数字也会累加。

    Concurrent Mark-Sweep GC Thread：并发标记清除垃圾回收器线程（CMC GC），该线程主要针对老年代垃圾回收

    Finalizer线程：垃圾收集前，调用对象的finalize()方法

• 只有当开始一轮垃圾收集时，才会开始调用finalize()方法；因此并不是所有对象的finalize()方法都会被执行
• 该线程也是daemon线程，因此如果虚拟机中没有其他非daemon线程，不管该线程有没有执行完finalize()方法，JVM也会退出
• JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象（Reference的实现），并放入ReferenceQueue，由Finalizer线程来处理；最后将该Finalizer对象的引用置为null，由垃圾收集器来回收
• JVM为什么要单独用一个线程来执行finalize()方法呢？如果JVM的垃圾收集线程自己来做，很有可能由于在finalize()方法中误操作导致GC线程停止或不可控，这对GC线程来说是一种灾难

2.     Jstat（查看性能）

2.1 作用：

可以观察到classloader，compiler，gc相关信息。可以实时监控资源和性能 。

2.2 命令选项：

-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity： 统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况

2.3 参数内容

S0  — Heap上的 Survivor space 0 区已使用空间的百分比
S0C：S0当前容量的大小
S0U：S0已经使用的大小
S1  — Heap上的 Survivor space 1 区已使用空间的百分比
S1C：S1当前容量的大小
S1U：S1已经使用的大小
E   — Heap上的 Eden space 区已使用空间的百分比
EC：Eden space当前容量的大小
EU：Eden space已经使用的大小
O   — Heap上的 Old space 区已使用空间的百分比
OC：Old space当前容量的大小
OU：Old space已经使用的大小
P   — Perm space 区已使用空间的百分比
OC：Perm space当前容量的大小
OU：Perm space已经使用的大小
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)，它的值等于YGC+FGC

3.     Jmap（查看内存）

3.1 作用：

jmap 用来查看堆内存使用状况，一般结合 jhat 使用

3.2 命令选项

-heap：打印 heap 的概要信息，GC 使用的算法，heap 的配置以及 wise heap 的使用情况。

-histo：打印每个 class 的实例数目，内存占用，类全名信息，

-permstat：打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.

二、Why

有时候内存泄漏，内存溢出，或者死锁等现象出现的时候仅仅通过应用程序的日志信息是很难定位问题的，很多时候这种情况出现的时候我们的解决方案都是重启服务器，但是这种方式并没有从根本上解决问题，程序运行一段时间还是会出现上述现象。

所以为了从根本上解决这些问题，我们首先要定位问题，知道问题发生的原因，因为 Java 应用程序都是运行在 JVM 上的，所以了解 JVM 的概念和原理是我们发现问题的第一步。

JVM 中为我们提供了一些内置的工具可以用于抓取 JVM 的状态信息，比如使用 Jstack 可以抓取当前进程的堆栈信息，分析后判断是否存在死锁问题，使用 Jmap 可以抓取堆内存信息，分析后可以发现各种内存泄漏，内存溢出的原因，使用 Jstat 可以查看系统的性能等。

三、How

1. Jstack

操作流程：

第一步：抓取堆栈信息写入 a.txt

jstack –l <pid>

第二步：使用工具分析堆栈信息

2. Jstat

抓取信息：

# jstat -gc 30077 100 5

3. Jmap

使用 IBM 的HeapAnalyzer 分析堆内存信息。

第一步：抓取数据

第二步：使用工具分析：HeapAnalyzer

四、参考资料

【1】性能分析之– JAVA Thread Dump 分析综述

http://blog.csdn.net/rachel_luo/article/details/8920596

【2】jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令

http://guafei.iteye.com/blog/1815222

【3】三个实例演示 Java Thread Dump 日志分析

http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

【4】关于JVM的Thin Lock, Fat Lock, SPIN Lock与Tasuki Lock

http://www.blogjava.net/security/archive/2009/02/16/jvm_thin-lock_fat-lock__spin-lock_tasuki-lock.html

【5】JVM性能调优监控工具

https://my.oschina.net/feichexia/blog/196575

对tomcat 7.0 下堆内存告警的情况进行了总结，线上jdk1.6使用的GC策略为:-XX:+UseParallelGC ，即新生代为并行GC年老代为串行GC，jdk1.7默认GC方式为-XX:+UseParallelOldGC ，即新生代和年老代均为并行GC。修改方式为，修改jdk1.7的GC策略为-XX:+UseConcMarkSweepGC （并发GC策略，仅标记阶段会暂停工作线程，响应优先，会较多较快的执行FullGc）。

监控报表的应用等也都遇到了堆内存超过80%的问题，其中一些应用是jdk1.6，也有jdk1.7。参照调整

原选项（或默认选项）

-XX:+UseParallelGC

修改为：

-XX:+UseConcMarkSweepGC

后，观察发现，young gc的次数明显增多，Full gc没有明显增长，堆内存随着时间推移仍然缓慢增长，待增长到一定时间，仍然有堆内存超过80%的告警。告警之后，Full gc之后，告警消失。于是分析，应该是年轻代内存上限不够，另外，能否通过适当增加Full gc的次数，对年老代进行及时回收。通过参考相关文档，旧生代并发回收的触发时机为：

1、当旧生代空间使用到一定比率时触发；

JDK V 1.6中默认为92%，可通过PrintCMSInitiationStatistics（此参数在V 1.5中不能用）来查看这个值到底是多少；

可通过CMSInitiatingOccupancyFraction来强制指定，默认值并不是赋值在了这个值上，是根据如下公式计算出来的：

((100 – MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0;

MinHeapFreeRatio默认值： 40   CMSTriggerRatio默认值： 80

2、当perm gen采用CMS收集且空间使用到一定比率时触发；

perm gen采用CMS收集需设置：-XX:+CMSClassUnloadingEnabled

JDK V 1.6中默认为92%；

可通过CMSInitiatingPermOccupancyFraction来强制指定，同样，它是根据如下公式计算出来的：

((100 – MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0;

MinHeapFreeRatio默认值： 40    CMSTriggerPermRatio默认值： 80

3、Hotspot根据成本计算决定是否需要执行CMS GC；

可通过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策略。

4、外部调用了System.gc，且设置了ExplicitGCInvokesConcurrent；

需要注意，在JDK 6中，在这种情况下如应用同时使用了NIO，可能会出现bug。

另外有两个重要的表格参考：

经过以上分析，调整内存参数为：

-Xms4096m -Xmx4096m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -Xmn2048M -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled

具体含义如下：

Xms和Xmx就不用说了，

-XX:MaxPermSize：最大持久代内存512M

-XX:+UseConcMarkSweepGC： 使用年轻代和年老代都并行gc的方式，并且gc的时间短，old gc的次数取决于stop the world（中断响应）的次数，尽量减少对应用响应的影响。

-Xmn2048M：设置新生代内存的上限大小为2g，这是为了减少young gc的次数，因为默认内存分配是会从新生代内存中分配的。

-XX:+UseCMSInitiatingOccupancyOnly: 不加这个选项的话，根据成本计算决定是否需要执行CMS gc，加上这个选项，当旧生代空间使用率达到92%时会无条件执行Full GC。

-XX:+CMSClassUnloadingEnabled ：CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，需要设置此选项。

其实还有两个选项可以考虑：

CMSInitiatingOccupancyFraction： 当旧生代空间使用到一定比率时, 强制执行旧生代的Full GC。默认为92%。这个参数如果设置为50左右的话，Full GC的次数会非常频繁。可能会对应用的性能造成一定影响。

CMSInitiatingPermOccupancyFraction： 当持久代里的使用比例达到一定比率时，进行持久代内存的回收，默认为92%。如果调低的话，也会明显增多持久代gc的次数。

但这个选项也可能对应用的性能造成影响，所以使用需要谨慎。

调整前的堆内存一天内变化趋势，可以看到虽然在调整，但是整体堆内存使用仍然呈增长态势，可以分析是Full GC的次数不够。