JVM 與 Linux 的內存關係 java開發必看！！！

JVM 與 Linux 的內存關係 java開發必看！！！

不創建在物理機器上的軟件運行都是扯淡

更好看的格式：https://www.yuque.com/shizhiy...

在一些物理內存爲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進程的內存特色。

用戶內存

上圖特別強調了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的內存管理方式的優勢，包括：

1. 第一，減小系統調用的次數，JVM在給Java程序分配內存空間時不須要操做系統干預，僅僅在 Java堆大小變化時須要向操做系統申請內存或通知回收，而普通程序每次內存空間的分配回收都須要系統調用參與；
2. 第二，減小內存泄漏，普通程序沒有（或者 沒有及時）通知操做系統內存空間的釋放是內存泄漏的重要緣由之一，而由JVM統一管理，能夠避免程序員帶來的內存泄漏問題。

最後是未使用區 未使用區是分配新內存空間的預備區域。
對於普通進程來講，這個區域被可用於堆和棧空間的申請及釋放，每次堆內存分配都會使用這個區 域，所以大小變更頻繁；
對於JVM進程來講，調整堆大小及線程棧時會使用該區域，而堆大小通常較少調整，所以大小相對穩定。操做系統會動態調整這個區域的 大小，而且這個區域一般並無被分配實際的物理內存，只是容許進程在這個區域申請堆或棧空間。

內核內存

應用程序一般不直接和內核內存打交道，內核內存由操做系統進行管理和使用；

不過隨着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程序性能也很是重要，

所以，在劃分系統內存使用時候，必定要給內核留出必定可用空間。

案例分析

內存分配問題

經過上面的分析，省略比較小的區域，能夠總結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所使用內存的需求。

內存泄漏問題

另外一個案例是，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()被禁用