圖片來自 Pexels

它的作用是在數(shù)據(jù)報從網(wǎng)絡設備到用戶程序空間傳遞的過程中，減少數(shù)據(jù)拷貝次數(shù)，減少系統(tǒng)調用，實現(xiàn) CPU 的零參與，徹底消除 CPU 在這方面的負載。

實現(xiàn)零拷貝用到的最主要技術是 DMA 數(shù)據(jù)傳輸技術和內存區(qū)域映射技術：

• 零拷貝機制可以減少數(shù)據(jù)在內核緩沖區(qū)和用戶進程緩沖區(qū)之間反復的 I/O 拷貝操作。

• 零拷貝機制可以減少用戶進程地址空間和內核地址空間之間因為上下文切換而帶來的 CPU 開銷。

下面給出兩個進程 A、B 各自的虛擬內存空間以及對應的物理內存之間的地址映射示意圖：

• 用戶進程向操作系統(tǒng)發(fā)出內存申請請求。

• 系統(tǒng)會檢查進程的虛擬地址空間是否被用完，如果有剩余，給進程分配虛擬地址。

• 系統(tǒng)為這塊虛擬地址創(chuàng)建內存映射（Memory Mapping），并將它放進該進程的頁表（Page Table）。

• 系統(tǒng)返回虛擬地址給用戶進程，用戶進程開始訪問該虛擬地址。

• CPU 根據(jù)虛擬地址在此進程的頁表（Page Table）中找到了相應的內存映射（Memory Mapping），但是這個內存映射（Memory Mapping）沒有和物理內存關聯(lián)，于是產(chǎn)生缺頁中斷。

• 操作系統(tǒng)收到缺頁中斷后，分配真正的物理內存并將它關聯(lián)到頁表相應的內存映射（Memory Mapping）。中斷處理完成后，CPU 就可以訪問內存了

• 當然缺頁中斷不是每次都會發(fā)生，只有系統(tǒng)覺得有必要延遲分配內存的時候才用的著，也即很多時候在上面的第 3 步系統(tǒng)會分配真正的物理內存并和內存映射（Memory Mapping）進行關聯(lián)。

• 地址空間：提供更大的地址空間，并且地址空間是連續(xù)的，使得程序編寫、鏈接更加簡單。

• 進程隔離：不同進程的虛擬地址之間沒有關系，所以一個進程的操作不會對其他進程造成影響。

• 數(shù)據(jù)保護：每塊虛擬內存都有相應的讀寫屬性，這樣就能保護程序的代碼段不被修改，數(shù)據(jù)塊不能被執(zhí)行等，增加了系統(tǒng)的安全性。

• 內存映射：有了虛擬內存之后，可以直接映射磁盤上的文件（可執(zhí)行文件或動態(tài)庫）到虛擬地址空間。

  這樣可以做到物理內存延時分配，只有在需要讀相應的文件的時候，才將它真正的從磁盤上加載到內存中來，而在內存吃緊的時候又可以將這部分內存清空掉，提高物理內存利用效率，并且所有這些對應用程序都是透明的。

• 共享內存：比如動態(tài)庫只需要在內存中存儲一份，然后將它映射到不同進程的虛擬地址空間中，讓進程覺得自己獨占了這個文件。

  進程間的內存共享也可以通過映射同一塊物理內存到進程的不同虛擬地址空間來實現(xiàn)共享。

• 物理內存管理：物理地址空間全部由操作系統(tǒng)管理，進程無法直接分配和回收，從而系統(tǒng)可以更好的利用內存，平衡進程間對內存的需求。

下圖是一個進程的用戶空間和內核空間的內存布局：

• 進程私有的虛擬內存：每個進程都有單獨的內核棧、頁表、task 結構以及 mem_map 結構等。

• 進程共享的虛擬內存：屬于所有進程共享的內存區(qū)域，包括物理存儲器、內核數(shù)據(jù)和內核代碼區(qū)域。

• 運行時棧：由編譯器自動釋放，存放函數(shù)的參數(shù)值，局部變量和方法返回值等。每當一個函數(shù)被調用時，該函數(shù)的返回類型和一些調用的信息被存儲到棧頂，調用結束后調用信息會被彈出并釋放掉內存。

  棧區(qū)是從高地址位向低地址位增長的，是一塊連續(xù)的內在區(qū)域，最大容量是由系統(tǒng)預先定義好的，申請的?？臻g超過這個界限時會提示溢出，用戶能從棧中獲取的空間較小。

