堆溢出：
/** * @author LXA * 堆溢出 */ public class Heap { public static void main(String[] args) { ArrayList list=new ArrayList(); while(true) { list.add(new Heap()); } } }
報錯：
java.lang.OutOfMemoryError: Java heap space
棧溢出：
/** * @author LXA * 棧溢出 */ public class Stack { public static void main(String[] args) { new Stack().test(); } public void test() { test(); } }
報錯：
java.lang.StackOverflowError
Java內存管理機制
在C++ 語言中，如果需要動態分配一塊內存，程序員需要負責這塊內存的整個生命周期。從申請分配、到使用、再到最后的釋放。這樣的過程非常靈活，但是卻十分繁瑣，程序員很容易由於疏忽而忘記釋放內存，從而導致內存的泄露。 Java 語言對內存管理做了自己的優化，這就是垃圾回收機制。 Java 的幾乎所有內存對象都是在堆內存上分配（基本數據類型除外），然后由 GC （ garbage collection）負責自動回收不再使用的內存。
上面是Java 內存管理機制的基本情況。但是如果僅僅理解到這里，我們在實際的項目開發中仍然會遇到內存泄漏的問題。也許有人表示懷疑，既然 Java 的垃圾回收機制能夠自動的回收內存，怎么還會出現內存泄漏的情況呢？這個問題，我們需要知道 GC 在什么時候回收內存對象，什么樣的內存對象會被 GC 認為是“不再使用”的。
Java中對內存對象的訪問，使用的是引用的方式。在 Java 代碼中我們維護一個內存對象的引用變量，通過這個引用變量的值，我們可以訪問到對應的內存地址中的內存對象空間。在 Java 程序中，這個引用變量本身既可以存放堆內存中，又可以放在代碼棧的內存中（與基本數據類型相同）。 GC 線程會從代碼棧中的引用變量開始跟蹤，從而判定哪些內存是正在使用的。如果 GC 線程通過這種方式，無法跟蹤到某一塊堆內存，那么 GC 就認為這塊內存將不再使用了（因為代碼中已經無法訪問這塊內存了）。
通過這種有向圖的內存管理方式，當一個內存對象失去了所有的引用之后，GC 就可以將其回收。反過來說，如果這個對象還存在引用，那么它將不會被 GC 回收，哪怕是 Java 虛擬機拋出 OutOfMemoryError 。
Java內存泄露
一般來說內存泄漏有兩種情況。一種情況如在C/C++ 語言中的，在堆中的分配的內存，在沒有將其釋放掉的時候，就將所有能訪問這塊內存的方式都刪掉（如指針重新賦值）；另一種情況則是在內存對象明明已經不需要的時候，還仍然保留着這塊內存和它的訪問方式（引用）。第一種情況，在 Java 中已經由於垃圾回收機制的引入，得到了很好的解決。所以， Java 中的內存泄漏，主要指的是第二種情況。
Vector v = new Vector( 10 ); for ( int i = 1 ;i < 100 ; i ++ ){ Object o = new Object(); v.add(o); o = null ; }
在這個例子中，代碼棧中存在Vector 對象的引用 v 和 Object 對象的引用 o 。在 For 循環中，我們不斷的生成新的對象，然后將其添加到 Vector 對象中，之后將 o 引用置空。問題是當 o 引用被置空后，如果發生 GC ，我們創建的 Object 對象是否能夠被 GC 回收呢？答案是否定的。因為， GC 在跟蹤代碼棧中的引用時，會發現 v 引用，而繼續往下跟蹤，就會發現 v 引用指向的內存空間中又存在指向 Object 對象的引用。也就是說盡管 o 引用已經被置空，但是 Object 對象仍然存在其他的引用，是可以被訪問到的，所以 GC 無法將其釋放掉。如果在此循環之后， Object 對象對程序已經沒有任何作用，那么我們就認為此 Java 程序發生了內存泄漏。
盡管對於C/C++ 中的內存泄露情況來說， Java 內存泄露導致的破壞性小，除了少數情況會出現程序崩潰的情況外，大多數情況下程序仍然能正常運行。但是，在移動設備對於內存和 CPU都有較嚴格的限制的情況下， Java 的內存溢出會導致程序效率低下、占用大量不需要的內存等問題。這將導致整個機器性能變差，嚴重的也會引起拋出 OutOfMemoryError ，導致程序崩潰。
一般情況下內存泄漏的避免
在不涉及復雜數據結構的一般情況下，Java 的內存泄露表現為一個內存對象的生命周期超出了程序需要它的時間長度。我們有時也將其稱為“對象游離”。
在這段代碼中，FileSearch 類中有一個函數 hasString ，用來判斷文檔中是否含有指定的字符串。流程是先將mFile 加載到內存中，然后進行判斷。但是，這里的問題是，將 content 聲明為了實例變量，而不是本地變量。於是，在此函數返回之后，內存中仍然存在整個文件的數據。而很明顯，這些數據我們后續是不再需要的，這就造成了內存的無故浪費。
要避免這種情況下的內存泄露，要求我們以C/C++ 的內存管理思維來管理自己分配的內存。第一，是在聲明對象引用之前，明確內存對象的有效作用域。在一個函數內有效的內存對象，應該聲明為 local 變量，與類實例生命周期相同的要聲明為實例變量……以此類推。第二，在內存對象不再需要時，記得手動將其引用置空。
Java中的幾種引用方式
Java中有幾種不同的引用方式，它們分別是：強引用、軟引用、弱引用和虛引用。下面，我們首先詳細地了解下這幾種引用方式的意義。
強引用
在此之前我們介紹的內容中所使用的引用 都是強引用，這是使用最普遍的引用。如果一個對象具有強引用，那就類似於必不可少的生活用品，垃圾回收器絕不會回收它。當內存空 間不足，Java 虛擬機寧願拋出 OutOfMemoryError 錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足問題。
軟引用（SoftReference ）
SoftReference 類的一個典型用途就是用於內存敏感的高速緩存。 SoftReference 的原理是：在保持對對象的引用時保證在 JVM 報告內存不足情況之前將清除所有的軟引用。關鍵之處在於，垃圾收集器在運行時可能會（也可能不會）釋放軟可及對象。對象是否被釋放取決於垃圾收集器的算法 以及垃圾收集器運行時可用的內存數量。
弱引用（WeakReference ）
WeakReference 類的一個典型用途就是規范化映射（ canonicalized mapping ）。另外，對於那些生存期相對較長而且重新創建的開銷也不高的對象來說，弱引用也比較有用。關鍵之處在於，垃圾收集器運行時如果碰到了弱可及對象，將釋放 WeakReference 引用的對象。然而，請注意，垃圾收集器可能要運行多次才能找到並釋放弱可及對象。
虛引用（PhantomReference ）
PhantomReference 類只能用於跟蹤對被引用對象即將進行的收集。同樣，它還能用於執行 pre-mortem 清除操作。 PhantomReference 必須與 ReferenceQueue 類一起使用。需要 ReferenceQueue 是因為它能夠充當通知機制。當垃圾收集器確定了某個對象是虛可及對象時， PhantomReference 對象就被放在它的 ReferenceQueue 上。將 PhantomReference 對象放在 ReferenceQueue 上也就是一個通知，表明 PhantomReference 對象引用的對象已經結束，可供收集了。這使您能夠剛好在對象占用的內存被回收之前采取行動。 Reference與 ReferenceQueue 的配合使用。