要查看哪些进程占用了较多的资源(如CPU、内存、磁盘IO等),在Linux下使用的最频繁的一个命令是top,如下图所示
这个就相当于windows下的任务管理器,能够简单的描述每个进程占用的资源信息,包含CPU、磁盘、内存等信息,按1可以将CPU拆解,看单个CPU的运行信息。使用ps –ef | grep 进程名可以查看对应进程的简单信息,如ps –ef|grep java,如下图所示:
其实JDK已经为我们提供了很多很好的针对Java的性能监控工具,下面我们就来一起看一下JDK都为我们提供了哪些性能检测工具。
JDK的命令行工具
Jps(JVM Process Status Tools)
Jps是参照Unix系统的取名规则命名的,而他的功能和ps的功能类似,可以列举正在运行的虚拟机进程并显示虚拟机执行的主类以及这些进程的唯一ID(LVMID,对应本机来说和PID相同),他的用法如下:
Jps [option] [hostid]
其中hostid默认为本机,而option选项包含以下选项
Option |
Function |
-q |
只输出LVMID |
-m |
输出JVM启动时传给主类的方法 |
-l |
输出主类的全名,如果是Jar则输出jar的路径 |
-v |
输出JVM的启动参数 |
jstat(JVM Statistics Monitoring Tools)
Jstat主要用于监控虚拟机的各种运行状态信息,如类的装载、内存、垃圾回收、JIT编译器等。在没有GUI的服务器上,这款工具是首选的一款监控工具。其用法如下:
jstat [option vmid [interval [s|ms] [vount] ] ]
参数interval和count分别表示查询间隔和查询次数,如每1毫秒查询一次进程20445的垃圾回收情况,监控20次,命令如下所示:
jstat –gc 20445 1 20
相关的输出参数介绍可参照官方的说明(注:网址链接请点击此处)
选项option代表用户需要查询的虚拟机的信息,主要分为3类:类装载、垃圾回收和运行期的编译情况,具体如下表所示:
Option |
Function |
-class |
监视类的装载、卸载数量以及类的装载总空间和耗费时间等 |
-gc |
监视Java堆,包含eden、2个survivor区、old区和永久带区域的容量、已用空间、GC时间合计等信息 |
-gccapcity |
监视内容与-gc相同,但输出主要关注Java区域用到的最大和最小空间 |
-gcutil |
监视内容与-gc相同,但输出主要关注已使用空间占总空间的百分比 |
-gccause |
与-gcutil输出信息相同,额外输出导致上次GC产生的原因 |
-gcnew |
监控新生代的GC情况 |
-gcnewcapacity |
与-gcnew监控信息相同,输出主要关注使用到的最大和最小空间 |
-gcold |
监控老生代的GC情况 |
-gcoldcapacity |
与-gcold监控信息相同,输出主要关注使用到的最大和最小空间 |
-gcpermcapacity |
输出永久带用到的最大和最小空间 |
-compiler |
输出JIT编译器编译过的方法、耗时信息 |
-printcompilation |
输出已经被JIT编译的方法 |
显示内容说明如下(部分结果是通过其他其他参数显示的,暂不说明):
S0C:年轻代中第一个survivor(幸存区)的容量 (字节)
S1C:年轻代中第二个survivor(幸存区)的容量 (字节)
S0U:年轻代中第一个survivor(幸存区)目前已使用空间 (字节)
S1U:年轻代中第二个survivor(幸存区)目前已使用空间 (字节)
EC:年轻代中Eden(伊甸园)的容量 (字节)
EU:年轻代中Eden(伊甸园)目前已使用空间 (字节)
OC:Old代的容量 (字节)
OU:Old代目前已使用空间 (字节)
PC:Perm(持久代)的容量 (字节)
PU:Perm(持久代)目前已使用空间 (字节)
YGC:从应用程序启动到采样时年轻代中gc次数
YGCT:从应用程序启动到采样时年轻代中gc所用时间(s)
FGC:从应用程序启动到采样时old代(全gc)gc次数
FGCT:从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT:从应用程序启动到采样时gc用的总时间(s)
NGCMN:年轻代(young)中初始化(最小)的大小 (字节)
NGCMX:年轻代(young)的最大容量 (字节)
NGC:年轻代(young)中当前的容量 (字节)
OGCMN:old代中初始化(最小)的大小 (字节)
OGCMX:old代的最大容量 (字节)
OGC:old代当前新生成的容量 (字节)
PGCMN:perm代中初始化(最小)的大小 (字节)
PGCMX:perm代的最大容量 (字节)
PGC:perm代当前新生成的容量 (字节)
S0:年轻代中第一个survivor(幸存区)已使用的占当前容量百分比
S1:年轻代中第二个survivor(幸存区)已使用的占当前容量百分比
E:年轻代中Eden(伊甸园)已使用的占当前容量百分比
O:old代已使用的占当前容量百分比
P:perm代已使用的占当前容量百分比
S0CMX:年轻代中第一个survivor(幸存区)的最大容量 (字节)
S1CMX :年轻代中第二个survivor(幸存区)的最大容量 (字节)
ECMX:年轻代中Eden(伊甸园)的最大容量 (字节)
DSS:当前需要survivor(幸存区)的容量 (字节)(Eden区已满)
TT: 持有次数限制
MTT : 最大持有次数限制
jinfo(JVM configuration Info for Java)
Jinfo的作用是实时查看虚拟机的各项参数信息。jps –v可以查看虚拟机在启动时被显式指定的参数信息,但是如果你想知道默认的一些参数信息呢?除了去查询对应的资料以外,jinfo就显得很重要了。jinfo的用法如下:
Jinfo [option] pid
如 jinfo –sysprops {pid}
还有很多参数信息,我们可以看到除了我们显式指定的参数信息以外,JVM的默认参数一览无余。同时,从JDK1.6以后,jinfo加入了运行时修改参数信息的能力,可以使用-flag [+|-]name 或者-flag name=value来修改一部分运行期可以写入的虚拟机参数。更多信息可参考官方文档。
jmap(JVM Memory Map for Java)
Jmap用于生成堆快照(heapdump)。当然我们有很多方法可以取到对应的dump信息,如我们通过JVM启动时加入启动参数 –XX:HeapDumpOnOutOfMemoryError参数,可以让JVM在出现内存溢出错误的时候自动生成dump文件,亦可以通过-XX:HeapDumpOnCtrlBreak参数,在运行时使用ctrl+break按键生成dump文件,当然我们也可以使用kill -3 pid的方式去恐吓JVM生成dump文件。Jmap的作用不仅仅是为了获取dump文件,还可以用于查询finalize执行队列、Java堆和永久带的详细信息,如空间使用率、垃圾回收器等。其运行格式如下:
Jmap [option] vmip
Option的信息如下表所示
Option |
Function |
-dump |
生成对应的dump信息,用法为-dump:[live,]format=b,file={fileName} |
-finalizerinfo |
显示在F-Queue中等待的Finalizer方法的对象(只在linux下生效) |
-heap |
显示堆的详细信息、垃圾回收器信息、参数配置、分代详情等 |
-histo |
显示堆栈中的对象的统计信息,包含类、实例数量和合计容量 |
-permstat |
以ClassLoder为统计口径显示永久带的内存状态 |
-F |
当虚拟机对-dump无响应时可使用这个选项强制生成dump快照 |
示例:jmap -dump:format=b,file=yhj.dump 20445
jhat(JVM Heap Analysis Tool)
Jhat是用来分析dump文件的一个微型的HTTP/HTML服务器,它能将生成的dump文件生成在线的HTML文件,让我们可以通过浏览器进行查阅,然而实际中我们很少使用这个工具,因为一般服务器上设置的堆、栈内存都比较大,生成的dump也比较大,直接用jhat容易造成内存溢出,而是我们大部分会将对应的文件拷贝下来,通过其他可视化的工具进行分析。其用法如下:
Jhat {dump_file}
执行命令后,我们看到系统开始读取这段dump信息,当系统提示Server is ready的时候,用户可以通过在浏览器键入http://ip地址:7000进行查询。
我们可以看到刚才生成的dump文件有多大
我们来生成以下看看!
jhat yhj.dump
//……..
然后我们启动浏览器查看
我们可以看到,很详细的类信息都被抓了出来
jstack(JVM Stack Trace for java)
Jstack用于JVM当前时刻的线程快照,又称threaddump文件,它是JVM当前每一条线程正在执行的堆栈信息的集合。生成线程快照的主要目的是为了定位线程出现长时间停顿的原因,如线程死锁、死循环、请求外部时长过长导致线程停顿的原因。通过jstack我们就可以知道哪些进程在后台做些什么,在等待什么资源等!其运行格式如下:
Jstack [option] vmid
相关的option和function如下表所示
Option |
Function |
-F |
当正常输出的请求不响应时强制输出线程堆栈 |
-l |
除堆栈信息外,显示关于锁的附加信息 |
-m |
显示native方法的堆栈信息 |
示例:jstack -l 20445
从JDK1.5以后,java.lang.Thread类增加了一个getAllStackTraces()方法用于获取虚拟机中的StackTraceElement对象,我们可以通过很简单的代码获取对应JVM的信息,下面是一个简单的示例:
package com.yhj.monitor; import java.util.Map; import java.util.Set; /** * @Described:线程监控器 * @author YHJ create at 2012-3-26 下午05:20:18 * @FileNmae com.yhj.monitor.Threadmonitor.java */ public class Threadmonitor { public static void main(String[] args) { Map<Thread, StackTraceElement[]> map = Thread.getAllStackTraces(); Set<Thread> set = map.keySet(); for(Thread thread : set){ System.out.println("检测到线程["+thread.getId()+":"+thread.getName()+"],线程详细信息:"); for(StackTraceElement trace:map.get(thread)){ System.out.println(trace); } } } }
一次运行结果如下:
如果我们把这个写入一个web工程的一个监控页面上,一个小的监控线程的程序就有了, !
JDK的可视化工具
介绍了前面几个命令,大家也许还在担心如何记住这么多详细的参数,其实JDK为我们提供了更为强大的GUI的监控工具,囊括了上面所有的监控工具的功能,同时还增加了很多工具方便我们的故障分析与性能监控!
从JDK1.5开始,JDK加入了可视化监控工具Jconsole,而从JDK1.6u7以后加了多功能于一体的可视化监控工具VisualVM。下面我们来逐一看一下!
JConsole(JVM Monitoring and management console)
在JDK的bin目录下,我们很容易找到jconsole.exe这个程序,双击即可启动!
这款工具既可以实现本地监控,亦可以实现远程监控。.
启动后界面如图所示:
我们可以清楚的查看对应的CPU、内存、类和一起其他的详细信息。
在内存的tab页面,我们可以看到内存的变化。
在线程tab,我们可以追踪对应线程的变化情况
我们来监控一段代码
package com.yhj.monitor; /** * @Described:死锁演示 * @author YHJ create at 2012-3-26 下午05:46:36 * @FileNmae com.yhj.monitor.Deadlock.java */ public class Deadlock implements Runnable{ private int a; private int b; public Deadlock(int a, int b) { super(); this.a = a; this.b = b; } @Override public void run() { synchronized (Integer.valueOf(a)) { synchronized (Integer.valueOf(b)) { System.out.println("a+b="+(a+b)); } } } public static void main(String[] args) { for(int i = 0; i < 1000; ++i){ new Thread(new Deadlock(1, 2)).start(); new Thread(new Deadlock(2, 1)).start(); } } }
这段代码执行一段时间你会发现他不动了,如下图所示:
我们使用Jconsole的线程tab,下面有一个检测死锁的按钮,点击一下
Jconsole很清楚的告诉我们发生了死锁,如上图所示。并且明确的告诉我们死锁线程每个线程都在干什么?什么资源导致了死锁的发生,很精确。
很多人还在迷惑,上段代码怎么可能发生死锁的?每个线程独享一个a和一个b,互不相干,怎么可能发生死锁呢?
其实发生死锁的原因是我们调用了Integer.valueOf()方法,这个方法是基于减少创建对象次数和节省内存设计的,出于这个的考虑,在[-128~127]之间的数字会被缓存掉,也就是我们循环中传输了那么多的1和2其实就返回的2个,当某个对象持有1,而另外一个对象持有2的时候,第一个等待2的释放,而第二个等待1的释放,因此就发生了死锁。其实这个程序的循环也是不需要的,2个线程就可能引发死锁,但是程序执行太快,概率太小,加一个1000次的循环就是为了增大这种概率。
VisualVM
VisualVM被称为是more in one的工具集,它可以实现以下功能点:
1、 显示虚拟机的进程以及进程的配置信息和环境信息(jps、jinfo)
2、 监视应用程序的CPU、内存、堆、方法区和线程信息(jstat、jstack)
3、 Dump以及分析dump的功能(jmap、jhat)
4、 离线程序快照:离线dump分析
5、 方法运行性能分析,找出调用最多,运行最长的方法块
6、 Plugings动态扩展功能
VisualVM因为是基于netBean开发,因此天生就具有plug大量扩展的能力,我们可以通过他的插件页面轻松安装所需要的插件!
启用VisualVM工具会很醒目的告诉我们检测到一个死锁,而不需要我们在Jconsole下手动启用检测。如下图所示:
VisualVM的插件安装图示如下图所示:
-
jvisual(Java VisualVM)导入dump文件内存不足解决办法
通过jvusual调整-Xmx参数:c:/program files/java/jdk1.6/lib/visualvm/etc/visualvm.conf
修改内容:-J-Xmx24m -J-Xmx256m
改为:-J-Xmx4096m -J-Xmx4096m
验证办法:重新打开jvisual,点击“本地”--VisualVM,查看JVM参数是否更新。
BTrace
在VisualVM中有一个开源的,强大的插件,叫做BTrace。这是一个很有意思的插件,假设这么一种场景,某天你的程序突然出现了某个差错,但是有没有写日志,怎么办呢?BTrace就可以通过简单的代码注入,在你不重启服务器的情况下动态加入相关的日志语句。相关示例请参见官方DEMO:https://hg.kenai.com/hg/btrace~hg/file/d31d25ebd48b/samples。
参考资料
深入理解JVM—性能监控工具:http://blog.csdn.net/wuqiqing_1/article/details/52200000
周志明:深入理解Java虚拟机:JVM高级特性与最佳实践