JVM学习总结五(番外)——JConsole

    之前本来打算结合自己写的小程序来介绍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、线程

    该页面可以查看当前JVM进程启动了多少个线程，并能查看每个线程的状态及堆栈信息，此外还有一个功能就是能够自动检测死锁，见图：    

4、类

    该页面其实和线程页有些相似，不过显示的是JVM加载类的信息，见图：

5、VM概述

    这个其实没必要细说，看图就明白，显示了当前JVM的各方面信息：

6、MBean管理

    这一部分也不细说，主要目前自己对JMX 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，敬请期待喽^_^。