九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

圖片來自 Pexels

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

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

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

• 零拷貝機(jī)制可以減少用戶進(jìn)程地址空間和內(nèi)核地址空間之間因?yàn)樯舷挛那袚Q而帶來的 CPU 開銷。

下面給出兩個(gè)進(jìn)程 A、B 各自的虛擬內(nèi)存空間以及對(duì)應(yīng)的物理內(nèi)存之間的地址映射示意圖：

• 用戶進(jìn)程向操作系統(tǒng)發(fā)出內(nèi)存申請(qǐng)請(qǐng)求。

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

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

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

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

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

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

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

• 進(jìn)程隔離：不同進(jìn)程的虛擬地址之間沒有關(guān)系，所以一個(gè)進(jìn)程的操作不會(huì)對(duì)其他進(jìn)程造成影響。

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

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

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

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

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

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

下圖是一個(gè)進(jìn)程的用戶空間和內(nèi)核空間的內(nèi)存布局：

• 進(jìn)程私有的虛擬內(nèi)存：每個(gè)進(jìn)程都有單獨(dú)的內(nèi)核棧、頁表、task 結(jié)構(gòu)以及 mem_map 結(jié)構(gòu)等。

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

• 運(yùn)行時(shí)棧：由編譯器自動(dòng)釋放，存放函數(shù)的參數(shù)值，局部變量和方法返回值等。每當(dāng)一個(gè)函數(shù)被調(diào)用時(shí)，該函數(shù)的返回類型和一些調(diào)用的信息被存儲(chǔ)到棧頂，調(diào)用結(jié)束后調(diào)用信息會(huì)被彈出并釋放掉內(nèi)存。

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

• 運(yùn)行時(shí)堆：用于存放進(jìn)程運(yùn)行中被動(dòng)態(tài)分配的內(nèi)存段，位于 BSS 和棧中間的地址位。由卡發(fā)人員申請(qǐng)分配（malloc）和釋放（free）。堆是從低地址位向高地址位增長(zhǎng)，采用鏈?zhǔn)酱鎯?chǔ)結(jié)構(gòu)。

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

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

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

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

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

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

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

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

• 用戶空間允許頁面中斷，而內(nèi)核空間則不允許。

• 內(nèi)核空間和用戶空間是針對(duì)線性地址空間的。

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

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

• 所有內(nèi)核進(jìn)程（線程）共用一個(gè)地址空間，而用戶進(jìn)程都有各自的地址空間。

有了用戶空間和內(nèi)核空間的劃分后，Linux 內(nèi)部層級(jí)結(jié)構(gòu)可以分為三部分，從最底層到最上層依次是硬件、內(nèi)核空間和用戶空間，如下圖所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

偽代碼如下：

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

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

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

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

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

read(file_fd, tmp_buf, len);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sendfile(socket_fd, file_fd, len);

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

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

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

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

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

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

Splice 的偽代碼如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Position：文件映射的起始地址，對(duì)應(yīng)內(nèi)存映射區(qū)域（MappedByteBuffer）的首地址。

Size：文件映射的字節(jié)長(zhǎng)度，從 Position 往后的字節(jié)數(shù)，對(duì)應(yīng)內(nèi)存映射區(qū)域（MappedByteBuffer）的大小。

MappedByteBuffer 相比 ByteBuffer 新增了三個(gè)重要的方法：

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

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

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

下面給出一個(gè)利用 MappedByteBuffer 對(duì)文件進(jìn)行讀寫的使用示例：

@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 并提供只讀權(quán)限，通過 fileChannel 映射到一個(gè)只可讀的內(nèi)存緩沖區(qū) mappedByteBuffer，讀取 mappedByteBuffer 中的字節(jié)數(shù)組即可得到文件數(shù)據(jù)。

下面介紹 map() 方法的底層實(shí)現(xiàn)原理。map() 方法是 java.nio.channels.FileChannel 的抽象方法，由子類 sun.nio.ch.FileChannelImpl.java 實(shí)現(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() 為文件分配一塊虛擬內(nèi)存，作為它的內(nèi)存映射區(qū)域，然后返回這塊內(nèi)存映射區(qū)域的起始地址：

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

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

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

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

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);
}

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

addr：文件在用戶進(jìn)程空間的內(nèi)存映射區(qū)中的起始地址，是一個(gè)建議的參數(shù)，通?？稍O(shè)置為 0 或 NULL，此時(shí)由內(nèi)核去決定真實(shí)的起始地址。

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

len：文件需要進(jìn)行內(nèi)存映射的字節(jié)長(zhǎng)度。

prot：控制用戶進(jìn)程對(duì)內(nèi)存映射區(qū)的訪問權(quán)限：

