除了程式計數器外，虛擬機器記憶體的其他幾個執行時區域都有發生OutOfMemoryError（OOM），下面我們來詳細分析。
Java堆溢位
Java堆用於儲存物件例項，只要不斷的建立物件，並且保證GC Roots到物件之間有可達路徑來避免垃圾回收機制來清除這些物件，那麼物件數量到達最大堆容量限制後就會產生記憶體溢位異常。例如：

Java堆的大小限制為20M，不可擴充套件（將堆的最小值-Xms引數與最大值-Xmx最大值引數設定為一樣，避免自動擴充套件）通過引數-XX：+HeapDumpOnOutOfMemoryError，可以讓虛擬機器在出現記憶體溢位時Dump出當前的記憶體轉儲快照以便事後進行分析。
要解決這個區域的異常，一般的手段是先通過記憶體映像工具如（Eclipse MemoryAnalyzer）對Dump出來的堆轉儲快照進行分析，重點是確認記憶體中的物件是否是必要的，也就是要先分析到底是出現了記憶體洩露(Memory Leak)還是記憶體溢位（Memory Overflow）
如果是記憶體洩露，可進一步通過工具檢視洩露物件到GC Roots的引用鏈，這樣就比較容易確定發生洩露的程式碼位置。
如果不存在記憶體洩露，那就應當檢查虛擬機器堆引數(-Xmx與-Xms)，與機器實體記憶體對比看是否還可以調大，從程式碼上檢查是否存在某些物件生命週期過長、持有狀態時間過長的情況，嘗試減少程式執行期的記憶體消耗。
虛擬機器棧和本地方法棧溢位

將此程式碼執行在單執行緒下，均讓無法讓虛擬機器產生OutOfMemoryError異常，嘗試結果都是StackOverflowError異常。
1、使用-Xss 引數減少棧記憶體容量，結果：丟擲StackOverflowError異常，異常出現時輸出的棧的深度相應縮小
2、定義了大量的本地變數，增大此方法幀中本地變量表的長度。結果：丟擲StackOverflowError異常時輸出的堆疊深度相應減小。
因此，在單執行緒下，無論是由於棧幀太大還是虛擬機器容量太小，當記憶體無法分配的時候虛擬機器都丟擲的是StackOverflowError。
如果測試不限於單執行緒，通過不斷的建立執行緒的方式倒是可以產生內除溢位異常，但是這樣產生的記憶體溢位與棧空間是否夠大不存在任何聯絡，或者說，為每個執行緒的棧分配的記憶體越大，然而越容易產生記憶體溢位異常。
原因是，作業系統分配給每個執行緒的記憶體是有限的，32位window為2G，虛擬機器提供了引數來控制Java堆和方法區的這兩部分記憶體的最大值。剩餘的記憶體為2G（作業系統記憶體）減去Xmx（堆最大容量），再減去MaxPermSize（最大方法區容量），程式計數器消耗的記憶體很小，可以忽略。如果虛擬機器程序本身耗費的記憶體不計算在內，剩下的記憶體就由虛擬機器棧和本地方法棧瓜分了。每個執行緒分配到棧容量越大，可以建立的執行緒數自然越少，建立執行緒時越容易把剩餘的記憶體耗盡。
方法區和執行時常量池溢位
執行時常量池是方法區的一部反，這兩個可以放在一起。
String.intern()方法是一個native方法，他的作用是：如果字串常量池中已經包含一個等於此String物件的字串，則返回代表池中這個字串的string物件；否則，將此String物件包含的字串新增到常量池中，並返回此String物件的引用。
我們可以通過-XX:PermSize和-XX:MaxPermSize限制方法區大小，從而間接限制其中常量池的容量，程式碼如下：

方法區用於存放Class相關資訊，如類名、訪問修飾符、常量池、欄位描述、方法描述等。方法區的溢位是一個類要被垃圾收集器回收掉，判斷條件是比較苛刻的。在經常動態生成大量Class應用中，需要特別注意類的回收情況。場景有程式使用了CGLib位元組碼增強和動態語言，還有大量jsp或動態產生jsp檔案的應用。例如：

本機直接記憶體溢位
DirectMemory容量可通過-XX：MaxDirectMemorySize指定，如果不指定，則預設與Java堆最大值-Xmx一樣，例如：

以上程式碼直接通過反射獲取Unsafe例項進行記憶體分配。雖然使用DirectByteBuffer分配記憶體也會丟擲記憶體溢位異常，但是他丟擲異常時並沒有真正向操作系統申請分配記憶體，而是通過計算得知記憶體無法分配，於是收到丟擲異常，真正申請分配記憶體的方法時unsafe.allocateMemory()方法。