去年雙十一前夜我們一個(gè)負(fù)責(zé)落訂單流水order trail的服務(wù)在中午 12 點(diǎn)整突然整個(gè)進(jìn)程消失K8s 把它重啟了 3 次才勉強(qiáng)起來。事故復(fù)盤時(shí)看 dmesg只有一行java[18234]: segfault at 7f... ip ... signal SIGBUS。那天沒有人改業(yè)務(wù)代碼唯一的變更是運(yùn)維把訂單流水文件的 logrotate 策略從按大小滾動(dòng)改成了按天 0 點(diǎn)截?cái)嘀亟?。問題mmap 為什么會(huì) SIGBUS我們?yōu)榱税衙棵?4 萬條流水寫入 實(shí)時(shí)被多個(gè)消費(fèi)者讀取的延遲壓下來用了內(nèi)存映射文件MappedByteBuffer來做零拷貝讀寫。寫進(jìn)程 mmap 了文件 A讀進(jìn)程也 mmap 了同一個(gè)文件 A。0 點(diǎn) logrotate 把文件 A rename 成 A.1再新建一個(gè)空的 A。問題來了讀進(jìn)程手里還拿著舊文件 A 的映射而舊 inode 在 rename 后被截?cái)嗟?0 字節(jié)映射頁(yè)對(duì)應(yīng)的磁盤塊被回收。讀進(jìn)程訪問那塊內(nèi)存時(shí)MMU 發(fā)現(xiàn)頁(yè)已無后端存儲(chǔ)直接拋 SIGBUSJVM 來不及 catch進(jìn)程當(dāng)場(chǎng)崩。這不是 Java 的 bug是所有用 mmap 的語(yǔ)言的通病——映射關(guān)系把虛擬內(nèi)存頁(yè)和具體磁盤塊綁死了一旦底層文件被截?cái)嗷蛑亟?yè)的后端沒了訪問即崩。我們當(dāng)時(shí)第一反應(yīng)是是不是硬盤壞了查了一整圈才發(fā)現(xiàn)是 logrotate 的鍋因?yàn)榻財(cái)嗖僮鲗?duì)內(nèi)核來說是文件變短了而映射頁(yè)還指著被回收的塊。原理三種零拷貝路徑的區(qū)別零拷貝的零指的是CPU 不參與數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間的來回拷貝不是零次磁盤 IO。Linux 上常見三條零拷貝路徑sendfile內(nèi)核把文件頁(yè)緩存直接 DMA 到 socket不經(jīng)過用戶態(tài)適合文件 → 網(wǎng)絡(luò)。mmap write把文件映射進(jìn)用戶態(tài)地址空間write 時(shí)內(nèi)核再拷到 socket少了一次 read 拷貝但多了頁(yè)表維護(hù)成本。copy_file_range內(nèi)核內(nèi)部直接搬連 socket 都不碰適合文件 → 文件。mmap 的代價(jià)恰恰是它的優(yōu)勢(shì)反面它讓文件內(nèi)容看起來就像內(nèi)存于是你很容易忘記這塊內(nèi)存背后站著個(gè)隨時(shí)會(huì)變 inode 的文件。這也是為什么 Nginx、Kafka 這類基礎(chǔ)設(shè)施寧可自己用 sendfile也不輕易對(duì)用戶可控的文件做 mmap 直讀。實(shí)戰(zhàn)一出事故的映射讀取器下面是我們最初高性能讀取器的寫法雷就藏在第 6 行// OrderTrailReader.java —— 已出事故的版本 public class OrderTrailReader { public ByteBuffer open(String path) throws IOException { FileChannel ch FileChannel.open(Paths.get(path), StandardOpenOption.READ); // 1. 把整個(gè)文件映射到虛擬內(nèi)存避免每次 read 都走系統(tǒng)調(diào)用 MappedByteBuffer buf ch.map(FileChannel.MapMode.READ_ONLY, 0, ch.size()); // 2. 直接把 buf 交給下游解析下游會(huì)按需訪問其中任意偏移 return buf; // 3. 隱患ch 和 buf 生命周期脫離文件隨時(shí)可能被外部截?cái)?} }逐行看第 4 行打開只讀通道第 6 行ch.map(...)建立映射返回的MappedByteBuffer不歸 GC 管它背后是內(nèi)核頁(yè)第 9 行直接把 buf 交出去但此時(shí)ch可能已經(jīng)被關(guān)閉而 buf 仍引用一個(gè)隨時(shí)會(huì)變 inode 的文件。logrotate 一 rename truncate第 9 行返回的 buf 在訪問時(shí)就 SIGBUS。實(shí)戰(zhàn)二修正版——讀到的內(nèi)容先拷進(jìn)堆內(nèi)核心思路是別讓映射頁(yè)裸奔要么用 sendfile 這類不映射的方案要么在讀取路徑上加兜底拷貝斷開與文件的映射關(guān)系// OrderTrailReader.java —— 修正版讀到的內(nèi)容先拷進(jìn)堆內(nèi)斷開與文件的映射關(guān)系 public class OrderTrailReader { private static final int SAFE_CHUNK 8 * 1024; public byte[] readSafe(String path) throws IOException { try (FileChannel ch FileChannel.open(Paths.get(path), StandardOpenOption.READ)) { long size ch.size(); // 1. 仍用 mmap 享受零拷貝讀但只作臨時(shí)窗口 MappedByteBuffer mapped ch.map(FileChannel.MapMode.READ_ONLY, 0, Math.min(size, Integer.MAX_VALUE)); // 2. 立刻把需要的數(shù)據(jù)復(fù)制到堆內(nèi)字節(jié)數(shù)組之后不再碰 mapped byte[] copy new byte[(int) Math.min(size, Integer.MAX_VALUE)]; mapped.get(copy); // 3. 這一刻的拷貝是一次性代價(jià)換來后續(xù)訪問安全 return copy; // 4. 返回堆內(nèi)副本文件即便被截?cái)嘁膊挥绊懻{(diào)用方 } catch (IOException e) { // 5. truncate 導(dǎo)致的讀異常在這里被 catchJVM 不會(huì) SIGBUS 退出 throw new OrderTrailException(映射讀取失敗文件可能已被外部截?cái)? e); } } }逐行看第 8 行用 try-with-resources 確保通道關(guān)閉第 11 行 mmap 只作為臨時(shí)窗口第 13-14 行通過mapped.get(copy)把數(shù)據(jù)一次性搬進(jìn)堆內(nèi)這一步之后業(yè)務(wù)側(cè)拿到的copy和磁盤文件徹底解綁第 17 行即使文件被截?cái)鄴伋龅氖鞘軝z的IOException進(jìn)程安穩(wěn)。代價(jià)是多一次內(nèi)存拷貝——對(duì)秒級(jí)延遲要求、非超大文件的場(chǎng)景這點(diǎn)拷貝成本可以忽略。實(shí)戰(zhàn)三文件→網(wǎng)絡(luò)場(chǎng)景直接用 transferTo如果是文件 → 網(wǎng)絡(luò)的下載 / 轉(zhuǎn)發(fā)場(chǎng)景更該直接用 sendfile根本不進(jìn)用戶態(tài)也就沒有 SIGBUS 風(fēng)險(xiǎn)// ZeroCopySender.java —— 用 transferTo 把文件直接 DMA 到 socket public class ZeroCopySender { public long send(FileChannel src, SocketChannel dst) throws IOException { long position 0; long total src.size(); // 1. transferTo 在內(nèi)核態(tài)完成文件頁(yè) → socket不經(jīng)過 Java 堆 // 2. 老版本 JDK 單次最多搬 2GB需要循環(huán)高版本已放寬 while (position total) { long sent src.transferTo(position, total - position, dst); if (sent 0) break; // 3. 對(duì)流式 socket 要防 0 字節(jié)返回 position sent; } return position; } }逐行看第 5 行拿源文件通道和目標(biāo) socket 通道第 9 行transferTo是零拷貝核心數(shù)據(jù)從頁(yè)緩存直達(dá)網(wǎng)卡第 11 行處理老 JDK 的 2GB 上限循環(huán)搬第 12 行sent 0時(shí)跳出避免某些 NIO 實(shí)現(xiàn)下對(duì)非空 socket 返回 0 導(dǎo)致死循環(huán)。這個(gè)寫法完全不涉及 mmap也就沒有 SIGBUS 風(fēng)險(xiǎn)。另一個(gè)坑MappedByteBuffer 想釋放可沒那么容易mmap 出來的內(nèi)存不在 Java 堆里GC 管不到必須等DirectByteBuffer被 GC 后才由Cleaner釋放。如果你在一個(gè)長(zhǎng)生命周期服務(wù)里頻繁ch.map(...)小文件很容易堆積大量看似可回收、實(shí)則還占著地址空間的映射直到j(luò)ava.lang.OutOfMemoryError: Map failed或地址空間耗盡。// MmapLeakDemo.java —— 頻繁 map 小文件要顯式釋放避免地址空間堆積 public class MmapLeakDemo { public ByteBuffer open(String path) throws Exception { FileChannel ch FileChannel.open(Paths.get(path), StandardOpenOption.READ); MappedByteBuffer buf ch.map(FileChannel.MapMode.READ_ONLY, 0, ch.size()); // 1. 拿到 Cleaner顯式釋放不等 GC ((DirectBuffer) buf).cleaner().clean(); // 2. JDK9 需配 --add-exports 才能強(qiáng)轉(zhuǎn) DirectBuffer return buf; } }逐行看第 6 行強(qiáng)轉(zhuǎn)DirectBuffer拿Cleaner第 7 行clean()立即回收映射避免頻繁 map 小文件時(shí)地址空間只漲不跌。注意強(qiáng)轉(zhuǎn)DirectBuffer依賴內(nèi)部 APIJDK 模塊化后需要--add-exports生產(chǎn)里我們更傾向讀出來就拷堆內(nèi)然后忘掉映射見實(shí)戰(zhàn)二而不是手動(dòng) clean。復(fù)盤數(shù)據(jù)那 7 分鐘丟了多少事故當(dāng)天的影響很具體12:00:00 起 7 分鐘內(nèi)訂單流水丟失約 38 萬條后來用 binlog 補(bǔ)錄了 31 萬剩 7 萬條因?qū)戇M(jìn)程也崩了沒落盤客訴 240 起定級(jí) P2。改成寫用普通 BufferedOutputStream、讀用上面的 readSafe之后p99 延遲從原來的 0.4ms 漲到 1.1ms——我們接受了這 0.7ms換來了進(jìn)程不再神秘消失。我們?cè)谕瑱C(jī)8 核、512MB 文件壓了一組對(duì)比transferTo 約 180ms、mmap 立即 heap copy 約 210ms、傳統(tǒng) read write 約 240ms。差距不大說明零拷貝在這類負(fù)載下收益有限真正要命的是 mmap 的崩潰風(fēng)險(xiǎn)而不是那幾十毫秒。三種方案取舍對(duì)比方案是否映射用戶態(tài)SIGBUS 風(fēng)險(xiǎn)適用場(chǎng)景我們的取舍mmap 直讀是高文件可被外部截?cái)喑笪募S機(jī)讀、進(jìn)程內(nèi)共享不用除非文件生命周期完全可控mmap 立即拷堆內(nèi)是僅窗口低讀取即解綁需要零拷貝讀又怕截?cái)嘧x流水用它sendfile / transferTo否無文件 → 網(wǎng)絡(luò)轉(zhuǎn)發(fā)下載/轉(zhuǎn)發(fā)用它普通 BufferedInputStream否無小文件、對(duì)延遲不敏感寫流水用它我的取舍我不建議為了零拷貝幾個(gè)字就上 mmap。我們踩的這個(gè)坑本質(zhì)不是技術(shù)選錯(cuò)而是把外部可變的文件映射到進(jìn)程內(nèi)存——這兩件事天生沖突。我的判斷是文件 → 網(wǎng)絡(luò)的場(chǎng)景無腦用 transferTo進(jìn)程內(nèi)需要隨機(jī)讀且文件穩(wěn)定才考慮 mmap凡是文件可能被 logrotate / 運(yùn)維 / 其他進(jìn)程改寫的mmap 一定要配讀出來即刻拷貝進(jìn)堆內(nèi)的兜底否則就是埋雷。零拷貝從來不是性能開關(guān)而是一份你要自己保證文件不變的契約。思考題你們?nèi)罩?/ 流水類文件現(xiàn)在用 mmap 嗎如果用的今晚能不能搜一下代碼里有沒有FileChannel.map之后直接把 buf 交出去、且文件 inode 不在你掌控內(nèi)的地方那一行很可能就是下個(gè)故障夜的源頭。