之前本来打算结合自己写的小程序来介绍JConsole和VirtualVM的使用的，但是发现很难通过一个程序把所有的场景都体现出来，所以还是决定用书中的典型小例子来讲更加清晰。
一、JConsole的基本功能
JConsole是一个机遇JMX（Java Management Extensions，即Java管理扩展）的JVM监控与管理工具，监控主要体现在：堆栈内存、线程、CPU、类、VM信息这几个方面，而管理主要是对JMX MBean（managed beans，被管理的beans，是一系列资源，包含对象、接口、设备等）的管理，不仅能查看bean的属性和方法信息，还能够在运行时修改属性或调用方法。
首先我们看下JConsole的启动，JConsole在jdk/bin/下，其启动需要图形界面的支持（废话，都说了图形界面），可能不少人一听到这个就觉得有点low：平时服务器跑的linux都没图形界面，那岂不是用不了。其实不用担心，JConsole支持远程进程监测。下边是连接界面，其实相当于jps命令：
再来看下连接后的界面，我们打开DeadLock（一个测试死锁的示例）：
可以看到上边的选项卡正好对应各个功能。
1、概述
这个不介绍了，就是上图，相信大家都看的懂。
2、内存
在内存页我们可以看到程序运行期间JVM各个部分的内存状况，右下角是对应各个分区的内存使用柱状图，点击对应柱可查看详情，看图：
3、线程
4、类
该页面其实和线程页有些相似，不过显示的是JVM加载类的信息，见图：
5、VM概述
6、MBean管理
下边来看两个小示例，分别分析内存和死锁的。
二、两个示例
1、内存分析
这里我们来通过一个小程序进行一下内存分析，代码如下：
package com.gj.jconsole; import java.util.ArrayList;
import java.util.List; public class DataInsert { //一个OOMObject实例大概64k+
static class OOMObject{
public byte[] placeholder= new byte[64*1024];
} public static void fillHeap() throws InterruptedException {
List<OOMObject> list =new ArrayList<OOMObject>();
for(int i=0;i<1000;i++){
Thread.sleep(100);
list.add(new OOMObject());
}
System.gc();
} public static void main(String[] args) throws Exception{
fillHeap();
}
}
可以看到程序向list中插入了1000个OOMObject对象，每个OOMObject大概64k，那么堆内存的峰值应该在64k*1000=64m左右，我们运行程序，并使用JConsole打开DataInsert进程，当程序结束时堆内存如下：
可以看到对内存峰值在60-70m之间（下方已用内存为63631kb，大约63m），与我们预计的相符。下边我们来看下下边这段代码：
package com.gj.jconsole; import java.util.ArrayList;
import java.util.List; import com.gj.jconsole.DataInsert.OOMObject; public class GCTest { // 一个OOMObject实例大概640k+
static class OOMObject {
public byte[] placeholder = new byte[64 * 1024*10];
} public static void fillHeap() throws InterruptedException {
for(int i=0;i<100;i++){
OOMObject oOmObject =new OOMObject();
Thread.sleep(1000);
oOmObject=null;
}
} public static void main(String[] args) throws InterruptedException {
fillHeap();
} }
这段代码每次新建一个OOMObject对象，在暂停1s后将其置null，我们来看下运行时内存图：
会发现堆内存呈规律的折线，我们来分析下：当每个对象实例化后，然后置null，这时候对象并不会被回收（因为没有gc），因此内存会一直上升，但是当堆内存不够用时，会触发gc，因此内存会降低。查看VM概况可知，一共进行了18次gc，回收算法为“复制”。
2、线程死锁
通过Jconsole不仅可以查看线程信息，而且能够检测死锁，先来看下代码：
package com.gj.jconsole;
public class DeadLock {
static class SynAddRunable implements Runnable{
int a,b;
public SynAddRunable(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);
}
}
}
}
/**
* @param args
*/
public static void main(String[] args) {
for(int i=0;i<100;i++){
new Thread(new SynAddRunable(1, 2)).start();
new Thread(new SynAddRunable(2, 1)).start();
}
}
}
可以看到代码中启动200个子线程，进行1+2或2+1的计算，但是这种情况为什么会出现死锁呢？我们看到在run中出现双重sychronized，这是典型的死锁特征，但是这种情况要出现死锁前提是多线程中sychronized同步的两个对象分别都是同一个，才会造成互锁，但是Integer.valueOf(a)和Integer.valueOf(b)每次返回的不都是一个新对象吗？这里需要注意一个问题，为了节省内存，对于[-128,127]以内的转换，Integer.valueOf会将这些值从缓存直接返回，所以相同的值返回的都是同一个对象（记得看java源码的时候见过很多这种处理方法）。好了，来看下如何检查死锁。
等程序运行一段时间之后（这种情况下形成死锁是随机的，并不能确定那两个会互锁，但是对于200个线程概率还是非常大的），我们在线程页点击“检测死锁”，则会多出来一个死锁页，打开可以看到如下信息：
可以看到线程0和线程11互锁，同时线程199由于等待线程11释放锁，也被阻塞。
以上就是JConsole的基本用法，还是比较简单的。但这些只是小道，工具毕竟只是辅助，关键的还是要懂得原理，学会分析，真正的能在实践中活用才好。下次将介绍更为强大的VirtualVM，敬请期待喽^_^。