在一些物理記憶體為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又不是一個普通的行程，其在記憶體空間上有許多嶄新的特點，主要原因有兩 個：
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記憶體的分配情況：
-
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程式優化有幫助，限于篇幅關系僅僅列舉兩個案例，希望起到拋磚引玉的作用，
來源：美團技術團隊
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/181224.html
標籤：Java