二、JDK的可視化工具

2.1 JConsole：Java監(jiān)視與管理控制臺

JConsole（Java Monitoring and Management Console）是一種基于JMX的可視化監(jiān)視汇在、管理工具脏答。它管理部分的功能是針對JMX MBean進行管理，由于MBean可以使用代碼阿蝶、中間件服務器的管理控制臺或者所有符合JMX規(guī)范的軟件進行訪問黄绩。

2.1.1 啟動JConsole

從JDK的bin目錄中可以直接雙擊運行此工具爽丹。

1

2

2.1.2 內存監(jiān)控

“內存”頁相當于可視化的jstat命令匕积，用于監(jiān)視受收集器管理的虛擬機內存（Java堆和永久代）的變化趨勢。這里通過例子說明（這里親自試驗了書中的例子闪唆，但是拿到的曲線和書中有點不一樣悄蕾，這里還是以書中為準）：

代碼如下：

//使用java -Xms100m -Xmx100m -XX:+UseSerialGC運行
public static void main(String[] args) throws Exception{
    fileHeap(1000);
}

static class OOMObject{
    public byte[] placeholder = new byte[64 * 1024];

}

public static void fileHeap(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();
}

3

• 問題一：虛擬機啟動參數(shù)只限制了Java堆為100MB颖侄，沒有指定-Xmn參數(shù)（-Xms初始堆大小，-Xmx最大堆大行⑷怠）穴墅，能否從監(jiān)控圖中估計出新生代有多大？
  從圖中可以看到Eden空間為27328KB，因為沒有設置-XX:SurvivorRadio參數(shù)悼泌，所以Eden與Survivor空間比例默認為8：1馆里，整個新生代空間大約為27328KB*125%=34160KB。

• 問題二丙者、為何執(zhí)行了System.gc()之后营密，圖中代表的老年代的柱狀圖仍然顯示峰值狀態(tài)，代碼需要如何改動才能讓System.gc()回收掉填充到堆中的對象纷捞？
  執(zhí)行完System.gc()后，空間未能回收是因為在List<OOMObject> list對象仍然存活奖唯，fileHeap()方法仍然沒有退出糜值，因此list對象在System.gc()執(zhí)行時仍然處于作用域之內。如果把System.gc()移動到fileHeap()方法外調用就可以回收掉全部內存病往。

2.1.3 線程監(jiān)控

如果上面的“內存”頁簽相當于可視化的jstat命令的話荣恐，“線程”頁簽的功能相當于可視化的jstack命令车要，遇到線程停頓時可以使用這個頁簽進行監(jiān)控分析寿弱。之前說過線程長時間停頓的主要原因主要有：等待外部資源（數(shù)據(jù)庫連接嚷硫、網絡資源仔掸、設備資源等）医清、死循環(huán)、鎖等待（活鎖和死鎖）负懦。下面通過代碼演示：

public static void createBusyThread(){
    Thread thread = new Thread(new Runnable(){
        @Override
        public void run(){
            while(true)
                ;
        }
    }, "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){
    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狀態(tài)闺金，Runnable狀態(tài)的線程會被分配運行時間，但readBytes方法檢查到流沒有更新時會立刻歸還執(zhí)行令牌败匹，這種等待只消耗很小的CPU資源掀亩。

4

接著監(jiān)控testBusyThread線程，如圖所示捉蚤。此時處于一個死循環(huán)中炼七，不會歸還線程執(zhí)行令牌豌拙，會消耗很多CPU資源。

5

在執(zhí)行testLockThread線程時捉超，在等待著lock對象的nofify或notifyAll方法的出現(xiàn)唯绍，此時線程處于WAITTING狀態(tài)况芒，在被喚醒之前是不會被分配執(zhí)行時間的。

6

//線程死鎖等待演示
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();
    }
}

說明：這段代碼開了200個線程去分別計算1+2以及2+1的值，一般的話舌狗，for循環(huán)只需要運行2~3次就會遇到線程死鎖扔水，程序無法結束。造成死鎖的原因是Integer.valueOf()方法基于減少對象創(chuàng)建次數(shù)和節(jié)省內存的考慮主届，[-128, 127]之間的數(shù)字會被緩存待德，當valueOf()方法傳入參數(shù)在這個范圍之內将宪，將直接返回緩存中的對象。即代碼中調用了200次valueOf()方法一共就只返回了兩個不同的對象印蔗。加入在某個線程的兩個synchronized塊之間發(fā)生了一次線程切換燎潮，那就會出現(xiàn)線程A等著被線程B持有的Integer.valueOf(1)，線程B又等著被線程A持有的Integer.valueOf(2)除呵，結果出現(xiàn)大家都拋不下去的情景爪喘。

出現(xiàn)死鎖之后秉剑，點擊JConsole線程面板的“監(jiān)測到死鎖”的按鈕，將出現(xiàn)一個新的“死鎖”頁簽诡曙，如圖所示略水。

7