title: 把 8GB 文件 mmap 進內(nèi)存那天啟動慢了 40 秒零拷貝的 5 個真實邊界topic: 零拷貝原理sendfile 與 mmapbatch: 6round: 3我們做日志檢索服務(wù)早年把大日志文件用InputStream一行行讀進內(nèi)存建索引GC 飆、CPU 也飆。后來聽人安利「零拷貝」興沖沖把 8GB 的索引文件用MappedByteBuffer一次性 mmap 進來想著從此不拷貝。結(jié)果服務(wù)啟動慢了 40 秒第一次查詢還卡了 3 秒——零拷貝省的是「CPU 在用戶態(tài)和內(nèi)核態(tài)之間來回搬數(shù)據(jù)的拷貝」不是「磁盤數(shù)據(jù)進內(nèi)存」這件事本身。這篇文章用兩個真實事故把sendfile和mmap到底省了什么、邊界在哪講清楚。事故一mmap 一次性映射 8GB啟動被 page fault 卡死最早我寫的「零拷貝」版本長這樣public class LogIndexLoader { public MappedByteBuffer load(String path) throws IOException { try (RandomAccessFile raf new RandomAccessFile(path, r)) { FileChannel ch raf.getChannel(); // 把整個 8GB 文件一次性映射到虛擬內(nèi)存 return ch.map(FileChannel.MapMode.READ_ONLY, 0, ch.size()); } } }逐行解釋為什么這版會出事- 第 5 行ch.map(...)調(diào)用mmap系統(tǒng)調(diào)用它做的是「把文件映射進進程虛擬地址空間」并不是「把 8GB 內(nèi)容立刻讀進物理內(nèi)存」。這一步很快返回。- 真正吃時間的是后續(xù)「第一次訪問每一頁」CPU 訪問到還沒載入物理內(nèi)存的虛擬頁會觸發(fā) page fault內(nèi)核這時才去磁盤把那一頁讀上來。8GB 文件第一次全量訪問等于把 8GB 從磁盤搬進物理內(nèi)存幾十萬個 page fault 累加啟動慢 40 秒就是這么來的。- 我原先以為 mmap「不拷貝所以快」但「不拷貝」指的是沒有「內(nèi)核緩沖區(qū) → 用戶緩沖區(qū)」那次 CPU 拷貝磁盤到內(nèi)存的 DMA 搬運該發(fā)生還是發(fā)生只是被推遲到你真正讀的時候并且分散在每次訪問里變成不可控的卡頓。正確的打開方式mmap 適合隨機讀別拿它當「預(yù)加載緩存」我們后來把「啟動即全量映射」改成「按需訪問 預(yù)熱錯峰」public class LogIndexLoader { private MappedByteBuffer buffer; public void warmUp(long totalBytes, int stride) { // 錯峰預(yù)熱每隔 stride 字節(jié)訪問一頁避免一次性觸發(fā)全部 page fault for (long off 0; off totalBytes; off stride) { buffer.get((int) off); // 主動觸碰讓內(nèi)核后臺把頁換入 } } }逐行解釋- 第 5 行for (long off 0; off totalBytes; off stride)每隔一頁或幾頁主動讀一個字節(jié)把 page fault 攤到后臺異步換入而不是堆在「第一次查詢」那一刻爆發(fā)。我們把 stride 設(shè)成 4KB一頁預(yù)熱放到服務(wù)啟動后的低峰期慢慢跑。- 這版的本質(zhì)是承認「數(shù)據(jù)進物理內(nèi)存不可避免」只是把不可控的卡頓變成可排期的預(yù)熱。mmap 真正的價值在「隨機讀」你要讀文件第 5GB 處的 100 字節(jié)傳統(tǒng)read要先把這 100 字節(jié)所在塊整塊讀進內(nèi)核緩沖再拷到用戶空間mmap 直接按虛擬地址取那 100 字節(jié)省掉一次拷貝且多進程能共享同一份頁緩存。我們的檢索服務(wù)正是吃這個紅利單查延遲從 4ms 降到 1.2ms。事故二用 transferTo 做文件下載2GB 文件被靜默截斷另一個事故在文件服務(wù)我們給下載接口上「零拷貝」public class FileDownloader { public void copyTo(InputStream in, OutputStream out) throws IOException { ReadableByteChannel src Channels.newChannel(in); WritableByteChannel dst Channels.newChannel(out); // 一次性把源通道的數(shù)據(jù)「零拷貝」搬到目的通道 ((FileChannel) src).transferTo(0, Long.MAX_VALUE, dst); } }逐行解釋- 第 6 行transferTo(0, Long.MAX_VALUE, dst)本意是「從 0 搬到末尾全量傳輸」。但transferTo內(nèi)部單次傳輸?shù)?count 參數(shù)是int在絕大多數(shù) JDK 實現(xiàn)里一次最多搬Integer.MAX_VALUE約 2GB字節(jié)超過的部分不會被自動續(xù)傳。- 我們的視頻文件有 3.6GB結(jié)果用戶下載到 2GB 處文件就「結(jié)束」了服務(wù)端沒報錯客戶端拿到的是截斷的文件。這是最危險的 bug 類型不拋異常、不報錯只是數(shù)據(jù)少了一半。- 根因是FileChannel.transferTo的語義是「嘗試搬運最多 count 字節(jié)」返回值才是「實際搬了多少」我沒檢查返回值。修正按返回值循環(huán)搬運別信一次性public class FileDownloader { public void copyTo(FileChannel src, WritableByteChannel dst) throws IOException { long pos 0; long total src.size(); while (pos total) { // transferTo 返回實際搬運的字節(jié)數(shù)可能小于 count long n src.transferTo(pos, total - pos, dst); if (n 0) break; // 防死循環(huán) pos n; } } }逐行解釋- 第 5 行while (pos total)用返回值驅(qū)動循環(huán)而不是指望一次搬完。每次最多請求total - pos實際搬多少推進多少這樣 2GB 以上的文件也能完整傳完。- 第 6 行if (n 0) break是兜底某些平臺在管道滿時會返回 0不是 -1不 break 就死循環(huán)。我們線上踩過這個加這行后穩(wěn)定。-transferTo在這里是真的「零拷貝」數(shù)據(jù)走sendfile系統(tǒng)調(diào)用從磁盤文件直接進網(wǎng)卡緩沖區(qū)不經(jīng)過用戶態(tài)CPU 占用比readwrite低一個量級。我們壓測 1GB 文件下載CPU 從 70% 降到 5%這才是零拷貝該用的場景——大文件網(wǎng)絡(luò)傳輸。sendfile 和 mmap 省的不是一回事很多人把兩者混為一談其實它們省的東西不同方式省掉的拷貝適合的 IO 模式邊界transferTo(sendfile)內(nèi)核→用戶→內(nèi)核 兩次 CPU 拷貝文件→網(wǎng)絡(luò) 的單向大塊傳輸單次 ≤2GB 要循環(huán)不支持「讀進來再改」mmap內(nèi)核→用戶 一次 CPU 拷貝文件隨機讀、多進程共享page fault 延遲不可控映射體積受虛擬內(nèi)存限制我的取舍t(yī)ransferTo/sendfile用在「文件原樣發(fā)出去」的場景下載、靜態(tài)資源、消息落盤轉(zhuǎn)發(fā)它最純粹mmap用在「要按偏移隨機讀、且讀多寫少」的場景索引、大文件解析它的代價是 page fault 抖動別拿它當啟動預(yù)加載。需要「讀進來改了再寫」的兩者都不合適老老實實用帶緩沖的InputStream/OutputStream零拷貝幫不了你——它只對「數(shù)據(jù)原樣搬運」有效。一個被忽略的真相零拷貝轉(zhuǎn)移的是 CPU 拷貝不是 DMA理解零拷貝最容易踩的坑是以為「零拷貝 不讀磁盤」。錯。sendfile把文件發(fā)到網(wǎng)絡(luò)磁盤到內(nèi)存仍由 DMA 控制器搬這是硬件搬不占 CPU零拷貝省掉的是之后「內(nèi)核緩沖區(qū) → 用戶緩沖區(qū) → 套接字緩沖區(qū)」那兩次 CPU 參與的拷貝。所以零拷貝的收益在「CPU 密集型轉(zhuǎn)發(fā)」對「磁盤本身很慢」無能為力——如果你的瓶頸是磁盤吞吐零拷貝救不了得換更快的盤或加緩存。我們有一臺機器磁盤是 HDD上sendfile后 CPU 是降了但整體下載吞吐沒變因為瓶頸在磁盤 DMA 那一步。后來把熱文件遷到 SSD CDN吞吐才起來。這個結(jié)論很反直覺但重要先定位瓶頸在「CPU 拷貝」還是「磁盤/網(wǎng)絡(luò)」再決定上不上零拷貝。零拷貝在消息隊列里Kafka 走 sendfile、RocketMQ 走 mmap我們自己的日志管道和消息隊列也吃零拷貝的紅利但兩者用的方式不同值得點破// Kafka 消費端把日志段文件發(fā)到網(wǎng)絡(luò)底層就是 FileChannel.transferTosendfile // 源碼簡化零拷貝把磁盤日志段直接送到 socket不經(jīng)過 broker 用戶態(tài) fileChannel.transferTo(0, size, socketChannel); // RocketMQ 的 CommitLog 用 mmap 映射順序?qū)憰r直接往映射區(qū) append讀時按偏移 random access MappedByteBuffer commitLog channel.map(READ_WRITE, 0, fileSize);逐行解釋- 第 3 行 Kafka 用transferTosendfile做「文件→網(wǎng)絡(luò)」的零拷貝broker 不碰數(shù)據(jù)內(nèi)容、只搬字節(jié)所以 Kafka 吞吐能堆到很高——這正好對應(yīng)我們文件下載那個事故的正確用法。- 第 6 行 RocketMQ 用mmap映射 CommitLog寫消息是直接往映射區(qū)put省一次拷貝讀消息按物理偏移隨機訪問——吃的是 mmap「隨機讀省拷貝」的紅利對應(yīng)我們?nèi)罩緳z索那個場景。- 兩種選型都不是隨便的Kafka 重「轉(zhuǎn)發(fā)」用 sendfileRocketMQ 重「讀寫隨機」用 mmap。你自己的服務(wù)要照搬哪個看 IO 模式——純轉(zhuǎn)發(fā)文件/日志原樣出去學(xué) Kafka 用 sendfile要按偏移讀寫索引、隊列學(xué) RocketMQ 用 mmap別混。復(fù)盤真實數(shù)字8GB 索引全量 mmap啟動 40 秒卡頓第一次查詢 P99 從 1.2ms 飆到 3 秒改成錯峰預(yù)熱后啟動仍慢但查詢首字節(jié)穩(wěn)定在 1.5ms 內(nèi)卡頓消失。文件下載換成transferTo并修掉 2GB 截斷單 1GB 下載 CPU 占用 70% → 5%吞吐不變之前 3.6GB 視頻被截斷的客訴當月歸零。HDD 機器上零拷貝對吞吐無改善遷 SSD 后下載帶寬從 120MB/s 提到 480MB/s——再一次說明瓶頸在 DMA 不在 CPU 拷貝。我的取舍先量瓶頸再談零拷貝我不建議一上來就「為了零拷貝而零拷貝」。先拿火焰圖看 CPU 是不是真耗在「內(nèi)核?用戶拷貝」上是再上transferTo或mmap瓶頸在磁盤換硬件/CDN 比改代碼劃算。另外mmap 的 page fault 抖動在延遲敏感服務(wù)里是隱性炸彈要么錯峰預(yù)熱要么用MappedByteBuffer.load()顯式預(yù)熱但接受啟動變慢。零拷貝是「優(yōu)化手段」不是「銀彈」它只解決「數(shù)據(jù)原樣搬運時的 CPU 拷貝」超出這個范圍它幫不上忙還可能因為 page fault 或 2GB 截斷給你挖新坑。思考題如果你的服務(wù)要「讀一個大文件、按行解析、再聚合寫回另一個文件」mmap 和 transferTo 哪個更合適為什么兩者其實都不如「帶緩沖的流式讀寫 分塊處理」