jvm中的內存溢出與內存泄露

內存溢出:

　　就是我們通常遇到的OutOfMemoryError異常,它俗理解就是內存不夠，通常在運行大型程序時發生，當程序所需要的內存遠遠超出了JVM內存所承受大小，就會報出OutOfMemoryError異常(稱為OOM異常)。

　　在我們的JVM內存區域中(可以點擊鏈接了解詳情),除了程序計數器所占的內存其他的內存區域都有可能發生OOM異常,當發生OOM異常時我們可以通過Jstack工具和圖形化工具JConsole工具查詢到發生異常的具體區域。

當然也可以從以下幾個方面來檢查自己的程序:

1. 1. 是否存在死循環和方法的無線遞歸調用
   2. 大量循環產生新對象
   3. 集合類中有對對象的引用，使用完后未清空，GC不能回收(內存泄漏)
   4. 是否一次性在數據庫中讀取了過多的數據

解決辦法：

　　可以通過設置JVM主要模塊的大小來避免發生OOM

-xms 堆內存的初始化大小 

-xmx 堆內存的最大空間

-xx：PermSize 方法區初始化大小

-xx：MaxPermSize 方法區最大空間

---

 

內存泄露:

　　內存泄漏是指本應該被GC回收的無用對象沒有被回收，導致的內存空間的浪費，當內存泄露嚴重時會導致OOM。Java內存泄露根本原因是：長生命周期的對象持有短生命周期對象的引用，盡管短生命周期對象已經不再需要，但是因為長生命周期對象持有它的引用而導致不能被GC回收。

　　一下是java中內存泄露發生的幾種場景：

　　1.靜態集合類引起內存泄露： 

　　像HashMap、Vector等集合的使用最容易出現內存泄露。因為這些集合屬於靜態集合，這些靜態變量的生命周期和應用程序一致，他們所引用的所有的對象Object也不能被釋放，因為他們也將一直被Vector等引用着。

 

Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();    //每次創建新的對象
v.add(o);
o = null;            //將對象添加到集合后將對象的引用置空
}
//因為對象的引用置空之后,JVM已經失去的使用該對象的價值,本應該被GC清除,但是在vector集合中還存在着此對象的引用,

//導致沒能順利清除

循環申請Object 對象，並將所申請的對象放入一個Vector 中，如果僅僅釋放引用本身（o=null），那么Vector 仍然引用該對象，所以這個對象對GC 來說是不可回收的。因此，如果對象加入到Vector 后，還必須從Vector 中刪除，最簡單的方法就是將v = null。這樣就可以將Vector執行那個的對象也釋放。

 

　　2、當集合（Hash算法的集合）里面的對象屬性被修改后，再調用remove（）方法時不起作用

public static void main(String[] args)
{
Set<Person> set = new HashSet<Person>();
Person p1 = new Person("唐僧","pwd1",25);
Person p2 = new Person("孫悟空","pwd2",26);
Person p3 = new Person("豬八戒","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:3 個元素!
p3.setAge(2); //修改p3的年齡,此時p3元素對應的hashcode值發生改變

set.remove(p3); //此時remove不掉，造成內存泄漏

set.add(p3); //重新添加，居然添加成功
System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:4 個元素!
for (Person person : set)
{
System.out.println(person);
}
}

 

 

 3、監聽器 
在java 編程中，我們都需要和監聽器打交道，通常一個應用當中會用到很多監聽器，我們會調用一個控件的諸如addXXXListener()等方法來增加監聽器，但往往在釋放對象的時候卻沒有記住去刪除這些監聽器，從而增加了內存泄漏的機會。

4、各種連接 
比如數據庫連接（dataSourse.getConnection()），網絡連接(socket)和io連接，除非其顯式的調用了其close（）方法將其連接關閉，否則是不會自動被GC 回收的。對於Resultset 和Statement 對象可以不進行顯式回收，但Connection 一定要顯式回收，因為Connection 在任何時候都無法自動回收，而Connection一旦回收，Resultset 和Statement 對象就會立即為NULL。但是如果使用連接池，情況就不一樣了，除了要顯式地關閉連接，還必須顯式地關閉Resultset Statement 對象（關閉其中一個，另外一個也會關閉），否則就會造成大量的Statement 對象無法釋放，從而引起內存泄漏。這種情況下一般都會在try里面去的連接，在finally里面釋放連接。

5、單例模式

如果單例對象持有外部對象的引用，那么這個外部對象將不能被jvm正常回收，導致內存泄露。

不正確使用單例模式是引起內存泄露的一個常見問題，單例對象在被初始化后將在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是個比較復雜的對象或者集合類型會發生什么情況