• 運行時堆：用于存放進程運行中被動態(tài)分配的內存段，位于 BSS 和棧中間的地址位。由卡發(fā)人員申請分配（malloc）和釋放（free）。堆是從低地址位向高地址位增長，采用鏈式存儲結構。

  頻繁地 malloc/free 造成內存空間的不連續(xù)，產(chǎn)生大量碎片。當申請堆空間時，庫函數(shù)按照一定的算法搜索可用的足夠大的空間。因此堆的效率比棧要低的多。

• 代碼段：存放 CPU 可以執(zhí)行的機器指令，該部分內存只能讀不能寫。通常代碼區(qū)是共享的，即其他執(zhí)行程序可調用它。假如機器中有數(shù)個進程運行相同的一個程序，那么它們就可以使用同一個代碼段。

• 未初始化的數(shù)據(jù)段：存放未初始化的全局變量，BSS 的數(shù)據(jù)在程序開始執(zhí)行之前被初始化為 0 或 NULL。

• 已初始化的數(shù)據(jù)段：存放已初始化的全局變量，包括靜態(tài)全局變量、靜態(tài)局部變量以及常量。

• 內存映射區(qū)域：例如將動態(tài)庫，共享內存等虛擬空間的內存映射到物理空間的內存，一般是 mmap 函數(shù)所分配的虛擬內存空間。

內核態(tài)可以執(zhí)行任意命令，調用系統(tǒng)的一切資源，而用戶態(tài)只能執(zhí)行簡單的運算，不能直接調用系統(tǒng)資源。用戶態(tài)必須通過系統(tǒng)接口（System Call），才能向內核發(fā)出指令。

• 內核空間可以訪問所有的 CPU 指令和所有的內存空間、I/O 空間和硬件設備。

• 用戶空間只能訪問受限的資源，如果需要特殊權限，可以通過系統(tǒng)調用獲取相應的資源。

• 用戶空間允許頁面中斷，而內核空間則不允許。

• 內核空間和用戶空間是針對線性地址空間的。

• x86 CPU 中用戶空間是 0-3G 的地址范圍，內核空間是 3G-4G 的地址范圍。

  x86_64 CPU 用戶空間地址范圍為0x0000000000000000–0x00007fffffffffff，內核地址空間為 0xffff880000000000-最大地址。

• 所有內核進程（線程）共用一個地址空間，而用戶進程都有各自的地址空間。

有了用戶空間和內核空間的劃分后，Linux 內部層級結構可以分為三部分，從最底層到最上層依次是硬件、內核空間和用戶空間，如下圖所示：

在 DMA 技術出現(xiàn)之前，應用程序與磁盤之間的 I/O 操作都是通過 CPU 的中斷完成的。

• 用戶進程向 CPU 發(fā)起 read 系統(tǒng)調用讀取數(shù)據(jù)，由用戶態(tài)切換為內核態(tài)，然后一直阻塞等待數(shù)據(jù)的返回。

• CPU 在接收到指令以后對磁盤發(fā)起 I/O 請求，將磁盤數(shù)據(jù)先放入磁盤控制器緩沖區(qū)。

• 數(shù)據(jù)準備完成以后，磁盤向 CPU 發(fā)起 I/O 中斷。

• CPU 收到 I/O 中斷以后將磁盤緩沖區(qū)中的數(shù)據(jù)拷貝到內核緩沖區(qū)，然后再從內核緩沖區(qū)拷貝到用戶緩沖區(qū)。

• 用戶進程由內核態(tài)切換回用戶態(tài)，解除阻塞狀態(tài)，然后等待 CPU 的下一個執(zhí)行時間鐘。

目前大多數(shù)的硬件設備，包括磁盤控制器、網(wǎng)卡、顯卡以及聲卡等都支持 DMA 技術。

這樣在大部分時間里，CPU 計算和 I/O 操作都處于并行操作，使整個計算機系統(tǒng)的效率大大提高。