• PROT_READ：讀權(quán)限。

• PROT_WRITE：寫權(quán)限。

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

• PROT_NONE：無權(quán)限。

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

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

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

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

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

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

下面總結(jié)一下 MappedByteBuffer 的特點(diǎn)和不足之處：

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

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

• MappedByteBuffer 在處理大文件時(shí)性能的確很高，但也存在內(nèi)存占用、文件關(guān)閉不確定等問題，被其打開的文件只有在垃圾回收的才會(huì)被關(guān)閉，而且這個(gè)時(shí)間點(diǎn)是不確定的。

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

  因此，用戶程序需要通過 Java 反射的調(diào)用 sun.misc.Cleaner 類的 clean() 方法手動(dòng)釋放映射占用的內(nèi)存區(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 的對(duì)象引用位于 Java 內(nèi)存模型的堆里面，JVM 可以對(duì) DirectByteBuffer 的對(duì)象進(jìn)行內(nèi)存分配和回收管理。

DirectByteBuffer 內(nèi)部的字節(jié)緩沖區(qū)位在于堆外的（用戶態(tài)）直接內(nèi)存，它是通過 Unsafe 的本地方法 allocateMemory() 進(jìn)行內(nèi)存分配，底層調(diào)用的是操作系統(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)本地的內(nèi)存，不在 JVM 的管控范圍之內(nèi)，因此直接內(nèi)存的回收和堆內(nèi)存的回收不同，直接內(nèi)存如果使用不當(dāng)，很容易造成 OutOfMemoryError。

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

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 的具體實(shí)現(xiàn)類。

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

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

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

內(nèi)存映像文件的隨機(jī)讀寫都是借助 ix() 方法實(shí)現(xiàn)定位的， ix() 方法通過內(nèi)存映射空間的內(nèi)存首地址（address）和給定偏移量 i 計(jì)算出指針地址，然后由 unsafe 類的 get() 和 put() 方法和對(duì)指針指向的數(shù)據(jù)進(jìn)行讀取或?qū)懭搿?/section>

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

FileChannel

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

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

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

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

public abstract long transferTo(long position, long count, WritableByteChannel target)
        throws IOException;


transferFrom()：把一個(gè)源通道 ReadableByteChannel 中的數(shù)據(jù)讀取到當(dāng)前 FileChannel 的文件里面。

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

下面給出 FileChannel 利用 transferTo() 和 transferFrom() 方法進(jìn)行數(shù)據(jù)傳輸?shù)氖褂檬纠?/section>

private static final String CONTENT = 'Zero copy implemented by FileChannel';
private static final String SOURCE_FILE = '/source.txt';
private static final String TARGET_FILE = '/target.txt';
private static final String CHARSET = 'UTF-8';


首先在類加載根路徑下創(chuàng)建 source.txt 和 target.txt 兩個(gè)文件，對(duì)源文件 source.txt 文件寫入初始化數(shù)據(jù)。

@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();
    }
}

對(duì)于 transferTo() 方法而言，目的通道 toChannel 可以是任意的單向字節(jié)寫通道 WritableByteChannel；而對(duì)于 transferFrom() 方法而言，源通道 fromChannel 可以是任意的單向字節(jié)讀通道 ReadableByteChannel。

其中，F(xiàn)ileChannel、SocketChannel 和 DatagramChannel 等通道實(shí)現(xiàn)了 WritableByteChannel 和 ReadableByteChannel 接口，都是同時(shí)支持讀寫的雙向通道。

為了方便測(cè)試，下面給出基于 FileChannel 完成 channel-to-channel 的數(shù)據(jù)傳輸示例。

通過 transferTo() 將 fromChannel 中的數(shù)據(jù)拷貝到 toChannel：

@Test
public void transferTo() 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();
        fromChannel.transferTo(position, offset, toChannel);
    }
}


通過 transferFrom() 將 fromChannel 中的數(shù)據(jù)拷貝到 toChannel：

@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);
    }
}

下面介紹 transferTo() 和 transferFrom() 方法的底層實(shí)現(xiàn)原理，這兩個(gè)方法也是 java.nio.channels.FileChannel 的抽象方法，由子類 sun.nio.ch.FileChannelImpl.java 實(shí)現(xiàn)。

transferTo() 和 transferFrom() 底層都是基于 Sendfile 實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)?，其?FileChannelImpl.java 定義了 3 個(gè)常量，用于標(biāo)示當(dāng)前操作系統(tǒng)的內(nèi)核是否支持 Sendfile 以及 Sendfile 的相關(guān)特性。

private static volatile boolean transferSupported = true;
private static volatile boolean pipeSupported = true;
private static volatile boolean fileSupported = true;


