java io操作中通常采用BufferedReader，BufferedInputStream等帶緩沖的IO類處理大文件，不過java nio中引入了一種基于MappedByteBuffer操作大文件的方式，其讀寫性能極高，本文會介紹其性能如此高的內部實現原理。

內存管理

在深入MappedByteBuffer之前，先看看計算機內存管理的幾個術語：

MMC：CPU的內存管理單元。

物理內存：即內存條的內存空間。

虛擬內存：計算機系統內存管理的一種技術。它使得應用程序認為它擁有連續的可用的內存（一個連續完整的地址空間），而實際上，它通常是被分隔成多個物理內存碎片，還有部分暫時存儲在外部磁盤存儲器上，在需要時進行數據交換。

頁面文件：操作系統反映構建并使用虛擬內存的硬盤空間大小而創建的文件，在windows下，即pagefile.sys文件，其存在意味著物理內存被占滿后，將暫時不用的數據移動到硬盤上。

缺頁中斷：當程序試圖訪問已映射在虛擬地址空間中但未被加載至物理內存的一個分頁時，由MMC發出的中斷。如果操作系統判斷此次訪問是有效的，則嘗試將相關的頁從虛擬內存文件中載入物理內存。

為什么會有虛擬內存和物理內存的區別？
如果正在運行的一個進程，它所需的內存是有可能大于內存條容量之和的，如內存條是256M，程序卻要創建一個2G的數據區，那么所有數據不可能都加載到內存（物理內存），必然有數據要放到其他介質中（比如硬盤），待進程需要訪問那部分數據時，再調度進入物理內存。

什么是虛擬內存地址和物理內存地址？
假設你的計算機是32位，那么它的地址總線是32位的，也就是它可以尋址00xFFFFFFFF（4G）的地址空間，但如果你的計算機只有256M的物理內存0x0x0FFFFFFF（256M），同時你的進程產生了一個不在這256M地址空間中的地址，那么計算機該如何處理呢？回答這個問題前，先說明計算機的內存分頁機制。

計算機會對虛擬內存地址空間（32位為4G）進行分頁產生頁（page），對物理內存地址空間（假設256M）進行分頁產生頁幀（page frame），頁和頁幀的大小一樣，所以虛擬內存頁的個數勢必要大于物理內存頁幀的個數。在計算機上有一個頁表（page table），就是映射虛擬內存頁到物理內存頁的，更確切的說是頁號到頁幀號的映射，而且是一對一的映射。
問題來了，虛擬內存頁的個數 > 物理內存頁幀的個數，豈不是有些虛擬內存頁的地址永遠沒有對應的物理內存地址空間？不是的，操作系統是這樣處理的。操作系統有個頁面失效（page fault）功能。操作系統找到一個最少使用的頁幀，使之失效，并把它寫入磁盤，隨后把需要訪問的頁放到頁幀中，并修改頁表中的映射，保證了所有的頁都會被調度。

現在來看看什么是虛擬內存地址和物理內存地址：

虛擬內存地址：由頁號（與頁表中的頁號關聯）和偏移量（頁的小大，即這個頁能存多少數據）組成。

舉個例子，有一個虛擬地址它的頁號是4，偏移量是20，那么他的尋址過程是這樣的：首先到頁表中找到頁號4對應的頁幀號（比如為8），如果頁不在內存中，則用失效機制調入頁，接著把頁幀號和偏移量傳給MMC組成一個物理上真正存在的地址，最后就是訪問物理內存的數據了。

MappedByteBuffer是什么

從繼承結構上看，MappedByteBuffer繼承自ByteBuffer，內部維護了一個邏輯地址address。

示例

通過MappedByteBuffer讀取文件

map過程

FileChannel提供了map方法把文件映射到虛擬內存，通常情況可以映射整個文件，如果文件比較大，可以進行分段映射。

FileChannel中的幾個變量：MapMode mode：內存映像文件訪問的方式，共三種： MapMode.READ_ONLY：只讀，試圖修改得到的緩沖區將導致拋出異常。 MapMode.READ_WRITE：讀/寫，對得到的緩沖區的更改最終將寫入文件；但該更改對映射到同一文件的其他程序不一定是可見的。 MapMode.PRIVATE：私用，可讀可寫,但是修改的內容不會寫入文件，只是buffer自身的改變，這種能力稱之為”copy on write”。position：文件映射時的起始位置。allocationGranularity：Memory allocation size for mapping buffers，通過native函數initIDs初始化。

接下去通過分析源碼，了解一下map過程的內部實現。

通過RandomAccessFile獲取FileChannel。

上述實現可以看出，由于synchronized ，只有一個線程能夠初始化FileChannel。

通過FileChannel.map方法，把文件映射到虛擬內存，并返回邏輯地址address，實現如下：

上述代碼可以看出，最終map通過native函數map0完成文件的映射工作。
1. 如果第一次文件映射導致OOM，則手動觸發垃圾回收，休眠100ms后再次嘗試映射，如果失敗，則拋出異常。
2. 通過newMappedByteBuffer方法初始化MappedByteBuffer實例，不過其最終返回的是DirectByteBuffer的實例，實現如下：

由于FileChannelImpl和DirectByteBuffer不在同一個包中，所以有權限訪問問題，通過AccessController類獲取DirectByteBuffer的構造器進行實例化。

DirectByteBuffer是MappedByteBuffer的一個子類，其實現了對內存的直接操作。

get過程

MappedByteBuffer的get方法最終通過DirectByteBuffer.get方法實現的。

map0()函數返回一個地址address，這樣就無需調用read或write方法對文件進行讀寫，通過address就能夠操作文件。底層采用unsafe.getByte方法，通過（address + 偏移量）獲取指定內存的數據。

第一次訪問address所指向的內存區域，導致缺頁中斷，中斷響應函數會在交換區中查找相對應的頁面，如果找不到（也就是該文件從來沒有被讀入內存的情況），則從硬盤上將文件指定頁讀取到物理內存中（非jvm堆內存）。

如果在拷貝數據時，發現物理內存不夠用，則會通過虛擬內存機制（swap）將暫時不用的物理頁面交換到硬盤的虛擬內存中。

性能分析

從代碼層面上看，從硬盤上將文件讀入內存，都要經過文件系統進行數據拷貝，并且數據拷貝操作是由文件系統和硬件驅動實現的，理論上來說，拷貝數據的效率是一樣的。
但是通過內存映射的方法訪問硬盤上的文件，效率要比read和write系統調用高，這是為什么？

read()是系統調用，首先將文件從硬盤拷貝到內核空間的一個緩沖區，再將這些數據拷貝到用戶空間，實際上進行了兩次數據拷貝；

map()也是系統調用，但沒有進行數據拷貝，當缺頁中斷發生時，直接將文件從硬盤拷貝到用戶空間，只進行了一次數據拷貝。

所以，采用內存映射的讀寫效率要比傳統的read/write性能高。

總結

MappedByteBuffer使用虛擬內存，因此分配(map)的內存大小不受JVM的-Xmx參數限制，但是也是有大小限制的。

如果當文件超出1.5G限制時，可以通過position參數重新map文件后面的內容。

MappedByteBuffer在處理大文件時的確性能很高，但也存在一些問題，如內存占用、文件關閉不確定，被其打開的文件只有在垃圾回收的才會被關閉，而且這個時間點是不確定的。
javadoc中也提到：A mapped byte buffer and the file mapping that it represents remain valid until the buffer itself is garbage-collected.*