• 用戶進程向 CPU 發(fā)起 read 系統(tǒng)調用讀取數(shù)據(jù)，由用戶態(tài)切換為內核態(tài)，然后一直阻塞等待數(shù)據(jù)的返回。

• CPU 在接收到指令以后對 DMA 磁盤控制器發(fā)起調度指令。

• DMA 磁盤控制器對磁盤發(fā)起 I/O 請求，將磁盤數(shù)據(jù)先放入磁盤控制器緩沖區(qū)，CPU 全程不參與此過程。

• 數(shù)據(jù)讀取完成后，DMA 磁盤控制器會接受到磁盤的通知，將數(shù)據(jù)從磁盤控制器緩沖區(qū)拷貝到內核緩沖區(qū)。

• DMA 磁盤控制器向 CPU 發(fā)出數(shù)據(jù)讀完的信號，由 CPU 負責將數(shù)據(jù)從內核緩沖區(qū)拷貝到用戶緩沖區(qū)。

• 用戶進程由內核態(tài)切換回用戶態(tài)，解除阻塞狀態(tài)，然后等待 CPU 的下一個執(zhí)行時間鐘。

偽代碼如下：

下圖分別對應傳統(tǒng) I/O 操作的數(shù)據(jù)讀寫流程，整個過程涉及 2 次 CPU 拷貝、2 次 DMA 拷貝，總共 4 次拷貝，以及 4 次上下文切換。

• 上下文切換：當用戶程序向內核發(fā)起系統(tǒng)調用時，CPU 將用戶進程從用戶態(tài)切換到內核態(tài)；當系統(tǒng)調用返回時，CPU 將用戶進程從內核態(tài)切換回用戶態(tài)。

• CPU 拷貝：由 CPU 直接處理數(shù)據(jù)的傳送，數(shù)據(jù)拷貝時會一直占用 CPU 的資源。

• DMA 拷貝：由 CPU 向DMA磁盤控制器下達指令，讓 DMA 控制器來處理數(shù)據(jù)的傳送，數(shù)據(jù)傳送完畢再把信息反饋給 CPU，從而減輕了 CPU 資源的占有率。

如果數(shù)據(jù)不存在，則先將數(shù)據(jù)從磁盤加載數(shù)據(jù)到內核空間的讀緩存（read buffer）中，再從讀緩存拷貝到用戶進程的頁內存中。

read(file_fd, tmp_buf, len);

• 用戶進程通過 read() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從主存或硬盤拷貝到內核空間（kernel space）的讀緩沖區(qū)（read buffer）。

• CPU 將讀緩沖區(qū)（read buffer）中的數(shù)據(jù)拷貝到用戶空間（user space）的用戶緩沖區(qū)（user buffer）。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），read 調用執(zhí)行返回。

當應用程序準備好數(shù)據(jù)，執(zhí)行 write 系統(tǒng)調用發(fā)送網(wǎng)絡數(shù)據(jù)時，先將數(shù)據(jù)從用戶空間的頁緩存拷貝到內核空間的網(wǎng)絡緩沖區(qū)（socket buffer）中，然后再將寫緩存中的數(shù)據(jù)拷貝到網(wǎng)卡設備完成數(shù)據(jù)發(fā)送。

• 用戶進程通過 write() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 將用戶緩沖區(qū)（user buffer）中的數(shù)據(jù)拷貝到內核空間（kernel space）的網(wǎng)絡緩沖區(qū)（socket buffer）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從網(wǎng)絡緩沖區(qū)（socket buffer）拷貝到網(wǎng)卡進行數(shù)據(jù)傳輸。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），write 系統(tǒng)調用執(zhí)行返回。

• 用戶態(tài)直接 I/O：應用程序可以直接訪問硬件存儲，操作系統(tǒng)內核只是輔助數(shù)據(jù)傳輸。

  這種方式依舊存在用戶空間和內核空間的上下文切換，硬件上的數(shù)據(jù)直接拷貝至了用戶空間，不經(jīng)過內核空間。因此，直接 I/O 不存在內核空間緩沖區(qū)和用戶空間緩沖區(qū)之間的數(shù)據(jù)拷貝。