transferSupported：用于標(biāo)記當(dāng)前的系統(tǒng)內(nèi)核是否支持 sendfile() 調(diào)用，默認(rèn)為 true。

pipeSupported：用于標(biāo)記當(dāng)前的系統(tǒng)內(nèi)核是否支持文件描述符（fd）基于管道（pipe）的 sendfile() 調(diào)用，默認(rèn)為 true。

fileSupported：用于標(biāo)記當(dāng)前的系統(tǒng)內(nèi)核是否支持文件描述符（fd）基于文件（file）的 sendfile() 調(diào)用，默認(rèn)為 true。

下面以 transferTo() 的源碼實(shí)現(xiàn)為例。FileChannelImpl 首先執(zhí)行 transferToDirectly() 方法，以 Sendfile 的零拷貝方式嘗試數(shù)據(jù)拷貝。

如果系統(tǒng)內(nèi)核不支持 Sendfile，進(jìn)一步執(zhí)行 transferToTrustedChannel() 方法，以 mmap 的零拷貝方式進(jìn)行內(nèi)存映射，這種情況下目的通道必須是 FileChannelImpl 或者 SelChImpl 類型。

如果以上兩步都失敗了，則執(zhí)行 transferToArbitraryChannel() 方法，基于傳統(tǒng)的 I/O 方式完成讀寫，具體步驟是初始化一個(gè)臨時(shí)的 DirectBuffer，將源通道 FileChannel 的數(shù)據(jù)讀取到 DirectBuffer，再寫入目的通道 WritableByteChannel 里面。

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

接下來重點(diǎn)分析一下 transferToDirectly() 方法的實(shí)現(xiàn)，也就是 transferTo() 通過 Sendfile 實(shí)現(xiàn)零拷貝的精髓所在。

可以看到，transferToDirectlyInternal() 方法先獲取到目的通道 WritableByteChannel 的文件描述符 targetFD，獲取同步鎖然后執(zhí)行 transferToDirectlyInternal() 方法。

private long transferToDirectly(long position, int icount, WritableByteChannel target)
        throws IOException {
    // 省略從target獲取targetFD的過程
    if (nd.transferToDirectlyNeedsPositionLock()) {
        synchronized (positionLock) {
            long pos = position();
            try {
                return transferToDirectlyInternal(position, icount,
                        target, targetFD);
            } finally {
                position(pos);
            }
        }
    } else {
        return transferToDirectlyInternal(position, icount, target, targetFD);
    }
}


最終由 transferToDirectlyInternal() 調(diào)用本地方法 transferTo0() ，嘗試以 Sendfile 的方式進(jìn)行數(shù)據(jù)傳輸。

如果系統(tǒng)內(nèi)核完全不支持 Sendfile，比如 Windows 操作系統(tǒng)，則返回 UNSUPPORTED 并把 transferSupported 標(biāo)識(shí)為 false。

如果系統(tǒng)內(nèi)核不支持 Sendfile 的一些特性，比如說低版本的 Linux 內(nèi)核不支持 DMA gather copy 操作，則返回 UNSUPPORTED_CASE 并把 pipeSupported 或者 fileSupported 標(biāo)識(shí)為 false。

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);
    }
}

本地方法（native method）transferTo0() 通過 JNI（Java Native Interface）調(diào)用底層 C 的函數(shù)。

這個(gè) native 函數(shù)（Java_sun_nio_ch_FileChannelImpl_transferTo0）同樣位于 JDK 源碼包下的 native/sun/nio/ch/FileChannelImpl.c 源文件里面。

JNI 函數(shù) Java_sun_nio_ch_FileChannelImpl_transferTo0() 基于條件編譯對(duì)不同的系統(tǒng)進(jìn)行預(yù)編譯，下面是 JDK 基于 Linux 系統(tǒng)內(nèi)核對(duì) transferTo() 提供的調(diào)用封裝。

#if defined(__linux__) || defined(__solaris__)
#include <sys/sendfile.h>
#elif defined(_AIX)
#include <sys/socket.h>
#elif defined(_ALLBSD_SOURCE)
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/uio.h>
#define lseek64 lseek
#define mmap64 mmap
#endif
JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_transferTo0(JNIEnv *env, jobject this,
                                            jobject srcFDO,
                                            jlong position, jlong count,
                                            jobject dstFDO)
{
    jint srcFD = fdval(env, srcFDO);
    jint dstFD = fdval(env, dstFDO);
#if defined(__linux__)
    off64_t offset = (off64_t)position;
    jlong n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
    return n;
#elif defined(__solaris__)
    result = sendfilev64(dstFD, &sfv, 1, &numBytes);    
    return result;
#elif defined(__APPLE__)
    result = sendfile(srcFD, dstFD, position, &numBytes, NULL, 0);
    return result;
#endif
}


