本文轉自：https://www.cnblogs.com/huxiao-tee/p/4660352.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章將同步到我的個人部落格：
> www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《不可輕視的Java網路程式設計》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。

該系列博文會告訴你如何從計算機網路的基礎知識入手，一步步地學習Java網路基礎，從socket到nio、bio、aio和netty等網路程式設計知識，並且進行實戰，網路程式設計是每一個Java後端工程師必須要學習和理解的知識點，進一步來說，你還需要掌握Linux中的網路程式設計原理，包括IO模型、網路程式設計框架netty的進階原理，才能更完整地瞭解整個Java網路程式設計的知識體系，形成自己的知識框架。

為了更好地總結和檢驗你的學習成果，本系列文章也會提供部分知識點對應的面試題以及參考答案。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

**閱讀目錄**

*   [mmap基礎概念](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label0)
*   [mmap記憶體對映原理](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label1)
*   [mmap和常規檔案操作的區別](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label2)
*   [mmap優點總結](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label3)
*   [mmap相關函式](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label4)
*   [mmap使用細節](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_label5)

# mmap基礎概念

mmap是一種記憶體對映檔案的方法，即將一個檔案或者其它物件對映到程式的地址空間，實現檔案磁碟地址和程式虛擬地址空間中一段虛擬地址的一一對映關係。實現這樣的對映關係後，程式就可以採用指標的方式讀寫操作這一段記憶體，而系統會自動回寫髒頁面到對應的檔案磁碟上，即完成了對檔案的操作而不必再呼叫read,write等系統呼叫函式。相反，核心空間對這段區域的修改也直接反映使用者空間，從而可以實現不同程式間的檔案共享。如下圖所示：

