虚拟机性能监控、故障处理工具
虚拟机性能监控、故障处理工具
-
- 二、基础故障处理工具
-
- 4.2.1 jps：虚拟机进程状况工具
- 4.2.2 jstat:虚拟机统计信息监视工具
- 4.2.3 jinfo:Java配置信息工具
- 4.2.4 jmap:java内存映像工具
- 4.2.5 jhat:虚拟机堆转储快照分析工具
- 4.2.6 jstack：Java堆栈跟踪工具
- 4.2.7 基础工具总结
- 三、可视化故障处理工具
-
- 4.3.1 JHSDB：基于服务性代理的调试工具
- 4.3.2 JConsole:Java监视与管理控制台
-
- 1、启动JConsole
- 2、内存监控
- 3、线程监控
- 4.3.3 VisualVM：多合-故障处理工具
-
- 1、VisualVM兼容范围与插件安装
- 2、生成、浏览堆转储快照
- 3、分析程序性能
- 4、BTrace动态日志跟踪
二、基础故障处理工具
4.2.1 jps：虚拟机进程状况工具
jps可以列出正在运行的虚拟机进程，并显示虚拟机执行主类名称以及这些进程的本地虚拟机唯一ID。
jps命令格式：
jps [options] [hostid]
| 选项 | 作用 |
|---|---|
| -q | 只输出LVMID，省略主类的名称 |
| -m | 输出虚拟机进程启动时传递给主类main()函数的参数 |
| -l | 输出主类的全名，如果进程执行的是JAR包，则输出JAR路径 |
| -v | 输出虚拟机进程启动时的JVM参数 |
4.2.2 jstat:虚拟机统计信息监视工具
jstat可以显示本地或者远程虚拟机进程中的类加载、内存、垃圾收集、即时编译等运行时数据，在没有GUI图形界面、只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的常用工具。
jstat命令格式为：
jstat [option vmid [interval[s|ms] [count]]]
对于VMID和LVMID：如果是本地虚拟机进程，VMID和LVMID是一致的，如果是远程虚拟机进程，那VMID的格式是：
[protocol:][//]lvmid[@hostname[:port]/servername]
参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次，假设需要没250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令应该是：
jstat -gc 2764 250 20
option代表用户希望查询的虚拟机信息，主要分为三类：类加载、类收集、运行期编译状况
| 选项 | 作用 |
|---|---|
| -class | 监视类加载、卸载数量、总空间以及类装载所耗费的时间 |
| -gc | 监视Java堆状况，包括Eden区、2个Survivor区、老年代、永久代等的容量，已用空间，垃圾收集时间合计等信息 |
| -gccapacity | 监视内容与-gc基本相同，但输出主要关注Java堆各个区域用到的最大、最小空间 |
| -gcutil | 监视内容与-tc基本相同，但输出主要关注已使用空间占总空间的百分比 |
| -gccause | 与-gcutil功能一样，但是会额外输出导致上一次垃圾收集产生的原因 |
| -gcnew | 监视新生代垃圾收集状况 |
| -gcnewcapacity | 监视内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间 |
| -gcold | 监视老年代垃圾收集状况 |
| -gcoldcapacity | 监视内容与-gcold基本相同，输出主要关注是用到的最大、最小空间 |
| -gcpermcapacity | 输出永久代使用的最大、最小空间 |
| -compiler | 输出即时编译器编译过的方法、耗时等信息 |
| -printcompilation | 输出已经被即时编译的方法 |
以下是各个数值的解释：
S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：Eden区的大小
EU：Eden区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
4.2.3 jinfo:Java配置信息工具
jinfo的作用是实时查看和调整虚拟机各项参数
jinfo命令格式：
jinfo [option] pid
执行样例：查询CMSInitiatingOccupancyFraction参数值
jinfo -flag CMSInitiatingOccupancyFraction 14444
-XX:CMSIntiatingOccupancyFraction=85
4.2.4 jmap:java内存映像工具
jmap命令用于生成堆转储快照。
如果不使用jmap命令，也可以使用一些其他的“暴力”手段，例如-XX：+HeapDumpOnOutOfMemoryError参数，可以让虚拟机出一场之后自动生成堆转储快照文件，通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成堆转储快 照文件，又或者在Linux系统下通过Kill-3命令发送进程退出信号“恐吓”一下虚拟机，也能顺利拿到堆转 储快照。
jmap的部分功能在Windows平台下受限，除了生成堆转储快照的-dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统中都可以使用之外，其余只能在Linux/Solaris中使用
jmap命令格式：
jmap [option] vmid
| 选项 | 作用 |
|---|---|
| -dump | 生成Java堆转储快照。格式为-dump:[live,]format=b,file=，其中live子参数说明是否只dump出存活的对象 |
| -finalizerinfo | 显示在F-Queue中等待Finalizer线程执行finalize方法的对象。只在Linux/Solaris平台下有效 |
| -heap | 显示Java堆详细信息，如使用哪种回收器、参数配置、分代状况等。只在Linux/Solaris平台下有效 |
| -histo | 显示堆中对象统计信息，包括类、实例数量、合计容量 |
| -permstat | 以ClassLoader为统计口径显示永久代内存状态。只在Linux/Solaris平台下有效 |
| -F | 当虚拟机进程对-dump选项没有响应时，可使用这个选项强制生成dump快照。只在Linux/Solaris平台下有效 |
使用jmap生成dump文件：
jmap -dump:format=b,file=eclipse.bin 3500
4.2.5 jhat:虚拟机堆转储快照分析工具
jhat命令与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/Web服务器，生成堆转储快照的分析结果后，可以在浏览器中查看。
一般不会使用jhat直接在应用程序的服务器上分析快照。
4.2.6 jstack：Java堆栈跟踪工具
jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者 javacore文件）。
线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的 目的通常是定位线程出现长时间停顿的原因。线程出现停顿时通过jstack来查看各个线程的调用堆栈， 就可以获知没有响应的线程到底在后台做些什么事情，或者等待着什么资源。
jstack命令格式：
jstack [option] vmid
| 选项 | 作用 |
|---|---|
| -F | 当正常输出的请求不被响应时，强制输出线程堆栈 |
| -l | 除堆栈外，显示关于锁的附加信息 |
| -m | 如果调用到本地方法的话，可以显示C/C++的堆栈 |
从JDK 5起，java.lang.Thread类新增了一个getAllStackTraces()方法用于获取虚拟机中所有线程的 StackTraceElement对象。使用这个方法可以通过简单的几行代码完成jstack的大部分功能，在实际项目 中不妨调用这个方法做个管理员页面，可以随时使用浏览器来查看线程堆栈。
4.2.7 基础工具总结
基础工具：用于支持基本的程序创建和运行
安全：用于程序签名、设置安全测试等
国际化：用于创建本地语言文件
远程方法调用：用于跨Web或网络的服务交互
部署工具：用于程序打包、发布、部署
Java Web Start
性能监控和故障处理工具
REPL和脚本工具
三、可视化故障处理工具
4.3.1 JHSDB：基于服务性代理的调试工具
JDK中提供了JCMD和JHSDB两个集成式的多功能工具箱，以下是JCMD、JHSDB与原基础工具实现相同功能的简要对比
JHSDB是一款基于服务性代理实现的进程外调试工具。服务性代理是 HotSpot虚拟机中一组用于映射Java虚拟机运行信息的、主要基于Java语言（含少量JNI代码）实现的 API集合。
服务性代理以HotSpot内部的数据结构为参照物进行设计，把这些C++的数据抽象出Java模 型对象，相当于HotSpot的C++代码的一个镜像。通过服务性代理的API，可以在一个独立的Java虚拟 机的进程里分析其他HotSpot虚拟机的内部数据，或者从HotSpot虚拟机进程内存中dump出来的转储快 照里还原出它的运行状态细节。
4.3.2 JConsole:Java监视与管理控制台
JConsole是一款基于JMX的可视化监视、管理工具。它的主要功能是通过JMX的MBean（Managed Bean）对系统进 行信息收集和参数动态调整。
1、启动JConsole
通过JDK/bin目录下的jconsole.exe启动JCon-sole后，会自动搜索出本机运行的所有虚拟机进程，而 不需要用户自己使用jps来查询。双击选择其中一个进程便可进入主界面开始监控。 JMX支持跨服务器的管理，也可以使用下面的“远程进程”功能来连接远程服务器，对远程虚拟机进行 监控。
2、内存监控
“内存”页签的作用相当于可视化的jstat命令，用于监视被收集器管理的虚拟机内存（被收集器直 接管理的Java堆和被间接管理的方法区）的变化趋势。
Jconsole监视代码：
参数：-Xms100m -Xmx100m -XX:+UseSerialGC
static class OOMObject {
public byte[] placeholder = new byte[64 * 1024];
}
public static void fillHeap(int num) throws InterruptedException {
List<OOMObject> list = new ArrayList<OOMObject>();
for (int i = 0; i < num; i++) {
// 稍作延时，令监视曲线的变化更加明显
Thread.sleep(500);
list.add(new OOMObject());
}
System.gc();
}
public static void main(String[] args) throws Exception {
fillHeap(1000);
}
- 虚拟机启动参数只限制了Java堆为100MB，但没有明确使用-Xmn参数指定新生代大小，读者 能否从监控图中估算出新生代的容量？
Eden空间为99008KB，因为没有设置-XX：SurvivorRadio参数，所以Eden 与Survivor空间比例的默认值为8∶1，因此整个新生代空间大约为99008KB×125%=123,760KB。
- 为何执行了System.gc()之后，图4-12中代表老年代的柱状图仍然显示峰值状态，代码需要如何 调整才能让System.gc()回收掉填充到堆中的对象？
执行System.gc()之后，空间未能回收是因为Listlist对象仍然存活， fillHeap()方法仍然没有退出，因此list对象在System.gc()执行时仍然处于作用域之内[1]。如果把 System.gc()移动到fillHeap()方法外调用就可以回收掉全部内存。
3、线程监控
如果说JConsole的“内存”页签相当于可视化的jstat命令的话，那“线程”页签的功能就相当于可视化 的jstack命令了，遇到线程停顿的时候可以使用这个页签的功能进行分析。前面讲解jstack命令时提到 线程长时间停顿的主要原因有等待外部资源（数据库连接、网络资源、设备资源等）、死循环、锁等待等。
/**
* 线程死循环演示
*/
public static void createBusyThread() {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
while (true) // 第41行
{
}
}
}, "testBusyThread");
thread.start();
}
/**
* 线程锁等待演示
*/
public static void createLockThread(final Object lock) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock) {
try {
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}, "testLockThread");
thread.start();
}
public static void main(String[] args) throws Exception {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
br.readLine();
createBusyThread();
br.readLine();
Object obj = new Object();
createLockThread(obj);
}
检测死锁代码样例：
/**
* 线程死锁等待演示
*/
static class SynAddRunalbe implements Runnable {
int a, b;
public SynAddRunalbe(int a, int b) {
this.a = a;
this.b = b;
}
@Override
public void run() {
synchronized (Integer.valueOf(a)) {
synchronized (Integer.valueOf(b)) {
System.out.println(a + b);
}
}
}
}
public static void main(String[] args) {
for (int i = 0; i < 100; i++) {
new Thread(new SynAddRunalbe(1, 2)).start();
new Thread(new SynAddRunalbe(2, 1)).start();
}
}
出现线程死锁后，点击JConsole线程面板的“检测死锁”按钮，将出现一个新的“死锁”页：
如上图所示，线程15在等待线程12的对象，线程12在等待线程15的对象，两个对象都被各自的线程锁住。
4.3.3 VisualVM：多合-故障处理工具
1、VisualVM兼容范围与插件安装
这里VisualVM里的插件中心不知道为什么一直连不上，试了网上的各种方法也没解决问题，之后用到了哪个插件手动下载吧。
2、生成、浏览堆转储快照
VisualVM中生成堆转储快照文件有两种方式：
- 在“应用程序”窗口中右键单击应用程序节点，然后选择“堆Dump”
- 在“应用程序”窗口中双击应用程序节点以打开应用程序标签，然后再“监视”标签中单击“堆Dump”
3、分析程序性能
在Profiler页签中，VisualVM提供了程序运行期间方法级的处理器执行时间分析以及内存分析。做 Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境使用这项功能，或者改用 JMC来完成，JMC的Profiling能力更强，对应用的影响非常轻微。
4、BTrace动态日志跟踪
BTrace [3]是一个很神奇的VisualVM插件，它本身也是一个可运行的独立程序。BTrace的作用是在 不中断目标程序运行的前提下，通过HotSpot虚拟机的Instrument功能[4]动态加入原本并不存在的调试 代码。这项功能对实际生产中的程序很有意义：如当程序出现问题时，排查错误的一些必要信息时 （譬如方法参数、返回值等），在开发时并没有打印到日志之中以至于不得不停掉服务时，都可以通 过调试增量来加入日志代码以解决问题。
由于时间原因，这里不做过多记录，以后有需求再返回来看。