引言
在一些物理內存為8g的server上，主要執行一個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的數據時，必須先將其換回到內存中。
從Linux系統上看，除了引導系統的BIN區，整個內存空間主要被分成兩個部分：內核內存（Kernel space）、用戶內存（User space）。
內核內存是Linux自身使用的內存空間，主要提供給程序調度、內存分配、連接硬件資源等程序邏輯使用。用戶內存是提供給各個進程主要空間，Linux給各個進程提供同樣的虛擬內存空間；這使得進程之間相互獨立，互不干擾。實現的方法是採用虛擬內存技術：給每個進程一定虛擬內存空間，而僅僅有當虛擬內存實際被使用時，才分配物理內存。例如以下圖所看到的，對於32的Linux系統來說，一般將0～3G的虛擬內存空間分配做為用戶空間，將3～4G的虛擬內存空間分配為內核空間；64位系統的划分情況是類似的。
從進程的角度來看，進程能直接訪問的用戶內存（虛擬內存空間）被划分為5個部分：代碼區、數據區、堆區、棧區、未使用區。
代碼區中存放應用程序的機器代碼。執行過程中代碼不能被改動，具有僅僅讀和固定大小的特點。數據區中存放了應用程序中的全局數據，靜態數據和一些常量字符串等，其大小也是固定的。
堆是執行時程序動態申請的空間，屬於程序執行時直接申請、釋放的內存資源。棧區用來存放函數的傳入參數、暫時變量，以及返回地址等數據。未使用區是分配新內存空間的預備區域。
二、進程與JVM內存模型
JVM本質就是一個進程，因此其內存模型也有進程的一般特點。
可是，JVM又不是一個普通的進程。其在內存模型上有很多嶄新的特點，主要原因有兩個：1.JVM將很多本來屬於操作系統管理范疇的東西，移植到了JVM內部，目的在於降低系統調用的次數；2. 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內存的分配情況：
(1)Linux保留大約200m。這部分是Linux正常執行的須要，
(2)Java服務的線程數量是160個，JVM默認的線程棧大小是1m。因此使用160m內存，
(3)Java NIO buffer，通過JMX查到最多占用了200m，
(4)Java服務使用NIO大量讀寫文件，須要使用PageCache，正如前面分析，這個臨時不好定量估算大小。
前三項加起來已經560m，因此能夠斷定Linux物理內存不夠使用。
細心的人會發現，引言中給出兩個server，一個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內存的server，Linux使用800m，監控進程使用600m，堆大小設置4g。系統可用內存有2.5g左右，可是也發生了大量的SWAP占用。
分析這個問題例如以下：
(1)在這個場景中， Java永久代 、Java堆(新生代和老年代)、線程棧所用內存基本是固定的，因此。占用內存過多的原因就定位在Java NIO上。
(2)依據前面的模型，Java NIO使用的內存主要分布在Linux內核內存的System區和PageCache區。查看監控的記錄，例如以下圖，我們能夠看到發生SWAP之前。也就是物理內存不夠使用的時候，PageCache急劇縮小。因此，能夠定位在System區的Java NIO Buffer發生內存泄漏。
(3)因為NIO的DirectByteBuffer須要在GC的后期被回收。因此連續申請DirectByteBuffer的程序，通常須要調用System.gc()，避免長時間不發生FullGC導致引用在old區的DirectByteBuffer內存泄漏。
分析到此，能夠判斷有兩種可能的原因：第一，Java程序沒有在必要的時候調用System.gc()；第二，System.gc()被禁用。
(4)最后是要排查JVM啟動參數和Java程序的DirectByteBuffer使用情況。在本例中，查看JVM啟動參數。發現啟用了-XX:+DisableExplicitGC導致System.gc()被禁用。
四、總結
本文具體分析了Linux與JVM的內存關系，比較了一般進程與JVM進程使用內存的異同點，理解這些特性將對Linux系統內存分配、JVM調優、Java程序優化有幫助。限於篇幅關系只列舉兩個案例。希望起到拋磚引玉的作用。