• 減少數(shù)據(jù)拷貝次數(shù)：在數(shù)據(jù)傳輸過程中，避免數(shù)據(jù)在用戶空間緩沖區(qū)和系統(tǒng)內核空間緩沖區(qū)之間的 CPU 拷貝，以及數(shù)據(jù)在系統(tǒng)內核空間內的 CPU 拷貝，這也是當前主流零拷貝技術的實現(xiàn)思路。

• 寫時復制技術：寫時復制指的是當多個進程共享同一塊數(shù)據(jù)時，如果其中一個進程需要對這份數(shù)據(jù)進行修改，那么將其拷貝到自己的進程地址空間中，如果只是數(shù)據(jù)讀取操作則不需要進行拷貝操作。

數(shù)據(jù)直接跨過內核進行傳輸，內核在數(shù)據(jù)傳輸過程除了進行必要的虛擬存儲配置工作之外，不參與任何其他工作，這種方式能夠直接繞過內核，極大提高了性能。

mmap 是 Linux 提供的一種內存映射文件方法，即將一個進程的地址空間中的一段虛擬地址映射到磁盤文件地址，mmap+write 的偽代碼如下：

tmp_buf = mmap(file_fd, len);
write(socket_fd, tmp_buf, len);

然而內核讀緩沖區(qū)（read buffer）仍需將數(shù)據(jù)拷貝到內核寫緩沖區(qū)（socket buffer），大致的流程如下圖所示：

• 用戶進程通過 mmap() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• 將用戶進程的內核空間的讀緩沖區(qū)（read buffer）與用戶空間的緩存區(qū)（user buffer）進行內存地址映射。

• CPU 利用 DMA 控制器將數(shù)據(jù)從主存或硬盤拷貝到內核空間（kernel space）的讀緩沖區(qū)（read buffer）。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），mmap 系統(tǒng)調用執(zhí)行返回。

• 用戶進程通過 write() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 將讀緩沖區(qū)（read buffer）中的數(shù)據(jù)拷貝到網(wǎng)絡緩沖區(qū)（socket buffer）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從網(wǎng)絡緩沖區(qū)（socket buffer）拷貝到網(wǎng)卡進行數(shù)據(jù)傳輸。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），write 系統(tǒng)調用執(zhí)行返回。

Sendfile 系統(tǒng)調用的引入，不僅減少了 CPU 拷貝的次數(shù)，還減少了上下文切換的次數(shù)，它的偽代碼如下：

與 mmap 內存映射方式不同的是， Sendfile 調用中 I/O 數(shù)據(jù)對用戶空間是完全不可見的。也就是說，這是一次完全意義上的數(shù)據(jù)傳輸過程。

• 用戶進程通過 sendfile() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從主存或硬盤拷貝到內核空間（kernel space）的讀緩沖區(qū)（read buffer）。

• CPU 將讀緩沖區(qū)（read buffer）中的數(shù)據(jù)拷貝到的網(wǎng)絡緩沖區(qū)（socket buffer）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從網(wǎng)絡緩沖區(qū)（socket buffer）拷貝到網(wǎng)卡進行數(shù)據(jù)傳輸。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），Sendfile 系統(tǒng)調用執(zhí)行返回。

這樣就省去了內核空間中僅剩的 1 次 CPU 拷貝操作，Sendfile 的偽代碼如下：

sendfile(socket_fd, file_fd, len);

這樣 DMA 引擎直接利用 gather 操作將頁緩存中數(shù)據(jù)打包發(fā)送到網(wǎng)絡中即可，本質就是和虛擬內存映射的思路類似。

• 用戶進程通過 sendfile() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從主存或硬盤拷貝到內核空間（kernel space）的讀緩沖區(qū)（read buffer）。

• CPU 把讀緩沖區(qū)（read buffer）的文件描述符（file descriptor）和數(shù)據(jù)長度拷貝到網(wǎng)絡緩沖區(qū)（socket buffer）。

• 基于已拷貝的文件描述符（file descriptor）和數(shù)據(jù)長度，CPU 利用 DMA 控制器的 gather/scatter 操作直接批量地將數(shù)據(jù)從內核的讀緩沖區(qū)（read buffer）拷貝到網(wǎng)卡進行數(shù)據(jù)傳輸。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），Sendfile 系統(tǒng)調用執(zhí)行返回。

