根據javadoc的描述，OOM是指JVM的內存不夠用了，同時垃圾收集器也無法提供更多的內存。從描述中可以看出，在JVM拋出OutOfMemoryError之前，垃圾收集器一般會出馬先嚐試回收內存。
除了程序計數器不會發生OOM外，哪些區域會發生OOM的情況呢？
-
堆內存
堆內存不足是最常見的發送OOM的原因之一，如果在堆中沒有內存完成對象實例的分配，並且堆無法再擴展時，將拋出OutOfMemoryError異常。當前主流的JVM可以通過-Xmx和-Xms來控制堆內存的大小，發生堆上OOM的可能是存在內存泄露，也可能是堆大小分配不合理。 -
Java虛擬機棧和本地方法棧
兩個區域的區別不過是虛擬機棧爲虛擬機執行Java方法服務，而本地方法棧則爲虛擬機使用到的Native方法服務，在內存分配異常上是相同的。在JVM規範中，對Java虛擬機棧規定了兩種異常：1.如果線程請求的棧大於所分配的棧大小，則拋出StackOverFlowError錯誤，比如進行了一個不會停止的遞歸調用；2. 如果虛擬機棧是可以動態拓展的，拓展時無法申請到足夠的內存，則拋出OutOfMemoryError錯誤。 -
直接內存
直接內存雖然不是虛擬機運行時數據區的一部分，但既然是內存，就會受到物理內存的限制。在JDK1.4中引入的NIO使用Native函數庫在堆外內存上直接分配內存，但直接內存不足時，也會導致OOM。 -
方法區
隨着Metaspace元數據區的引入，方法區的OOM錯誤信息也變成了“java.lang.OutOfMemoryError:Metaspace”。對於舊版本的Oracle JDK，由於永久代的大小有限，而JVM對永久代的垃圾回收並不積極，如果往永久代不斷寫入數據，例如String.Intern()的調用，在永久代佔用太多空間導致內存不足，也會出現OOM的問題，對應的錯誤信爲“java.lang.OutOfMemoryError:PermGen space”
堆內存監控於診斷
- 圖形化工具
圖形化工具的優點是直觀，連接到Java進程後，可以顯示堆內存、堆外內存的使用情況，類似的工具有JConsole,VisualVm等。 - 命令行工具
這類工具可以在運行時進行查詢，包括jstat，jmap等，可以對堆內存、方法區等進行查看。
定位線上問題時也多會使用這些工具。jmap也可以生成堆轉儲文件（Heap Dump）文件，如果是在linux上，可以將堆轉儲文件拉到本地來，使用Eclipse MAT進行分析，也可以使用jhap進行分析。
堆內存結構
站在垃圾收集器的角度來看，可以把內存分爲新生代與老年代。
內存的分配規則取決於當前使用的是哪種垃圾收集器的組合，以及內存相關的參數配置。
往大的方向說，對象優先分配在新生代的Eden區域，而大對象直接進入老年代。
- 第一, 新生代的Eden區域
對象優先分配在該區域，同時JVM可以爲每個線程分配一個私有的緩存區域，稱爲TLAB（Thread Local Allocation Buffer），避免多線程同時分配內存時需要使用加鎖等機制而影響分配速度。TLAB在堆上分配，位於Eden中。TLAB的結構如下：
// ThreadLocalAllocBuffer: a descriptor for thread-local storage used by
// the threads for allocation.
// It is thread-private at any time, but maybe multiplexed over
// time across multiple threads. The park()/unpark() pair is
// used to make it avaiable for such multiplexing.
class ThreadLocalAllocBuffer: public CHeapObj<mtThread> {
friend class VMStructs;
private:
HeapWord* _start; // address of TLAB
HeapWord* _top; // address after last allocation
HeapWord* _pf_top; // allocation prefetch watermark
HeapWord* _end; // allocation end (excluding alignment_reserve)
size_t _desired_size; // desired size (including alignment_reserve)
size_t _refill_waste_limit; // hold onto tlab if free() is larger than this
從本質上來說，TLAB的管理是依靠三個指針：start、end、top。start與end標記了Eden中被該TLAB管理的區域，該區域不會被其他線程分配內存所使用，top是分配指針，開始時指向start的位置，隨着內存分配的進行，慢慢向end靠近，當撞上end時觸發TLAB refill。因此內存中Eden的結構大體爲：
2. 新生代的Survivor區域
當Eden區域內存不足時會觸發Minor GC，也稱爲新生代GC，在Minor GC存活下來的對象，會被複制到Survivor區域中。我認爲Survivor區的作用在於避免過早觸發Full GC。如果沒有Survivor，Eden區每進行一次Minor GC都把對象直接送到老年代，老年代很快便會內存不足引發Full GC。新生代中有兩個Survivor區，我認爲兩個Survivor的作用在於提高性能，避免內存碎片的出現。在任何時候，總有一個Survivor是empty的，在發生Minor GC時，會將Eden及另一個的Survivor的存活對象拷貝到該empty Survivor中，從而避免內存碎片的產生。新生代的內存結構大體爲：
3. 老年代
老年代放置長生命週期的對象，通常是從Survivor區域拷貝過來的對象，不過當對象過大的時候，無法在新生代中用連續內存的存放，那麼這個大對象就會被直接分配在老年代上。一般來說，普通的對象都是分配在TLAB上，較大的對象，直接分配在Eden區上的其他內存區域，而過大的對象，直接分配在老年代上。
4. 永久代
如前面所說，在早起的Hotspot JVM中有永久代的概念，永久代用於存儲Java類的元數據、常量池、Intern字符串等。在JDK8之後，就將永久代移除，而引入元數據區的概念。
5. Vritual空間
前面說過，可以使用Xms與Xmx來指定堆的最小與最大空間。如果Xms小於Xmx，堆的大小不會直接擴展到上限，而是留着一部分等待內存需求不斷增長時，再分配給新生代。Vritual空間便是這部分保留的內存區域。
那麼綜上所述，可以畫出Java堆內的內存結構大體爲：
堆內存參數配置
- -Xmx value 指定最大的堆大小
- -Xms value 指定初始的最小堆大小
- -XX:NewSize = value 指定新生代的大小
- -XX：NewRatio = value 老年代與新生代的大小比例。默認情況下，這個比例是2，也就是說老年代是新生代的2倍大。老年代過大的時候，Full GC的時間會很長；老年代過小，則很容易觸發Full GC，Full GC頻率過高，這就是這個參數會造成的影響。
- -XX：SurvivorRation = value . 設置Eden與Srivivor的大小比例，如果該值爲8，代表一個Survivor是Eden的1/8，是整個新生代的1/10。
Java性能監控與問題定位工具
在系統的性能分析中，CPU、內存與IO是主要的關注項。
很多時候服務出現問題，在這三者上會體現出現，比如CPU飆升，內存不足發生OOM等，這時候需要使用對應的工具，來對性能進行監控，對問題進行定位。
- CPU
對於CPU的監控，首先可以使用top命令來進行查看，下面是使用top查看負載的一個截圖：
load average 代表1分鐘、5分鐘、15分鐘的系統平均負載，從這三個數字，可以判斷系統負荷是大還是小。當CPU完全空閒的時候，平均負荷爲0；當CPU工作量飽和的時候，平均負荷爲1。因此 load average 這三個數值越低，代表系統負荷越小，那麼什麼時候能看出系統負荷比較重呢？這篇文章（Understanding Linux CPU Load – when should you be worried）裏解釋得非常通俗。如果電腦裏只有一個CPU，把CPU看成一條單行橋，橋上只有一個車道，所有的車都必須從這個橋上通過。那麼
系統負荷爲0，代表橋上一輛車也沒有
系統負荷0.5，意味着橋上一半路段上有車
系統負荷1，意味着橋上道路已經被車佔滿
系統負荷1.7，代表着在橋上車子已經滿了（100%），同時還有70%的車子在等待從橋上通過：
從top命令的截圖中可以看到這三個值機器的load average非常低。如果這三個值非常高，比如超過了50%或60%，就應當引起注意。從時間維度上來說，如果發現CPU負荷慢慢升高，也需要警惕。