對(duì) Linux、Solaris 以及 Apple 系統(tǒng)而言，transferTo0() 函數(shù)底層會(huì)執(zhí)行 sendfile64 這個(gè)系統(tǒng)調(diào)用完成零拷貝操作，sendfile64() 函數(shù)的原型如下：

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

下面簡(jiǎn)單介紹一下 sendfile64() 函數(shù)各個(gè)參數(shù)的含義：

• out_fd：待寫入的文件描述符。

• in_fd：待讀取的文件描述符。

• offset：指定 in_fd 對(duì)應(yīng)文件流的讀取位置，如果為空，則默認(rèn)從起始位置開始。

• count：指定在文件描述符 in_fd 和 out_fd 之間傳輸?shù)淖止?jié)數(shù)。

在 Linux 2.6.3 之前，out_fd 必須是一個(gè) socket，而從 Linux 2.6.3 以后，out_fd 可以是任何文件。

也就是說，sendfile64() 函數(shù)不僅可以進(jìn)行網(wǎng)絡(luò)文件傳輸，還可以對(duì)本地文件實(shí)現(xiàn)零拷貝操作。

其它的零拷貝實(shí)現(xiàn)

Netty 零拷貝

Netty 中的零拷貝和上面提到的操作系統(tǒng)層面上的零拷貝不太一樣, 我們所說的 Netty 零拷貝完全是基于（Java 層面）用戶態(tài)的，它的更多的是偏向于數(shù)據(jù)操作優(yōu)化這樣的概念。

具體表現(xiàn)在以下幾個(gè)方面：

• Netty 通過 DefaultFileRegion 類對(duì) java.nio.channels.FileChannel 的 tranferTo() 方法進(jìn)行包裝，在文件傳輸時(shí)可以將文件緩沖區(qū)的數(shù)據(jù)直接發(fā)送到目的通道（Channel）。

• ByteBuf 可以通過 wrap 操作把字節(jié)數(shù)組、ByteBuf、ByteBuffer 包裝成一個(gè) ByteBuf 對(duì)象, 進(jìn)而避免了拷貝操作。

• ByteBuf 支持 Slice 操作, 因此可以將 ByteBuf 分解為多個(gè)共享同一個(gè)存儲(chǔ)區(qū)域的 ByteBuf，避免了內(nèi)存的拷貝。

• Netty 提供了 CompositeByteBuf 類，它可以將多個(gè) ByteBuf 合并為一個(gè)邏輯上的 ByteBuf，避免了各個(gè) ByteBuf 之間的拷貝。

其中第 1 條屬于操作系統(tǒng)層面的零拷貝操作，后面 3 條只能算用戶層面的數(shù)據(jù)操作優(yōu)化。

RocketMQ 和 Kafka 對(duì)比

RocketMQ 選擇了 mmap+write 這種零拷貝方式，適用于業(yè)務(wù)級(jí)消息這種小塊文件的數(shù)據(jù)持久化和傳輸。

而 Kafka 采用的是 Sendfile 這種零拷貝方式，適用于系統(tǒng)日志消息這種高吞吐量的大塊文件的數(shù)據(jù)持久化和傳輸。

但是值得注意的一點(diǎn)是，Kafka 的索引文件使用的是 mmap+write 方式，數(shù)據(jù)文件使用的是 Sendfile 方式。

總結(jié)

本文開篇詳述了 Linux 操作系統(tǒng)中的物理內(nèi)存和虛擬內(nèi)存，內(nèi)核空間和用戶空間的概念以及 Linux 內(nèi)部的層級(jí)結(jié)構(gòu)。

在此基礎(chǔ)上，進(jìn)一步分析和對(duì)比傳統(tǒng) I/O 方式和零拷貝方式的區(qū)別，然后介紹了 Linux 內(nèi)核提供的幾種零拷貝實(shí)現(xiàn)。

包括內(nèi)存映射 mmap、Sendfile、Sendfile+DMA gather copy 以及 Splice 幾種機(jī)制，并從系統(tǒng)調(diào)用和拷貝次數(shù)層面對(duì)它們進(jìn)行了對(duì)比。

接下來從源碼著手分析了 Java NIO 對(duì)零拷貝的實(shí)現(xiàn)，主要包括基于內(nèi)存映射（mmap）方式的 MappedByteBuffer 以及基于 Sendfile 方式的 FileChannel。

最后在篇末簡(jiǎn)單的闡述了一下 Netty 中的零拷貝機(jī)制，以及 RocketMQ 和 Kafka 兩種消息隊(duì)列在零拷貝實(shí)現(xiàn)方式上的區(qū)別。

作者：陳林