java程序性能優化之找出內存溢出元凶

我曾經在剛入行的時候做過一個小的swing程序，用到了java SE，swing，Thread等東東，當初經驗少也沒有做過嚴格的性能測試，布到生產環境用了一段時間后發現那個小程序有時候會拋java.lang.OutOfMemoryError異常，就是java的內存溢出。當時也上網查了不少資料，試過一些辦法，代碼也稍微做了些優化，但是有一個問題我始終是找不到解決的方案 - 不知為什么子窗體關閉后java的垃圾回收機制無法回收其資源，因為這個程序可能要經常開關一些子窗體，那么這些子窗體關閉后無法釋放資源就造成了程序OutOfMemoryError的潛在的隱患！ 

最近無意間在網上看到了一個監控java程序內存使用的工具 - JProbe，馬上回想起那個未解決的難題，於是我就下載了JProbe8.0.0希望從分析內存入手找到我要的答案。軟件下載安裝后，在安裝目錄里詳盡的用戶指南（懂點軟件和英語的人很快就能上手），主要是兩個步驟： 

1.用JProbe Config工具根據提示生成J2SE或者J2EE程序的控制腳本（一個.jpl文件和一個.bat文件），在命令行里進入.bat文件所在的目錄，然后執行該批處理讓要監控的java程序跑起來 

2.運行JProbe Console工具，點擊“Attach to Session...”按鈕，彈出java程序的內存實時監控圖表“Runtime Summary”，我們主要是看“Data”卡片里的內容（注意：第一次使用該軟件可能會遇到一些小問題：比如發布為jar包的程序如果運行時會去讀配置文件，從控制腳本啟動的話，可能會發生配置文件找不到的異常，解決辦法是：不要打jar包，直接就用文件夾發布；還有可能因為一些殺毒軟件的網絡防火牆導致JProbe無法連接到控制腳本的session，造成監控圖表打不開，解決辦法是：取消防火牆對於JProbe訪問網絡的限制） 

實時監控圖表“Runtime Summary”如下圖所示： 


可以設置要監視的包或者類，然后點擊“Refresh Runtime Data”按鈕刷新這些對象占用內存的情況，當你覺得某個類比較可疑的話，你可以在不斷的使用程序的過程中監視它的生命周期，看看它是否像預期的那樣在結束了生命周期后占用的內存就被釋放。眾所周知：java的內存回收是自動進行的，無需程序員干預，我們稱其為垃圾回收，這個垃圾回收可能是不定期的，就是當程序占用內存資源比較少的情況下可能jvm的垃圾回收頻率就比較低；反之，java程序消耗內存資源比較多的情況下，垃圾回收的頻率和力度就比較高，這種垃圾回收的不確定性很可能會影響我們的判斷，但我們可以點擊JProbe監控界面右上方的“Request a Garbage Collection”（像一個垃圾桶的圖標）按鈕來向jvm發出垃圾回收的請求，等幾秒后再去點擊“Refresh Runtime Data”，這個時候如果那個預期應該已經銷毀的對象的類名還是沒有從監控界面下方的class列中消失或者其對象數量沒有減少的話（請多試幾次，中間可以夾雜些其他增加程序內存使用的操作以確保jvm確實執行了垃圾回收），那恭喜你！90%的可能性你已經找到了程序的某個缺陷 

這個查找元凶的過程可能是相當耗時的，是對程序員的耐心的挑戰。我熬了一下午一晚上，功夫不負有心人，基本上把我那個小程序的所有內存溢出的漏洞都找到並補上了。事實告訴我之前那個子窗體關閉后資源無法釋放的根本原因是：子窗體雖然調用了dispose()方法，但是子窗體對象的引用一直都在：或者是被靜態HashMap引用、或者是它的內部子線程類沒有釋放、或者是它的某個事件監聽類沒有釋放（借用JProbe的火眼金睛一檢驗，發現問題真是一大堆啊！），so.我們要徹底釋放某個對象占用資源的關鍵在於找到並釋放所有對它的引用！ 

下面是我解決具體問題的一些經驗： 

程序中造成內存溢出可能性最大的是HashMap，Hashtable等等集合類，尤其是靜態的，更是要慎之又慎！！！它們引用的對象可能你感覺已經銷毀了，其實很可能你忘記remove鍵值，而如果這些集合對象還是靜態的掛在其他類里面，那么這個引用可能一直都在，借用JProbe測試一下，結果往往出人意料，解決辦法：徹底刪除鍵，remove、clear，如果允許最好把集合對象設為null 

對於不再使用的線程對象，如果要徹底殺了它，很多書上都推薦用join方法，我之前也是這樣做的，但后來借助JProbe工具我吃驚的發現這樣做很可能要殺的線程仍舊好好的活在你日益增大的內存里，很可能調用了線程的sleep方法后用join方法就會有點問題，解決辦法：在join方法前再加一句執行interrupt方法，不過這個時候可能會有新的問題：執行interrupt方法后你的線程類會拋InterruptedException，上有政策下有對策，加一個開關變量做判斷就能完美解決，可參考下面的代碼： 

/**
 * <p>Description: 創建線程的內部類</p>
 * @author cuishen
 * @version 1.1
 */
class NewThread implements Runnable {
    Thread t;
    NewThread() {
        t = new Thread(this, path);
        t.start();
    }
    public void run() {
        try {
            while(isThreadAlive) {
                startMonitor();
                Thread.sleep(Long.parseLong(controlList.get(controlList.size() - 1).toString()));
            }
        } catch (InterruptedException e) {
            if(!ifForceInterruptThread) {//開關變量
                stopThread(logThread);
                String error = "InterruptedException！！！" + path + ": Interrupted，線程異常終止！程序已試圖重啟該線程！！";
                System.err.println(error);
                LogService.writeLog(error);
                createLogThread();
            }
        }
    }
}

public void createLogThread() {
    ifForceInterruptThread = false;//開關變量
    logThread = new NewThread();
}

private void stopThread(NewThread thread) {
    try {
        thread.t.join(100);
    } catch (InterruptedException ex) {
        System.out.println("線程終止異常！！！");
    } finally {
        thread = null;
    }
}

/**
 * 關閉並徹底釋放該線程資源的方法
 */
public void stopThread() {
    try {
        ifForceInterruptThread = true;//開關變量
        isThreadAlive = false;
        logThread.t.interrupt();
        logThread.t.join(50);
    } catch (InterruptedException ex) {
        System.out.println("線程終止異常！！！");
    } finally {
        this.controlList = null;
        this.keyList = null;
        logThread = null;
    }
}

對於繼承JFrame的窗體類，我們要注意在初始化方法中加入：this.setDefaultCloseOperation(DISPOSE_ON_CLOSE); ，並且注意和其關聯的事件監聽類一律寫成窗體類的內部類，這樣窗體dispose()的時候，這些內部類也一並銷毀，就不會再有什么莫名其妙的引用了