Splice 的偽代碼如下：

Splice 系統(tǒng)調用可以在內核空間的讀緩沖區(qū)（read buffer）和網(wǎng)絡緩沖區(qū)（socket buffer）之間建立管道（pipeline），從而避免了兩者之間的 CPU 拷貝操作。

• 用戶進程通過 splice() 函數(shù)向內核（kernel）發(fā)起系統(tǒng)調用，上下文從用戶態(tài)（user space）切換為內核態(tài)（kernel space）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從主存或硬盤拷貝到內核空間（kernel space）的讀緩沖區(qū)（read buffer）。

• CPU 在內核空間的讀緩沖區(qū)（read buffer）和網(wǎng)絡緩沖區(qū)（socket buffer）之間建立管道（pipeline）。

• CPU 利用 DMA 控制器將數(shù)據(jù)從網(wǎng)絡緩沖區(qū)（socket buffer）拷貝到網(wǎng)卡進行數(shù)據(jù)傳輸。

• 上下文從內核態(tài)（kernel space）切換回用戶態(tài)（user space），Splice 系統(tǒng)調用執(zhí)行返回。

fbuf 的思想是每個進程都維護著一個緩沖區(qū)池，這個緩沖區(qū)池能被同時映射到用戶空間（user space）和內核態(tài)（kernel space），內核和用戶共享這個緩沖區(qū)池，這樣就避免了一系列的拷貝操作。

下面從 CPU 拷貝次數(shù)、DMA 拷貝次數(shù)以及系統(tǒng)調用幾個方面總結一下上述幾種 I/O 拷貝方式的差別：

在 Java NIO 中的通道（Channel）就相當于操作系統(tǒng)的內核空間（kernel space）的緩沖區(qū)。

而緩沖區(qū)（Buffer）對應的相當于操作系統(tǒng)的用戶空間（user space）中的用戶緩沖區(qū)（user buffer）：

• 通道（Channel）是全雙工的（雙向傳輸），它既可能是讀緩沖區(qū)（read buffer），也可能是網(wǎng)絡緩沖區(qū)（socket buffer）。

• 緩沖區(qū)（Buffer）分為堆內存（HeapBuffer）和堆外內存（DirectBuffer），這是通過 malloc() 分配出來的用戶態(tài)內存。

抽象方法 map() 方法在 FileChannel 中的定義如下：

public abstract MappedByteBuffer map(MapMode mode, long position, long size)
        throws IOException;

Mode：限定內存映射區(qū)域（MappedByteBuffer）對內存映像文件的訪問模式，包括只可讀（READ_ONLY）、可讀可寫（READ_WRITE）和寫時拷貝（PRIVATE）三種模式。

Position：文件映射的起始地址，對應內存映射區(qū)域（MappedByteBuffer）的首地址。

Size：文件映射的字節(jié)長度，從 Position 往后的字節(jié)數(shù)，對應內存映射區(qū)域（MappedByteBuffer）的大小。

MappedByteBuffer 相比 ByteBuffer 新增了三個重要的方法：

• fore()：對于處于 READ_WRITE 模式下的緩沖區(qū)，把對緩沖區(qū)內容的修改強制刷新到本地文件。

• load()：將緩沖區(qū)的內容載入物理內存中，并返回這個緩沖區(qū)的引用。

• isLoaded()：如果緩沖區(qū)的內容在物理內存中，則返回 true，否則返回 false。

下面給出一個利用 MappedByteBuffer 對文件進行讀寫的使用示例：

