JVM 與 Linux 的記憶體關係詳解
在一些實體記憶體為8g的伺服器上，主要執行一個Java服務，系統記憶體分配如下：Java服務的JVM堆大小設定為6g，一個監控程序佔用大約 600m，Linux自身使用大約800m。
從表面上，實體記憶體應該是足夠使用的；但實際執行的情況是，會發生大量使用SWAP(說明實體記憶體不夠使用 了)，如下圖所示。由於SWAP和GC同時發生會致使JVM嚴重卡頓，所以我們要追問：記憶體究竟去哪兒了？
要分析這個問題，理解JVM和作業系統之間的記憶體關係非常重要。接下來主要就Linux與JVM之間的記憶體關係進行一些分析。
一、Linux與程序記憶體模型
JVM以一個程序（Process）的身份執行在Linux系統上，瞭解Linux與程序的記憶體關係，是理解JVM與Linux記憶體的關係的基礎。下圖給出了硬體、系統、程序三個層面的記憶體之間的概要關係。
從硬體上看，Linux系統的記憶體空間由兩個部分構成：實體記憶體和SWAP（位於磁碟）。實體記憶體是Linux活動時使用的主要記憶體區域；當實體記憶體不夠使用時，Linux會把一部分暫時不用的記憶體資料放到磁碟上的SWAP中去，以便騰出更多的可用記憶體空間；而當需要使用位於SWAP的資料時，必須 先將其換回到記憶體中。JVM執行時區域詳解，推薦大家看下。
從Linux系統上看，除了引導系統的BIN區，整個記憶體空間主要被分成兩個部分：核心記憶體（Kernel space）、使用者記憶體（User space）。
核心記憶體是Linux自身使用的記憶體空間，主要提供給程式排程、記憶體分配、連線硬體資源等程式邏輯使用。
使用者記憶體是提供給各個程序主要空間，Linux給各個程序提供相同的虛擬記憶體空間；這使得程序之間相互獨立，互不干擾。實現的方法是採用虛擬記憶體技術：給每一個程序一定虛擬記憶體空間，而只有當虛擬記憶體實 際被使用時，才分配實體記憶體。
如下圖所示，對於32的Linux系統來說，一般將0～3G的虛擬記憶體空間分配做為使用者空間，將3～4G的虛擬記憶體空間分配 為核心空間；64位系統的劃分情況是類似的。
從程序的角度來看，程序能直接訪問的使用者記憶體（虛擬記憶體空間）被劃分為5個部分：程式碼區、資料區、堆區、棧區、未使用區。
程式碼區中存放應用程式的機器程式碼，執行過程中程式碼不能被修改，具有隻讀和固定大小的特點。
資料區中存放了應用程式中的全域性資料，靜態資料和一些常量字串等，其大小也是固定的。
堆是執行時程式動態申請的空間，屬於程式執行時直接申請、釋放的記憶體資源。
棧區用來存放函式的傳入引數、臨時變數，以及返回地址等資料。
未使用區是分配新內 存空間的預備區域。
二、程序與JVM記憶體空間
JVM本質就是一個程序，因此其記憶體空間（也稱之為執行時資料區，注意與JMM的區別）也有程序的一般特點。深入淺出 Java 中 JVM 記憶體管理，這篇參考下。
但是，JVM又不是一個普通的程序，其在記憶體空間上有許多嶄新的特點，主要原因有兩 個：
- JVM將許多本來屬於作業系統管理範疇的東西，移植到了JVM內部，目的在於減少系統呼叫的次數；
- Java NIO，目的在於減少用於讀寫IO的系統呼叫的開銷。JVM程序與普通程序記憶體模型比較如下圖:
需要說明的是，這個模型的並不是JVM記憶體使用的精確模型，更側重於從作業系統的角度而省略了一些JVM的內部細節（儘管也很重要）。下面從使用者記憶體和核心記憶體兩個方面講解JVM程序的記憶體特點。
1.使用者記憶體
上圖特別強調了JVM程序模型的程式碼區和資料區指的是JVM自身的，而非Java程式的。普通程序棧區，在JVM一般僅僅用做執行緒棧。JVM的堆區和普通程序的差別是最大的，下面具體詳細說明：
首先是永久代。永久代本質上是Java程式的程式碼區和資料區。Java程式中類（class），會被載入到整個區域的不同資料結構中去，包括常量池、域、方法資料、方法體、建構函式、以及類中的專用方法、例項初始化、介面初始化等。這個區域對於作業系統來說，是堆的一個部分；而對於Java程式來 說，這是容納程式本身及靜態資源的空間，使得JVM能夠解釋執行Java程式。
其次是新生代和老年代。新生代和老年代才是Java程式真正使用的堆空間，主要用於記憶體物件的儲存；但是其管理方式和普通程序有本質的區別。
普通程序在執行時給記憶體物件分配空間時，比如C++執行new操作時，會觸發一次分配記憶體空間的系統呼叫，由作業系統的執行緒根據物件的大小分配好空間後返 回；同時，程式釋放物件時，比如C++執行delete操作時，也會觸發一次系統呼叫，通知作業系統物件所佔用的空間已經可以回收。
JVM對記憶體的使用和一般程序不同。JVM向作業系統申請一整段記憶體區域（具體大小可以在JVM引數調節）作為Java程式的堆（分為新生代和老年代）；當Java程式申請記憶體空間，比如執行new操作，JVM將在這段空間中按所需大小分配給Java程式，並且Java程式不負責通知JVM何時可以釋放這 個物件的空間，垃圾物件記憶體空間的回收由JVM進行。
JVM的記憶體管理方式的優點是顯而易見的，包括：第一，減少系統呼叫的次數，JVM在給Java程式分配記憶體空間時不需要作業系統干預，僅僅在 Java堆大小變化時需要向作業系統申請記憶體或通知回收，而普通程式每次記憶體空間的分配回收都需要系統呼叫參與；第二，減少記憶體洩漏，普通程式沒有（或者 沒有及時）通知作業系統記憶體空間的釋放是記憶體洩漏的重要原因之一，而由JVM統一管理，可以避免程式設計師帶來的記憶體洩漏問題。
最後是未使用區，未使用區是分配新記憶體空間的預備區域。對於普通程序來說，這個區域被可用於堆和棧空間的申請及釋放，每次堆記憶體分配都會使用這個區 域，因此大小變動頻繁；對於JVM程序來說，調整堆大小及執行緒棧時會使用該區域，而堆大小一般較少調整，因此大小相對穩定。作業系統會動態調整這個區域的 大小，並且這個區域通常並沒有被分配實際的實體記憶體，只是允許程序在這個區域申請堆或棧空間。
2.核心記憶體
應用程式通常不直接和核心記憶體打交道，核心記憶體由作業系統進行管理和使用；不過隨著Linux對效能的關注及改進，一些新的特性使得應用程式可以使 用核心記憶體，或者是對映到核心空間。Java NIO正是在這種背景下誕生的，其充分利用了Linux系統的新特性，提升了Java程式的IO效能。
上圖給出了Java NIO使用的核心記憶體在linux系統中的分佈情況。nio buffer主要包括：nio使用各種channel時所使用的ByteBuffer、Java程式主動使用 ByteBuffer.allocateDirector申請分配的Buffer。
而在PageCache裡面，nio使用的記憶體主要包 括：FileChannel.map方式開啟檔案佔用mapped、FileChannel.transferTo和 FileChannel.transferFrom所需要的Cache（圖中標示 nio file）。
通過JMX可以監控到NIO Buffer和 mapped 的使用情況，如下圖所示。不過，FileChannel的實現是通過系統呼叫使用原生的PageCache，過程對於Java是透明的，無法監控到這部分記憶體的使用大小。
Linux和Java NIO在核心記憶體上開闢空間給程式使用，主要是減少不要的複製，以減少IO作業系統呼叫的開銷。例如，將磁碟檔案的資料傳送網絡卡，使用普通方法和NIO時，資料流動比較下圖所示：
將資料在核心記憶體和使用者記憶體之間拷貝是比較消耗資源和時間的事情，而從上圖我們可以看到，通過NIO的方式減少了2次核心記憶體和使用者記憶體之間的資料拷貝。這是Java NIO高效能的重要機制之一（另一個是非同步非阻塞）。
從上面可以看出，核心記憶體對於Java程式效能也非常重要，因此，在劃分系統記憶體使用時候，一定要給核心留出一定可用空間。
三、案例分析
1.記憶體分配問題
通過上面的分析，省略比較小的區域，可以總結JVM佔用的記憶體：
JVM記憶體 ≈ Java永久代 ＋ Java堆(新生代和老年代) ＋ 執行緒棧＋ Java NIO
回到文章開頭提出的問題，原來的記憶體分配是：6g(java堆) ＋ 600m(監控) ＋ 800m(系統)，剩餘大約600m記憶體未分配。
現在分析這600m記憶體的分配情況：
- Linux保留大約200m，這部分是Linux正常執行的需要，
- Java服務的執行緒數量是160個，JVM預設的執行緒棧大小是1m，因此使用160m記憶體，
- Java NIO buffer，通過JMX查到最多佔用了200m，
- Java服務使用NIO大量讀寫檔案，需要使用PageCache，正如前面分析，這個暫時不好定量估算大小。
前三項加起來已經560m，因此可以斷定Linux實體記憶體不夠使用。
細心的人會發現，引言中給出兩個伺服器，一個SWAP最多佔用了2.16g，另外一個SWAP最多佔用了871m；但是，似乎我們的記憶體缺口沒有那麼大。事實上，這是由於SWAP和GC同時進行造成的，從下圖可以看到，SWAP的使用和長時間的GC在同一時刻發生。
SWAP和GC同時發生會導致GC時間很長，JVM嚴重卡頓，極端的情況下會導致服務崩潰。原因如下：JVM進行GC時，時需要對相應堆分割槽的已用 記憶體進行遍歷；假如GC的時候，有堆的一部分內容被交換到SWAP中，遍歷到這部分的時候就需要將其交換回記憶體，同時由於記憶體空間不足，就需要把記憶體中堆 的另外一部分換到SWAP中去；於是在遍歷堆分割槽的過程中，(極端情況下)會把整個堆分割槽輪流往SWAP寫一遍。Linux對SWAP的回收是滯後的，我 們就會看到大量SWAP佔用。上述問題，可以通過減少堆大小，或者增加實體記憶體解決。
因此，我們得出一個結論：部署Java服務的Linux系統，在記憶體分配上，需要避免SWAP的使用；具體如何分配需要綜合考慮不同場景下JVM對Java永久代 、Java堆(新生代和老年代)、執行緒棧、Java NIO所使用記憶體的需求。
2.記憶體洩漏問題
另一個案例是，8g記憶體的伺服器，Linux使用800m，監控程序使用600m，堆大小設定4g；系統可用記憶體有2.5g左右，但是也發生了大量的SWAP佔用。
分析這個問題如下：
-
在這個場景中， Java永久代 、Java堆(新生代和老年代)、執行緒棧所用記憶體基本是固定的，因此，佔用記憶體過多的原因就定位在Java NIO上。
-
根據前面的模型，Java NIO使用的記憶體主要分佈在Linux核心記憶體的System區和PageCache區。檢視監控的記錄，如下圖，我們可以看到發生SWAP之前，也就是 實體記憶體不夠使用的時候，PageCache急劇縮小。因此，可以定位在System區的Java NIO Buffer發生記憶體洩漏。
-
由於NIO的DirectByteBuffer需要在GC的後期被回收，因此連續申請DirectByteBuffer的程式，通常需要呼叫 System.gc()，避免長時間不發生FullGC導致引用在old區的DirectByteBuffer記憶體洩漏。分析到此，可以推斷有兩種可能的 原因：第一，Java程式沒有在必要的時候呼叫System.gc()；第二，System.gc()被禁用。
-
最後是要排查JVM啟動引數和Java程式的DirectByteBuffer使用情況。在本例中，檢視JVM啟動引數，發現啟用了-XX:+DisableExplicitGC導致System.gc()被禁用。
四、總結
本文詳細分析了Linux與JVM的記憶體關係，比較了一般程序與JVM程序使用記憶體的異同點，理解這些特性將對Linux系統記憶體分配、JVM調優、Java程式優化有幫助。限於篇幅關係僅僅列舉兩個案例，希望起到拋磚引玉的作用。