引言

在一些物理內存為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的數據時，必須先將其換回到內存中。

從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物理內存不夠使用。

細心的人會發現，引言中給出兩個服務器，一個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占用。
分析這個問題如下：
(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程序優化有幫助。限于篇幅關系僅僅列舉兩個案例，希望起到拋磚引玉的作用。

參考

1. http://www.ibm.com/developerworks/library/j-nativememory-linux/
2. http://www.ibm.com/developerworks/library/l-kernel-memory-access/
3. http://www.ibm.com/developerworks/library/j-zerocopy/
4. 《深入分析Java Web技術內幕》
   
   本文轉載自：https://tech.meituan.com/linux-jvm-memory.html