@Test
public void writeToFileByMappedByteBuffer() {
    Path path = Paths.get(getClass().getResource(FILE_NAME).getPath());
    byte[] bytes = CONTENT.getBytes(Charset.forName(CHARSET));
    try (FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ,
            StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
        MappedByteBuffer mappedByteBuffer = fileChannel.map(READ_WRITE, 0, bytes.length);
        if (mappedByteBuffer != null) {
            mappedByteBuffer.put(bytes);
            mappedByteBuffer.force();
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

讀文件數(shù)據(jù)：打開文件通道 fileChannel 并提供只讀權限，通過 fileChannel 映射到一個只可讀的內存緩沖區(qū) mappedByteBuffer，讀取 mappedByteBuffer 中的字節(jié)數(shù)組即可得到文件數(shù)據(jù)。

下面介紹 map() 方法的底層實現(xiàn)原理。map() 方法是 java.nio.channels.FileChannel 的抽象方法，由子類 sun.nio.ch.FileChannelImpl.java 實現(xiàn)。

public MappedByteBuffer map(MapMode mode, long position, long size) throws IOException {
    int pagePosition = (int)(position % allocationGranularity);
    long mapPosition = position - pagePosition;
    long mapSize = size + pagePosition;
    try {
        addr = map0(imode, mapPosition, mapSize);
    } catch (OutOfMemoryError x) {
        System.gc();
        try {
            Thread.sleep(100);
        } catch (InterruptedException y) {
            Thread.currentThread().interrupt();
        }
        try {
            addr = map0(imode, mapPosition, mapSize);
        } catch (OutOfMemoryError y) {
            throw new IOException('Map failed', y);
        }
    }
    int isize = (int)size;
    Unmapper um = new Unmapper(addr, mapSize, isize, mfd);
    if ((!writable) || (imode == MAP_RO)) {
        return Util.newMappedByteBufferR(isize, addr + pagePosition, mfd, um);
    } else {
        return Util.newMappedByteBuffer(isize, addr + pagePosition, mfd, um);
    }
}

map() 方法通過本地方法 map0() 為文件分配一塊虛擬內存，作為它的內存映射區(qū)域，然后返回這塊內存映射區(qū)域的起始地址：

• 文件映射需要在 Java 堆中創(chuàng)建一個 MappedByteBuffer 的實例。如果第一次文件映射導致 OOM，則手動觸發(fā)垃圾回收，休眠 100ms 后再嘗試映射，如果失敗則拋出異常。

• 通過 Util 的 newMappedByteBuffer（可讀可寫）方法或者 newMappedByteBufferR（僅讀）方法反射創(chuàng)建一個 DirectByteBuffer 實例，其中 DirectByteBuffer 是 MappedByteBuffer 的子類。

這樣一定程度上替代了 read() 或 write() 方法，底層直接采用 sun.misc.Unsafe 類的 getByte() 和 putByte() 方法對數(shù)據(jù)進行讀寫。

這個 native 函數(shù)（Java_sun_nio_ch_FileChannelImpl_map0）的實現(xiàn)位于 JDK 源碼包下的 native/sun/nio/ch/FileChannelImpl.c 這個源文件里面。

JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
                                     jint prot, jlong off, jlong len)
{
    void *mapAddress = 0;
    jobject fdo = (*env)->GetObjectField(env, this, chan_fd);
    jint fd = fdval(env, fdo);
    int protections = 0;
    int flags = 0;
    if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) {
        protections = PROT_READ;
        flags = MAP_SHARED;
    } else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) {
        protections = PROT_WRITE | PROT_READ;
        flags = MAP_SHARED;
    } else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) {
        protections =  PROT_WRITE | PROT_READ;
        flags = MAP_PRIVATE;
    }
    mapAddress = mmap64(
        0,                    /* Let OS decide location */
        len,                  /* Number of bytes to map */
        protections,          /* File permissions */
        flags,                /* Changes are shared */
        fd,                   /* File descriptor of mapped file */
        off);                 /* Offset into file */
    if (mapAddress == MAP_FAILED) {
        if (errno == ENOMEM) {
            JNU_ThrowOutOfMemoryError(env, 'Map failed');
            return IOS_THROWN;
        }
        return handle(env, -1, 'Map failed');
    }
    return ((jlong) (unsigned long) mapAddress);
}

下面詳細介紹一下 mmap64() 函數(shù)各個參數(shù)的含義以及參數(shù)可選值：

addr：文件在用戶進程空間的內存映射區(qū)中的起始地址，是一個建議的參數(shù)，通常可設置為 0 或 NULL，此時由內核去決定真實的起始地址。

當 flags 為 MAP_FIXED 時，addr 就是一個必選的參數(shù)，即需要提供一個存在的地址。

len：文件需要進行內存映射的字節(jié)長度。

prot：控制用戶進程對內存映射區(qū)的訪問權限：

• PROT_READ：讀權限。

• PROT_WRITE：寫權限。

