835
再談java的內存泄露
這兩天看了一本老書《bitter java》，第一次係統地了解了所謂“反模式”。就書的內容來說已經過於陳舊，書中提到的magic servlet、複合jsp等等反模式已經是早就熟知的編程禁忌，而如web頁麵不能有太多元素這樣的反模式也因為ajax的出現（異步加載）變的不是那麼“反模式”了，其中又講述了很多ejb的反模式，這些在輕量級框架流行的今天也早已經過時。不過書中有一個章節倒是挺有價值，講述的是java的內存泄露問題，我認為是我目前讀的關於這方麵問題比較有價值的介紹。
網上關於java內存泄露的資料都過於玄乎，其實java導致內存泄露的原因很明確：長生命周期的對象持有短生命周期對象的引用就很可能發生內存泄露，盡管短生命周期對象已經不再需要，但是因為長生命周期對象持有它的引用而導致不能被回收，這就是java中內存泄露的發生場景。作者在書中提到了3個場景：
1。流失監聽器問題，在awt、swing編程中，給組件添加了事件監聽器，這些組件的生命周期如果很長的話，監聽器對象將不能被正確回收。關於GUI編程我不是很熟悉，這一點存有疑問，因為顯然你觸發一個按鈕的事件，當然是一直期待同樣的行為發生，如果刪除了監聽器或者使用弱引用讓JVM回收不符合業務邏輯和用戶體驗。
2。集合類，集合類僅僅有添加元素的方法，而沒有相應的刪除機製，導致內存被占用。這一點其實也不明確，這個集合類如果僅僅是局部變量，根本不會造成內存泄露，在方法棧退出後就沒有引用了會被jvm正常回收。而如果這個集合類是全局性的變量（比如類中的靜態屬性，全局性的map等），那麼沒有相應的刪除機製，很可能導致集合所占用的內存隻增不減，因此提供這樣的刪除機製或者定期清除策略非常必要。
3。單例模式。不正確使用單例模式是引起內存泄露的一個常見問題，單例對象在被初始化後將在JVM的整個生命周期中存在（以靜態變量的方式），如果單例對象持有外部對象的引用，那麼這個外部對象將不能被jvm正常回收，導致內存泄露，考慮下麵的例子：
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B類采用單例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
顯然B采用singleton模式，他持有一個A對象的引用，而這個A類的對象將不能被回收。想象下如果A是個比較大的對象或者集合類型會發生什麼情況。
上麵所講的這些也啟發我們如何去查找內存泄露問題，第一選擇當然是利用工具，比如jprofiler，第二就是在代碼複審的時候關注長生命周期對象：全局性的集合、單例模式的使用、類的static變量等等。
文章轉自莊周夢蝶 ，原文發布時間 2007-11-11
最後更新：2017-05-17 17:01:54