JDK这种除了提供大量的命令行工具外，还有两个功能强大的可视化工具：JConsole和VisualVM，这两个工具是JDK的正式成员，没有被贴上“unsupported and experimental”的标签。
其中JConsole是在JDK1.5时期就已经提供的虚拟机监控工具，而VisualVm在JDK1.6 Update7中才首次发布，现在已经成为Sun(Oracle)主力推动的多合一故障处理工具，并且已经从JDK中分离出来成为i可以独立发展的开源项目。
JConsole：Java监视与管理控制台
JConsole（Java Monitoring and Management Console）是一款基于JMX的可视化监视和管理的工具。它管理部分的功能是针对JMX MBean进行管理，MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行。
1.启动JConsole
通过JDK/bin目录下的jconsole.exe启动JConsole后，将自动搜索出本机运行的所有虚拟机进程，不需要用户自己再使用jps来查询了，如下图所示。双击选择其中一个进程即可开始监控，也可以使用下面的“远程进程”功能来连接远程服务器，对远程虚拟机进行监控。
随便选择一个JConsole进入JConsole主界面，可以看到主界面共包含“概述”、“内存”、“线程”、“类”、“VM摘要”和“MBean”六个页签，如下图所示。
“概述”页签显示的是整个虚拟机主要运行数据的概览，其中包括“堆内存使用情况”、“线程”、“类”、“CPU使用情况”四项信息的曲线图，这些曲线图是后面“内存”、“线程”、“类”页签的信息汇总。
2. 内存监控
“内存”页签相当于可视化的jstat命令，用于监视受收集器管理的虚拟机内存（Java堆和永久代）的变化趋势。
/**
* 内存占位符对象，一个OOMObject大约占64K
*/
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(50);
list.add(new OOMObject());
}
System.gc();
}
public static void main(String[] args) throws Exception{
fillHeap(1000);
}运行时设置参数为：-Xms100m -Xmx100m -XX:+UseSerialGC，这段代码的作用是以64KB/50毫秒的速度往Java堆里填充数据，一共填充1000次，使用JConsole的“内存”页签进行监视。
程序运行后，在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状，如下图所示。而监视范围扩大至整个堆后，会发现曲线是一条向上增长的平滑曲线。并从柱状图可以看到，在1000次循环执行结束，运行了System.gc()后，虽然整个新生代Eden和Survivor区都基本被清空了，但是代表老年代的柱状图仍然保持峰值状态，说明被填充进堆中的数据在System.gc()方法执行之后仍然存活着。
3. 线程监控
如果上面的“内存”页签相当于可视化的jstat命令的话，“线程”页签的功能则相当于可视化的jstack命令，遇到线程停顿的时候可以使用这个页签进行监控分析。前者讲解jstack命令的时候提到过线程长时间停顿的主要原因有：等待外部资源（数据库连接、网络资源、设备资源）、死循环、锁等待（活锁和死锁）。通过下面的代码来演示一下
/**
* 线程死循环演示
*/
public static void createBusyThread(){
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
while(true);//31行所在
}
},"testBusyThread");
thread.start();
}
/**
* 线程锁等待演示
* @param lock
*/
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);
}程序运行后，首先在“线程”页签中选择main线程，如下图所示。堆栈追踪显示BufferedReader在readBytes方法中等待System.in的键盘输入，这时候线程为Runnable状态,Runnable状态的进程会被分配运行时间，单readBytes方法检查到流没有更新时会立刻归还执行令牌，这种等待只消耗很小的CPU资源。
接着监控testBusyThread线程，如下图所示，testBusyThread线程一直在执行空循环，从堆栈追踪中可以看到一直停留在MonitoringTest.java代码的31行，31行为while(true)。这时候线程为Runnable状态，并且没有归还线程执行令牌的动作，会在空循环上用尽全部执行时间知道线程切换，这种等待会消耗较多的CPU资源。
而下图所示testLockThread线程在等待这lock对象的notify或notifyAll方法的出现，线程这时候处于WAITING状态，在被唤醒前不会被分配执行时间。testLockThread线程正处于正常的活锁等待状态，只要lock对象的notify()或notifyAll()方法被调用，这个线程便能激活以继续执行。
死锁代码样例：
static class SynAddRunnable implements Runnable{
int a,b;
public SynAddRunnable(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) throws Exception{
for(int i=0;i<100;i++){
new Thread(new SynAddRunnable(1, 2)).start();
new Thread(new SynAddRunnable(2, 1)).start();
}
}这段代码开了200个线程分别去计算1+2和2+1的值，其实for循环是可省略的，两个线程也可能会导致死锁，不过那样概率太小，需要尝试多次才能看到效果。造成死锁的原因是Integer.valueOf()方法基于减少对象创建次数和节省内存的考虑，[-128,127]之间的数字会被缓存，当valueOf()方法在这个范围内传入参数，将直接返回缓冲中的对象。也就是说代码中调用了200此Integer.valueOf()方法一共就只返回了两个不同的对象。假如某个线程的两个synchronized块之间发生了一次线程切换，就会出现线程A等着被线程B持有的Integer.valueOf(1)，线程B又等着被线程A持有的Integer.valueOf(2)，结果就大家都跑不下去的情况。
出现线程死锁之后，点击JConsole线程面板的“检测到死锁”按钮，将出现一个新的“死锁”页签，如下图所示：
图中很清晰地显示了Thread-151在等待一个被线程Thread-72持有的Integer对象，而点击线程Thread-72则显示它也在等待一个被线程Thread-151持有的Integer对象，于是两个线程开始互掐，谁都不肯让步，然后就看不到锁被释放的希望了。
VisualVM：多合一故障处理工具
VisualVM（All-in-One Java Troubleshooting Tool）是目前为止（作者出第一版时，因为我在JDK1.7发现了jmc）,随JDK发布的功能最强大的运行监视和故障处理程序。官方在VisualVM的软件说明中写上了“All-in-One”的描述字样，预示着它除了运行监视、故障出来外，还提供了其他方面的功能。如性能分析（Profilling），VisualVM的性能分析功能甚至比起JProfiler、YourKit等专业收费Profilling工具也不逊色多少，而且VisualVM还有一个很大的优点：不需要被监视的程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接应用在生产环境中。这个优点是JProfiler、YourKit等工具无法与之媲美的。
1.VisualVM兼容范围和插件安装
VisualVM基于NetBeans平台开发，因此它一开始就具备了插件扩展功能的特色，通过插件可扩展支持，VisualVM可以做到：
显示虚拟机进程及进程的配置和环境信息（jps、jinfo）。
监视应用程序的CPU、GC、堆、方法区及线程的信息（jstat、jstack）。
dump及分析堆转储快照（jmap、jhat）。
方法级的程序运行性能分析，找出被调用最多、运行时间最长的方法。
离线程序快照：收集程序的运行时配置、线程dump、内存dump等信息建立一个快照，可以将快照发送开发者处进行Bug反馈。
其他plugins的无限的可能性。
VisualVM在JDK1.6 update7中才首次出现，但并不意味着它只能监控运行于JDK1.6上的程序，它具备很强的向下兼容能力，甚至能向下兼容至近10年前发布的JDK1.4.2平台，这对无数已经处于实施、维护状态的项目很有意义。当然，并非所有的功能都能完美地向下兼容，主要特性的兼容性见下表
| 特性 | JDK1.4.2 | JDK1.5 | JDK1.6 local | JDK1.6 remote |
| 运行环境信息 | √ | √ | √ | √ |
| 系统属性 | √ | |||
| 监视面板 | √ | √ | √ | √ |
| 线程面板 | √ | √ | √ | |
| 性能监控 | √ | |||
| 堆、线程Dump | √ | |||
| MBean管理 | √ | √ | √ | |
| JConsole插件 | √ | √ | √ |
首次启动VisualVM后，不必急着找应用程序进行监测，因为现在VisualVM还没有加载任何插件，虽然基本的监视、线程面板的功能主程序都以默认插件的形式提供了，但是不给VisualVM装任何扩展插件，就相当于放弃了它最精华的功能，和没有安装任何应用软件的操作系统差不多。
插件可以手动安装，在插件中心网站上下载*.nbm包后，点击“工具”-->“插件”-->“已下载”菜单，然后在弹出的对话框中指定nbm包路径便可进行安装，插件安装后存放在JDK_HOME/lib/visualvm/visualvm中。不过手工安装并不常见，使用VisualVM的自动安装功能已经可以找到所需的大多数插件，在有网络连接的环境下，点击“工具”-->“插件”菜单，踏出如下图所示的插件页签，在页签的“可用插件”中列举了当前版本VisualVM可以使用的插件，选中插件后在右边窗口将显示这个插件的基本信息，如开发者、版本、功能描述等。
大家可以根据自己的工作需要和兴趣选择合适的插件，然后点击安装按钮，弹出如下图的下载进度窗口，跟着提示操作即可完成安装。
安装完插件后，选择一个需要监视的程序进入程序的主界面，如下图所示。根据插件数量的不同，页签有所不同。
VisualVM中“概述”、“监视”、“线程”、“MBeans”的功能与前面介绍的JConsole差别不大。
2. 生成和浏览堆转储快照
在VisualVM中生成dump文件有两种方式，可以执行下列任一操作：
在“应用程序”窗口右键单击应用程序节点，然后选择“堆Dump”。
在“应用程序”窗口双击应用程序节点，打开应用程序标签，然后在“监视”页签中点击“堆Dump”。
生成了dump文件后，应用程序页签将在该堆的应用程序下增加一个以[heapdump]开头的子节点，并且在主页签中打开该转储快照，如下图所示。如果需要将dump文件保存或发送出去，要在heapdump节点右键选择“另存为”菜单，否则当VisualVM关闭时，生成的dump文件会被当做临时文件被删除掉。要打开一个已经存在的dump文件，通过文件菜单中的“装入”功能，选择硬盘上的dump文件即可。
从堆页签中的“摘要”面板可以看到应用程序dump时的运行时参数、System.getProperties()的内容、线程堆栈等信息，“类”面板则是以类为统计口径统计类的实例数量和容量信息，“实例”面板不能直接使用，因为不能确定用户想查看哪个类的实例，所以需要通过“类”面板进入，在“类”中选择一个要看的类双击进入，可以看到该类500个实例的具体属性信息。“OQL控制台”面板里面就是运行OQL查询语句的，同jhat里面介绍的OQL功能一样。
3. 分析程序性能
在Profiler页签中，VisualVM提供了程序运行期间方法级的CPU执行时间分析及内存分析，进行Profilling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境中使用这项功能。
要开始分析，先选择“CPU”和“内存”按钮中的一个，然后切换到应用程序对程序进行操作，VisualVM会记录到这段时间中应用程序执行过的方法。如果是CPU分析，将会统计每个方法的执行次数、执行耗时；如果是内存分析则会统计每个方法关联的对象数及这些对象所占的空间。分析结束后，点击“停止”按钮结束监控过程，如下图所示。
注意 在JDK1.5之后，在Client模式下的虚拟机加入并且自动开启了类共享——这是一个在多虚拟机进程中共享rt.jar的类数据以提高加载速度和节省内存的优化，而根据相关Bug报告的反映，VisualVM的Profiler功能会因为类共享而导致被监视的应用程序崩溃，所以进行Profilling前，最好在被监视的程序中使用-Xshare:off参数来关闭类共享优化。
上图是对Eclipse IDE一段操作的录制和分析结果，分析自己的应用程序时，可以根据实际业务的复杂程度与方法的时间和调用次数做比较，找到最有优化价值的方法。
4. BTrace动态日志跟踪
由于没有配置成功，略过，以后再补。
扫一扫
377
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