• PROT_EXEC：執(zhí)行權限。

• PROT_NONE：無權限。

flags：控制內存映射區(qū)的修改是否被多個進程共享：

• MAP_PRIVATE：對內存映射區(qū)數(shù)據(jù)的修改不會反映到真正的文件，數(shù)據(jù)修改發(fā)生時采用寫時復制機制。

• MAP_SHARED：對內存映射區(qū)的修改會同步到真正的文件，修改對共享此內存映射區(qū)的進程是可見的。

• MAP_FIXED：不建議使用，這種模式下 addr 參數(shù)指定的必須提供一個存在的 addr 參數(shù)。

fd：文件描述符。每次 map 操作會導致文件的引用計數(shù)加 1，每次 unmap 操作或者結束進程會導致引用計數(shù)減 1。

offset：文件偏移量。進行映射的文件位置，從文件起始地址向后的位移量。

下面總結一下 MappedByteBuffer 的特點和不足之處：

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

• 如果當文件超出 Integer.MAX_VALUE 字節(jié)限制時，可以通過 position 參數(shù)重新 map 文件后面的內容。

• MappedByteBuffer 在處理大文件時性能的確很高，但也存在內存占用、文件關閉不確定等問題，被其打開的文件只有在垃圾回收的才會被關閉，而且這個時間點是不確定的。

• MappedByteBuffer 提供了文件映射內存的 mmap() 方法，也提供了釋放映射內存的 unmap() 方法。然而 unmap() 是 FileChannelImpl 中的私有方法，無法直接顯示調用。

  因此，用戶程序需要通過 Java 反射的調用 sun.misc.Cleaner 類的 clean() 方法手動釋放映射占用的內存區(qū)域。

public static void clean(final Object buffer) throws Exception {
    AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
        try {
            Method getCleanerMethod = buffer.getClass().getMethod('cleaner', new Class[0]);
            getCleanerMethod.setAccessible(true);
            Cleaner cleaner = (Cleaner) getCleanerMethod.invoke(buffer, new Object[0]);
            cleaner.clean();
        } catch(Exception e) {
            e.printStackTrace();
        }
    });
}

DirectByteBuffer 的對象引用位于 Java 內存模型的堆里面，JVM 可以對 DirectByteBuffer 的對象進行內存分配和回收管理。

DirectByteBuffer 內部的字節(jié)緩沖區(qū)位在于堆外的（用戶態(tài)）直接內存，它是通過 Unsafe 的本地方法 allocateMemory() 進行內存分配，底層調用的是操作系統(tǒng)的 malloc() 函數(shù)。