![](https://images0.cnblogs.com/blog2015/571793/201507/200501092691998.png)

由上圖可以看出，程式的虛擬地址空間，由多個虛擬記憶體區域構成。虛擬記憶體區域是程式的虛擬地址空間中的一個同質區間，即具有同樣特性的連續地址範圍。上圖中所示的text資料段（程式碼段）、初始資料段、BSS資料段、堆、棧和記憶體對映，都是一個獨立的虛擬記憶體區域。而為記憶體對映服務的地址空間處在堆疊之間的空餘部分。

linux核心使用vm_area_struct結構來表示一個獨立的虛擬記憶體區域，由於每個不同質的虛擬記憶體區域功能和內部機制都不同，因此一個程式使用多個vm_area_struct結構來分別表示不同型別的虛擬記憶體區域。各個vm_area_struct結構使用連結串列或者樹形結構連結，方便程式快速訪問，如下圖所示：

![](https://images0.cnblogs.com/blog2015/571793/201507/200501434261629.png)

vm_area_struct結構中包含區域起始和終止地址以及其他相關資訊，同時也包含一個vm_ops指標，其內部可引出所有針對這個區域可以使用的系統呼叫函式。這樣，程式對某一虛擬記憶體區域的任何操作需要用要的資訊，都可以從vm_area_struct中獲得。mmap函式就是要建立一個新的vm_area_struct結構，並將其與檔案的物理磁碟地址相連。具體步驟請看下一節。

[回到頂部](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_labelTop)

# mmap記憶體對映原理

mmap記憶體對映的實現過程，總的來說可以分為三個階段：

**（一）程式啟動對映過程，並在虛擬地址空間中為對映建立虛擬對映區域**

1、程式在使用者空間呼叫庫函式mmap，原型：void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);

2、在當前程式的虛擬地址空間中，尋找一段空閒的滿足要求的連續的虛擬地址

3、為此虛擬區分配一個vm_area_struct結構，接著對這個結構的各個域進行了初始化

4、將新建的虛擬區結構（vm_area_struct）插入程式的虛擬地址區域連結串列或樹中

**（二）呼叫核心空間的系統呼叫函式mmap（不同於使用者空間函式），實現檔案實體地址和程式虛擬地址的一一對映關係**

5、為對映分配了新的虛擬地址區域後，透過待對映的檔案指標，在檔案描述符表中找到對應的檔案描述符，透過檔案描述符，連結到核心“已開啟檔案集”中該檔案的檔案結構體（struct file），每個檔案結構體維護著和這個已開啟檔案相關各項資訊。

6、透過該檔案的檔案結構體，連結到file_operations模組，呼叫核心函式mmap，其原型為：int mmap(struct file *filp, struct vm_area_struct *vma)，不同於使用者空間庫函式。

7、核心mmap函式透過虛擬檔案系統inode模組定位到檔案磁碟實體地址。

8、透過remap_pfn_range函式建立頁表，即實現了檔案地址和虛擬地址區域的對映關係。此時，這片虛擬地址並沒有任何資料關聯到主存中。

**（三）程式發起對這片對映空間的訪問，引發缺頁異常，實現檔案內容到實體記憶體（主存）的複製**

注：前兩個階段僅在於建立虛擬區間並完成地址對映，但是並沒有將任何檔案資料的複製至主存。真正的檔案讀取是當程式發起讀或寫操作時。

9、程式的讀或寫操作訪問虛擬地址空間這一段對映地址，透過查詢頁表，發現這一段地址並不在物理頁面上。因為目前只建立了地址對映，真正的硬碟資料還沒有複製到記憶體中，因此引發缺頁異常。

10、缺頁異常進行一系列判斷，確定無非法操作後，核心發起請求調頁過程。

11、調頁過程先在交換快取空間（swap cache）中尋找需要訪問的記憶體頁，如果沒有則呼叫nopage函式把所缺的頁從磁碟裝入到主存中。

12、之後程式即可對這片主存進行讀或者寫的操作，如果寫操作改變了其內容，一定時間後系統會自動回寫髒頁面到對應磁碟地址，也即完成了寫入到檔案的過程。

注：修改過的髒頁面並不會立即更新迴檔案中，而是有一段時間的延遲，可以呼叫msync()來強制同步, 這樣所寫的內容就能立即儲存到檔案裡了。

[回到頂部](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_labelTop)

# mmap和常規檔案操作的區別

對linux檔案系統不瞭解的朋友，請參閱我之前寫的博文《[從核心檔案系統看檔案讀寫過程](http://www.cnblogs.com/huxiao-tee/p/4657851.html)》，我們首先簡單的回顧一下常規檔案系統操作（呼叫read/fread等類函式）中，函式的呼叫過程：

1、程式發起讀檔案請求。

2、核心透過查詢程式檔案符表，定位到核心已開啟檔案集上的檔案資訊，從而找到此檔案的inode。

3、inode在address_space上查詢要請求的檔案頁是否已經快取在頁快取中。如果存在，則直接返回這片檔案頁的內容。

4、如果不存在，則透過inode定位到檔案磁碟地址，將資料從磁碟複製到頁快取。之後再次發起讀頁面過程，進而將頁快取中的資料發給使用者程式。

總結來說，常規檔案操作為了提高讀寫效率和保護磁碟，使用了頁快取機制。這樣造成讀檔案時需要先將檔案頁從磁碟複製到頁快取中，由於頁快取處在核心空間，不能被使用者程式直接定址，所以還需要將頁快取中資料頁再次複製到記憶體對應的使用者空間中。這樣，透過了兩次資料複製過程，才能完成程式對檔案內容的獲取任務。寫操作也是一樣，待寫入的buffer在核心空間不能直接訪問，必須要先複製至核心空間對應的主存，再寫回磁碟中（延遲寫回），也是需要兩次資料複製。

而使用mmap操作檔案中，建立新的虛擬記憶體區域和建立檔案磁碟地址和虛擬記憶體區域對映這兩步，沒有任何檔案複製操作。而之後訪問資料時發現記憶體中並無資料而發起的缺頁異常過程，可以透過已經建立好的對映關係，只使用一次資料複製，就從磁碟中將資料傳入記憶體的使用者空間中，供程式使用。

**總而言之，常規檔案操作需要從磁碟到頁快取再到使用者主存的兩次資料複製。而mmap操控檔案，只需要從磁碟到使用者主存的一次資料複製過程。**說白了，mmap的關鍵點是實現了使用者空間和核心空間的資料直接互動而省去了空間不同資料不通的繁瑣過程。因此mmap效率更高。

[回到頂部](https://www.cnblogs.com/huxiao-tee/p/4660352.html#_labelTop)

# mmap優點總結

由上文討論可知，mmap優點共有一下幾點：

1、對檔案的讀取操作跨過了頁快取，減少了資料的複製次數，用記憶體讀寫取代I/O讀寫，提高了檔案讀取效率。

2、實現了使用者空間和核心空間的高效互動方式。兩空間的各自修改操作可以直接反映在對映的區域內，從而被對方空間及時捕捉。

3、提供程式間共享記憶體及相互通訊的方式。不管是父子程式還是無親緣關係的程式，都可以將自身使用者空間對映到同一個檔案或匿名對映到同一片區域。從而透過各自對對映區域的改動，達到程式間通訊和程式間共享的目的。

同時，如果程式A和程式B都對映了區域C，當A第一次讀取C時透過缺頁從磁碟複製檔案頁到記憶體中；但當B再讀C的相同頁面時，雖然也會產生缺頁異常，但是不再需要從磁碟中複製檔案過來，而可直接使用已經儲存在記憶體中的檔案資料。

4、可用於實現高效的大規模資料傳輸。記憶體空間不足，是制約大資料操作的一個方面，解決方案往往是藉助硬碟空間協助操作，補充記憶體的不足。但是進一步會造成大量的檔案I/O操作，極大影響效率。這個問題可以透過mmap對映很好的解決。換句話說，但凡是需要用磁碟空間代替記憶體的時候，mmap都可以發揮其功效。

# mmap使用細節

1、使用mmap需要注意的一個關鍵點是，mmap對映區域大小必須是物理頁大小(page_size)的整倍數（32位系統中通常是4k位元組）。原因是，記憶體的最小粒度是頁，而程式虛擬地址空間和記憶體的對映也是以頁為單位。為了匹配記憶體的操作，mmap從磁碟到虛擬地址空間的對映也必須是頁。

2、核心可以跟蹤被記憶體對映的底層物件（檔案）的大小，程式可以合法的訪問在當前檔案大小以內又在記憶體對映區以內的那些位元組。也就是說，如果檔案的大小一直在擴張，只要在對映區域範圍內的資料，程式都可以合法得到，這和對映建立時檔案的大小無關。具體情形參見“情形三”。

3、對映建立之後，即使檔案關閉，對映依然存在。因為對映的是磁碟的地址，不是檔案本身，和檔案控制程式碼無關。同時可用於程式間通訊的有效地址空間不完全受限於被對映檔案的大小，因為是按頁對映。

在上面的知識前提下，我們下面看看如果大小不是頁的整倍數的具體情況：

**情形一：一個檔案的大小是5000位元組，mmap函式從一個檔案的起始位置開始，對映5000位元組到虛擬記憶體中。**

分析：因為單位物理頁面的大小是4096位元組，雖然被對映的檔案只有5000位元組，但是對應到程式虛擬地址區域的大小需要滿足整頁大小，因此mmap函式執行後，實際對映到虛擬記憶體區域8192個 位元組，5000~8191的位元組部分用零填充。對映後的對應關係如下圖所示：

![](https://images0.cnblogs.com/blog2015/571793/201507/200521495513717.png)

此時：

（1）讀/寫前5000個位元組（0~4999），會返回操作檔案內容。

（2）讀位元組5000~8191時，結果全為0。寫5000~8191時，程式不會報錯，但是所寫的內容不會寫入原檔案中 。

（3）讀/寫8192以外的磁碟部分，會返回一個SIGSECV錯誤。

**情形二：一個檔案的大小是5000位元組，mmap函式從一個檔案的起始位置開始，對映15000位元組到虛擬記憶體中，即對映大小超過了原始檔案的大小。**

分析：由於檔案的大小是5000位元組，和情形一一樣，其對應的兩個物理頁。那麼這兩個物理頁都是合法可以讀寫的，只是超出5000的部分不會體現在原檔案中。由於程式要求對映15000位元組，而檔案只佔兩個物理頁，因此8192位元組~15000位元組都不能讀寫，操作時會返回異常。如下圖所示：

![](https://images0.cnblogs.com/blog2015/571793/201507/200522381763096.png)

此時：

（1）程式可以正常讀/寫被對映的前5000位元組(0~4999)，寫操作的改動會在一定時間後反映在原檔案中。

（2）對於5000~8191位元組，程式可以進行讀寫過程，不會報錯。但是內容在寫入前均為0，另外，寫入後不會反映在檔案中。

（3）對於8192~14999位元組，程式不能對其進行讀寫，會報SIGBUS錯誤。

（4）對於15000以外的位元組，程式不能對其讀寫，會引發SIGSEGV錯誤。

**情形三：一個檔案初始大小為0，使用mmap操作對映了1000*4K的大小，即1000個物理頁大約4M位元組空間，mmap返回指標ptr。**

分析：如果在對映建立之初，就對檔案進行讀寫操作，由於檔案大小為0，並沒有合法的物理頁對應，如同情形二一樣，會返回SIGBUS錯誤。

但是如果，每次操作ptr讀寫前，先增加檔案的大小，那麼ptr在檔案大小內部的操作就是合法的。例如，檔案擴充4096位元組，ptr就能操作ptr ~ [ (char)ptr + 4095]的空間。只要檔案擴充的範圍在1000個物理頁（對映範圍）內，ptr都可以對應操作相同的大小。

這樣，方便隨時擴充檔案空間，隨時寫入檔案，不造成空間浪費。

本文轉自：https://www.jianshu.com/p/007052ee3773

### 堆外記憶體

堆外記憶體是相對於堆內記憶體的一個概念。堆內記憶體是由JVM所管控的Java程式記憶體，我們平時在Java中建立的物件都處於堆內記憶體中，並且它們遵循JVM的記憶體管理機制，JVM會採用垃圾回收機制統一管理它們的記憶體。那麼堆外記憶體就是存在於JVM管控之外的一塊記憶體區域，因此它是不受JVM的管控。

### 在講解DirectByteBuffer之前，需要先簡單瞭解兩個知識點

#### java引用型別，因為DirectByteBuffer是透過虛引用(Phantom Reference)來實現堆外記憶體的釋放的。

PhantomReference 是所有“弱引用”中最弱的引用型別。不同於軟引用和弱引用，虛引用無法透過 get() 方法來取得目標物件的強引用從而使用目標物件，觀察原始碼可以發現 get() 被重寫為永遠返回 null。
那虛引用到底有什麼作用？其實虛引用主要被用來 跟蹤物件被垃圾回收的狀態，透過檢視引用佇列中是否包含物件所對應的虛引用來判斷它是否 即將被垃圾回收，從而採取行動。它並不被期待用來取得目標物件的引用，而目標物件被回收前，它的引用會被放入一個 ReferenceQueue 物件中，從而達到跟蹤物件垃圾回收的作用。
關於java引用型別的實現和原理可以閱讀之前的文章[Reference 、ReferenceQueue 詳解](https://www.jianshu.com/p/f86d3a43eec5) 和[Java 引用型別簡述](https://www.jianshu.com/p/9a089a37f78d)

#### 關於linux的核心態和使用者態

![](https://upload-images.jianshu.io/upload_images/4235178-7c5ca2cb236fd2eb.png?imageMogr2/auto-orient/strip|imageView2/2/w/752/format/webp)

*   核心態：控制計算機的硬體資源，並提供上層應用程式執行的環境。比如socket I/0操作或者檔案的讀寫操作等
*   使用者態：上層應用程式的活動空間，應用程式的執行必須依託於核心提供的資源。
*   系統呼叫：為了使上層應用能夠訪問到這些資源，核心為上層應用提供訪問的介面。

![](https://upload-images.jianshu.io/upload_images/4235178-2393d0797135217b.png?imageMogr2/auto-orient/strip|imageView2/2/w/1200/format/webp)

因此我們可以得知當我們透過JNI呼叫的native方法實際上就是從使用者態切換到了核心態的一種方式。並且透過該系統呼叫使用作業系統所提供的功能。

Q：為什麼需要使用者程式(位於使用者態中)要透過系統呼叫(Java中即使JNI)來呼叫核心態中的資源，或者說呼叫作業系統的服務了？
A：intel cpu提供Ring0-Ring3四種級別的執行模式，Ring0級別最高，Ring3最低。Linux使用了Ring3級別執行使用者態，Ring0作為核心態。Ring3狀態不能訪問Ring0的地址空間，包括程式碼和資料。因此使用者態是沒有許可權去操作核心態的資源的，它只能透過系統呼叫外完成使用者態到核心態的切換，然後在完成相關操作後再有核心態切換回使用者態。

### DirectByteBuffer ———— 直接緩衝

DirectByteBuffer是Java用於實現堆外記憶體的一個重要類，我們可以透過該類實現堆外記憶體的建立、使用和銷燬。

![](https://upload-images.jianshu.io/upload_images/4235178-fc2ae3eac18813d3.png?imageMogr2/auto-orient/strip|imageView2/2/w/726/format/webp)

DirectByteBuffer該類本身還是位於Java記憶體模型的堆中。堆內記憶體是JVM可以直接管控、操縱。
而DirectByteBuffer中的unsafe.allocateMemory(size);是個一個native方法，這個方法分配的是堆外記憶體，透過C的malloc來進行分配的。分配的記憶體是系統本地的記憶體，並不在Java的記憶體中，也不屬於JVM管控範圍，所以在DirectByteBuffer一定會存在某種方式來操縱堆外記憶體。
在DirectByteBuffer的父類Buffer中有個address屬性：

```
    // Used only by direct buffers
    // NOTE: hoisted here for speed in JNI GetDirectBufferAddress
    long address;

```

address只會被直接快取給使用到。之所以將address屬性升級放在Buffer中，是為了在JNI呼叫GetDirectBufferAddress時提升它呼叫的速率。
address表示分配的堆外記憶體的地址。

![](https://upload-images.jianshu.io/upload_images/4235178-5e010dc58916b102.png?imageMogr2/auto-orient/strip|imageView2/2/w/1200/format/webp)

unsafe.allocateMemory(size);分配完堆外記憶體後就會返回分配的堆外記憶體基地址，並將這個地址賦值給了address屬性。這樣我們後面透過JNI對這個堆外記憶體操作時都是透過這個address來實現的了。

在前面我們說過，在linux中核心態的許可權是最高的，那麼在核心態的場景下，作業系統是可以訪問任何一個記憶體區域的，所以作業系統是可以訪問到Java堆的這個記憶體區域的。
Q：那為什麼作業系統不直接訪問Java堆內的記憶體區域了？
A：這是因為JNI方法訪問的記憶體區域是一個已經確定了的記憶體區域地質，那麼該記憶體地址指向的是Java堆內記憶體的話，那麼如果在作業系統正在訪問這個記憶體地址的時候，Java在這個時候進行了GC操作，而GC操作會涉及到資料的移動操作[GC經常會進行先標誌在壓縮的操作。即，將可回收的空間做標誌，然後清空標誌位置的記憶體，然後會進行一個壓縮，壓縮就會涉及到物件的移動，移動的目的是為了騰出一塊更加完整、連續的記憶體空間，以容納更大的新物件]，資料的移動會使JNI呼叫的資料錯亂。所以JNI呼叫的記憶體是不能進行GC操作的。

Q：如上面所說，JNI呼叫的記憶體是不能進行GC操作的，那該如何解決了？
A：①堆內記憶體與堆外記憶體之間資料複製的方式(並且在將堆內記憶體複製到堆外記憶體的過程JVM會保證不會進行GC操作)：比如我們要完成一個從檔案中讀資料到堆內記憶體的操作，即FileChannelImpl.read(HeapByteBuffer)。這裡實際上File I/O會將資料讀到堆外記憶體中，然後堆外記憶體再講資料複製到堆內記憶體，這樣我們就讀到了檔案中的記憶體。

![](https://upload-images.jianshu.io/upload_images/4235178-f94db8df14023550.png?imageMogr2/auto-orient/strip|imageView2/2/w/1194/format/webp)

```
    static int read(FileDescriptor var0, ByteBuffer var1, long var2, NativeDispatcher var4) throws IOException {
        if (var1.isReadOnly()) {
            throw new IllegalArgumentException("Read-only buffer");
        } else if (var1 instanceof DirectBuffer) {
            return readIntoNativeBuffer(var0, var1, var2, var4);
        } else {
            // 分配臨時的堆外記憶體
            ByteBuffer var5 = Util.getTemporaryDirectBuffer(var1.remaining());

int var7;
            try {
                // File I/O 操作會將資料讀入到堆外記憶體中
                int var6 = readIntoNativeBuffer(var0, var5, var2, var4);
                var5.flip();
                if (var6 > 0) {
                    // 將堆外記憶體的資料複製到堆外記憶體中
                    var1.put(var5);
                }

var7 = var6;
            } finally {
                // 裡面會呼叫DirectBuffer.cleaner().clean()來釋放臨時的堆外記憶體
                Util.offerFirstTemporaryDirectBuffer(var5);
            }

return var7;
        }
    }

```

而寫操作則反之，我們會將堆內記憶體的資料線寫到對堆外記憶體中，然後作業系統會將堆外記憶體的資料寫入到檔案中。
② 直接使用堆外記憶體，如DirectByteBuffer：這種方式是直接在堆外分配一個記憶體(即，native memory)來儲存資料，程式透過JNI直接將資料讀/寫到堆外記憶體中。因為資料直接寫入到了堆外記憶體中，所以這種方式就不會再在JVM管控的堆內再分配記憶體來儲存資料了，也就不存在堆內記憶體和堆外記憶體資料複製的操作了。這樣在進行I/O操作時，只需要將這個堆外記憶體地址傳給JNI的I/O的函式就好了。

### DirectByteBuffer堆外記憶體的建立和回收的原始碼解讀

#### 堆外記憶體分配

```
    DirectByteBuffer(int cap) {                   // package-private
        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        // 保留總分配記憶體(按頁分配)的大小和實際記憶體的大小
        Bits.reserveMemory(size, cap);

long base = 0;
        try {
            // 透過unsafe.allocateMemory分配堆外記憶體，並返回堆外記憶體的基地址
            base = unsafe.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        // 構建Cleaner物件用於跟蹤DirectByteBuffer物件的垃圾回收，以實現當DirectByteBuffer被垃圾回收時，堆外記憶體也會被釋放
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;
    }

```

#### Bits.reserveMemory(size, cap) 方法

```
    static void reserveMemory(long size, int cap) {

if (!memoryLimitSet && VM.isBooted()) {
            maxMemory = VM.maxDirectMemory();
            memoryLimitSet = true;
        }

// optimist!
        if (tryReserveMemory(size, cap)) {
            return;
        }

final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();

// retry while helping enqueue pending Reference objects
        // which includes executing pending Cleaner(s) which includes
        // Cleaner(s) that free direct buffer memory
        while (jlra.tryHandlePendingReference()) {
            if (tryReserveMemory(size, cap)) {
                return;
            }
        }

// trigger VM's Reference processing
        System.gc();

// a retry loop with exponential back-off delays
        // (this gives VM some time to do it's job)
        boolean interrupted = false;
        try {
            long sleepTime = 1;
            int sleeps = 0;
            while (true) {
                if (tryReserveMemory(size, cap)) {
                    return;
                }
                if (sleeps >= MAX_SLEEPS) {
                    break;
                }
                if (!jlra.tryHandlePendingReference()) {
                    try {
                        Thread.sleep(sleepTime);
                        sleepTime <<= 1;
                        sleeps++;
                    } catch (InterruptedException e) {
                        interrupted = true;
                    }
                }
            }

// no luck
            throw new OutOfMemoryError("Direct buffer memory");

} finally {
            if (interrupted) {
                // don't swallow interrupts
                Thread.currentThread().interrupt();
            }
        }
    }

```

該方法用於在系統中儲存總分配記憶體(按頁分配)的大小和實際記憶體的大小。

其中，如果系統中記憶體( 即，堆外記憶體 )不夠的話：

```
        final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();

// retry while helping enqueue pending Reference objects
        // which includes executing pending Cleaner(s) which includes
        // Cleaner(s) that free direct buffer memory
        while (jlra.tryHandlePendingReference()) {
            if (tryReserveMemory(size, cap)) {
                return;
            }
        }

```

jlra.tryHandlePendingReference()會觸發一次非堵塞的Reference#tryHandlePending(false)。該方法會將已經被JVM垃圾回收的DirectBuffer物件的堆外記憶體釋放。
因為在Reference的靜態程式碼塊中定義了：

```
        SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
            @Override
            public boolean tryHandlePendingReference() {
                return tryHandlePending(false);
            }
        });

```

如果在進行一次堆外記憶體資源回收後，還不夠進行本次堆外記憶體分配的話，則

```
        // trigger VM's Reference processing
        System.gc();

```

System.gc()會觸發一個full gc，當然前提是你沒有顯示的設定-XX:+DisableExplicitGC來禁用顯式GC。並且你需要知道，呼叫System.gc()並不能夠保證full gc馬上就能被執行。
所以在後面打程式碼中，會進行最多9次嘗試，看是否有足夠的可用堆外記憶體來分配堆外記憶體。並且每次嘗試之前，都對延遲等待時間，已給JVM足夠的時間去完成full gc操作。如果9次嘗試後依舊沒有足夠的可用堆外記憶體來分配本次堆外記憶體，則丟擲OutOfMemoryError("Direct buffer memory”)異常。

![](https://upload-images.jianshu.io/upload_images/4235178-6da0d60191992f59.png?imageMogr2/auto-orient/strip|imageView2/2/w/449/format/webp)

注意，這裡之所以用使用full gc的很重要的一個原因是：System.gc()會對新生代的老生代都會進行記憶體回收，這樣會比較徹底地回收DirectByteBuffer物件以及他們關聯的堆外記憶體.
DirectByteBuffer物件本身其實是很小的，但是它後面可能關聯了一個非常大的堆外記憶體，因此我們通常稱之為冰山物件.
我們做ygc的時候會將新生代裡的不可達的DirectByteBuffer物件及其堆外記憶體回收了，但是無法對old裡的DirectByteBuffer物件及其堆外記憶體進行回收，這也是我們通常碰到的最大的問題。( 並且堆外記憶體多用於生命期中等或較長的物件 )
如果有大量的DirectByteBuffer物件移到了old，但是又一直沒有做cms gc或者full gc，而只進行ygc，那麼我們的實體記憶體可能被慢慢耗光，但是我們還不知道發生了什麼，因為heap明明剩餘的記憶體還很多(前提是我們禁用了System.gc – JVM引數DisableExplicitGC)。

總的來說，Bits.reserveMemory(size, cap)方法在可用堆外記憶體不足以分配給當前要建立的堆外記憶體大小時，會實現以下的步驟來嘗試完成本次堆外記憶體的建立：
① 觸發一次非堵塞的Reference#tryHandlePending(false)。該方法會將已經被JVM垃圾回收的DirectBuffer物件的堆外記憶體釋放。
② 如果進行一次堆外記憶體資源回收後，還不夠進行本次堆外記憶體分配的話，則進行 System.gc()。System.gc()會觸發一個full gc，但你需要知道，呼叫System.gc()並不能夠保證full gc馬上就能被執行。所以在後面打程式碼中，會進行最多9次嘗試，看是否有足夠的可用堆外記憶體來分配堆外記憶體。並且每次嘗試之前，都對延遲等待時間，已給JVM足夠的時間去完成full gc操作。
注意，如果你設定了-XX:+DisableExplicitGC，將會禁用顯示GC，這會使System.gc()呼叫無效。
③ 如果9次嘗試後依舊沒有足夠的可用堆外記憶體來分配本次堆外記憶體，則丟擲OutOfMemoryError("Direct buffer memory”)異常。

那麼可用堆外記憶體到底是多少了？，即預設堆外存記憶體有多大：
① 如果我們沒有透過-XX:MaxDirectMemorySize來指定最大的堆外記憶體。則?
② 如果我們沒透過-Dsun.nio.MaxDirectMemorySize指定了這個屬性，且它不等於-1。則?
③ 那麼最大堆外記憶體的值來自於directMemory = Runtime.getRuntime().maxMemory()，這是一個native方法

```
JNIEXPORT jlong JNICALL
Java_java_lang_Runtime_maxMemory(JNIEnv *env, jobject this)
{
    return JVM_MaxMemory();
}

JVM_ENTRY_NO_ENV(jlong, JVM_MaxMemory(void))
  JVMWrapper("JVM_MaxMemory");
  size_t n = Universe::heap()->max_capacity();
  return convert_size_t_to_jlong(n);
JVM_END

```

其中在我們使用CMS GC的情況下也就是我們設定的-Xmx的值裡除去一個survivor的大小就是預設的堆外記憶體的大小了。

#### 堆外記憶體回收

Cleaner是PhantomReference的子類，並透過自身的next和prev欄位維護的一個雙向連結串列。PhantomReference的作用在於跟蹤垃圾回收過程，並不會對物件的垃圾回收過程造成任何的影響。
所以cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); 用於對當前構造的DirectByteBuffer物件的垃圾回收過程進行跟蹤。
當DirectByteBuffer物件從pending狀態 ——> enqueue狀態時，會觸發Cleaner的clean()，而Cleaner的clean()的方法會實現透過unsafe對堆外記憶體的釋放。

![](https://upload-images.jianshu.io/upload_images/4235178-792afac32aefd061.png?imageMogr2/auto-orient/strip|imageView2/2/w/713/format/webp)

![](https://upload-images.jianshu.io/upload_images/4235178-07eaab88f1d02927.png?imageMogr2/auto-orient/strip|imageView2/2/w/750/format/webp)

?雖然Cleaner不會呼叫到Reference.clear()，但Cleaner的clean()方法呼叫了remove(this)，即將當前Cleaner從Cleaner連結串列中移除，這樣當clean()執行完後，Cleaner就是一個無引用指向的物件了，也就是可被GC回收的物件。

thunk方法：

![](https://upload-images.jianshu.io/upload_images/4235178-ebeffa00197df134.png?imageMogr2/auto-orient/strip|imageView2/2/w/515/format/webp)

#### 透過配置引數的方式來回收堆外記憶體

同時我們可以透過-XX:MaxDirectMemorySize來指定最大的堆外記憶體大小，當使用達到了閾值的時候將呼叫System.gc()來做一次full gc，以此來回收掉沒有被使用的堆外記憶體。

### 堆外記憶體那些事

#### 使用堆外記憶體的原因

*   對垃圾回收停頓的改善
    因為full gc 意味著徹底回收，徹底回收時，垃圾收集器會對所有分配的堆內記憶體進行完整的掃描，這意味著一個重要的事實——這樣一次垃圾收集對Java應用造成的影響，跟堆的大小是成正比的。過大的堆會影響Java應用的效能。如果使用堆外記憶體的話，堆外記憶體是直接受作業系統管理( 而不是虛擬機器 )。這樣做的結果就是能保持一個較小的堆內記憶體，以減少垃圾收集對應用的影響。
*   在某些場景下可以提升程式I/O操縱的效能。少去了將資料從堆內記憶體複製到堆外記憶體的步驟。

#### 什麼情況下使用堆外記憶體

*   堆外記憶體適用於生命週期中等或較長的物件。( 如果是生命週期較短的物件，在YGC的時候就被回收了，就不存在大記憶體且生命週期較長的物件在FGC對應用造成的效能影響 )。
*   直接的檔案複製操作，或者I/O操作。直接使用堆外記憶體就能少去記憶體從使用者記憶體複製到系統記憶體的操作，因為I/O操作是系統核心記憶體和裝置間的通訊，而不是透過程式直接和外設通訊的。
*   同時，還可以使用 池+堆外記憶體 的組合方式，來對生命週期較短，但涉及到I/O操作的物件進行堆外記憶體的再使用。( Netty中就使用了該方式 )

#### 堆外記憶體 VS 記憶體池

*   記憶體池：主要用於兩類物件：①生命週期較短，且結構簡單的物件，在記憶體池中重複利用這些物件能增加CPU快取的命中率，從而提高效能；②載入含有大量重複物件的大片資料，此時使用記憶體池能減少垃圾回收的時間。
*   堆外記憶體：它和記憶體池一樣，也能縮短垃圾回收時間，但是它適用的物件和記憶體池完全相反。記憶體池往往適用於生命期較短的可變物件，而生命期中等或較長的物件，正是堆外記憶體要解決的。

#### 堆外記憶體的特點

*   對於大記憶體有良好的伸縮性
*   對垃圾回收停頓的改善可以明顯感覺到
*   在程式間可以共享，減少虛擬機器間的複製

#### 堆外記憶體的一些問題

*   堆外記憶體回收問題，以及堆外記憶體的洩漏問題。這個在上面的原始碼解析已經提到了
*   堆外記憶體的資料結構問題：堆外記憶體最大的問題就是你的資料結構變得不那麼直觀，如果資料結構比較複雜，就要對它進行序列化（serialization），而序列化本身也會影響效能。另一個問題是由於你可以使用更大的記憶體，你可能開始擔心虛擬記憶體（即硬碟）的速度對你的影響了。

## 參考文章

[http://lovestblog.cn/blog/2015/05/12/direct-buffer/](https://link.jianshu.com/?t=http://lovestblog.cn/blog/2015/05/12/direct-buffer/)
[http://www.infoq.com/cn/news/2014/12/external-memory-heap-memory](https://link.jianshu.com/?t=http://www.infoq.com/cn/news/2014/12/external-memory-heap-memory)
[http://www.jianshu.com/p/85e931636f27](https://www.jianshu.com/p/85e931636f27)
聖思園《併發與Netty》課程

Java網路程式設計與NIO詳解8：淺析mmap和Direct Buffer

相關文章