DirectByteBuffer(int cap) {
    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 {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

由于使用 DirectByteBuffer 分配的是系統(tǒng)本地的內存，不在 JVM 的管控范圍之內，因此直接內存的回收和堆內存的回收不同，直接內存如果使用不當，很容易造成 OutOfMemoryError。

說了這么多，那么 DirectByteBuffer 和零拷貝有什么關系？前面有提到在 MappedByteBuffer 進行內存映射時，它的 map() 方法會通過 Util.newMappedByteBuffer() 來創(chuàng)建一個緩沖區(qū)實例。

static MappedByteBuffer newMappedByteBuffer(int size, long addr, FileDescriptor fd,
                                            Runnable unmapper) {
    MappedByteBuffer dbb;
    if (directByteBufferConstructor == null)
        initDBBConstructor();
    try {
        dbb = (MappedByteBuffer)directByteBufferConstructor.newInstance(
            new Object[] { new Integer(size), new Long(addr), fd, unmapper });
    } catch (InstantiationException | IllegalAccessException | InvocationTargetException e) {
        throw new InternalError(e);
    }
    return dbb;
}
private static void initDBBRConstructor() {
    AccessController.doPrivileged(new PrivilegedAction<Void>() {
        public Void run() {
            try {
                Class<?> cl = Class.forName('java.nio.DirectByteBufferR');
                Constructor<?> ctor = cl.getDeclaredConstructor(
                    new Class<?>[] { int.class, long.class, FileDescriptor.class,
                                    Runnable.class });
                ctor.setAccessible(true);
                directByteBufferRConstructor = ctor;
            } catch (ClassNotFoundException | NoSuchMethodException |
                     IllegalArgumentException | ClassCastException x) {
                throw new InternalError(x);
            }
            return null;
        }});
}

DirectByteBuffer 是 MappedByteBuffer 的具體實現(xiàn)類。

因此，除了允許分配操作系統(tǒng)的直接內存以外，DirectByteBuffer 本身也具有文件內存映射的功能，這里不做過多說明。

我們需要關注的是，DirectByteBuffer 在 MappedByteBuffer 的基礎上提供了內存映像文件的隨機讀取 get() 和寫入 write() 的操作。

public byte get() {
    return ((unsafe.getByte(ix(nextGetIndex()))));
}
public byte get(int i) {
    return ((unsafe.getByte(ix(checkIndex(i)))));
}

private long ix(int i) {
    return address + ((long)i << 0);
}

FileChannel 是一個用于文件讀寫、映射和操作的通道，同時它在并發(fā)環(huán)境下是線程安全的。

基于 FileInputStream、FileOutputStream 或者 RandomAccessFile 的 getChannel() 方法可以創(chuàng)建并打開一個文件通道。

FileChannel 定義了 transferFrom() 和 transferTo() 兩個抽象方法，它通過在通道和通道之間建立連接實現(xiàn)數(shù)據(jù)傳輸?shù)摹?/p>

transferTo()：通過 FileChannel 把文件里面的源數(shù)據(jù)寫入一個 WritableByteChannel 的目的通道。

public abstract long transferFrom(ReadableByteChannel src, long position, long count)
        throws IOException;

@Before
public void setup() {
    Path source = Paths.get(getClassPath(SOURCE_FILE));
    byte[] bytes = CONTENT.getBytes(Charset.forName(CHARSET));
    try (FileChannel fromChannel = FileChannel.open(source, StandardOpenOption.READ,
            StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
        fromChannel.write(ByteBuffer.wrap(bytes));
    } catch (IOException e) {
        e.printStackTrace();
    }
}

@Test
public void transferFrom() throws Exception {
    try (FileChannel fromChannel = new RandomAccessFile(
             getClassPath(SOURCE_FILE), 'rw').getChannel();
         FileChannel toChannel = new RandomAccessFile(
             getClassPath(TARGET_FILE), 'rw').getChannel()) {
        long position = 0L;
        long offset = fromChannel.size();
        toChannel.transferFrom(fromChannel, position, offset);
    }
}

public long transferTo(long position, long count, WritableByteChannel target)
        throws IOException {
    // 計算文件的大小
    long sz = size();
    // 校驗起始位置
    if (position > sz)
        return 0;
    int icount = (int)Math.min(count, Integer.MAX_VALUE);
    // 校驗偏移量
    if ((sz - position) < icount)
        icount = (int)(sz - position);
    long n;
    if ((n = transferToDirectly(position, icount, target)) >= 0)
        return n;
    if ((n = transferToTrustedChannel(position, icount, target)) >= 0)
        return n;
    return transferToArbitraryChannel(position, icount, target);
}

private long transferToDirectlyInternal(long position, int icount,
                                        WritableByteChannel target,
                                        FileDescriptor targetFD) throws IOException {
    assert !nd.transferToDirectlyNeedsPositionLock() ||
            Thread.holdsLock(positionLock);
    long n = -1;
    int ti = -1;
    try {
        begin();
        ti = threads.add();
        if (!isOpen())
            return -1;
        do {
            n = transferTo0(fd, position, icount, targetFD);
        } while ((n == IOStatus.INTERRUPTED) && isOpen());
        if (n == IOStatus.UNSUPPORTED_CASE) {
            if (target instanceof SinkChannelImpl)
                pipeSupported = false;
            if (target instanceof FileChannelImpl)
                fileSupported = false;
            return IOStatus.UNSUPPORTED_CASE;
        }
        if (n == IOStatus.UNSUPPORTED) {
            transferSupported = false;
            return IOStatus.UNSUPPORTED;
        }
        return IOStatus.normalize(n);
    } finally {
        threads.remove(ti);
        end (n > -1);
    }
}

#include <sys/sendfile.h>
ssize_t sendfile64(int out_fd, int in_fd, off_t *offset, size_t count);