前言
Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相關(guān)的類，使得 Java 程序員可以拋棄基于 Stream ，從而使用基于 Block 的方式讀寫文件，另外，JDK 還引入了 IO 性能優(yōu)化之王—— 零拷貝 sendFile 和 mmap。但他們的性能究竟怎么樣？ 和 RandomAccessFile 比起來，快多少？ 什么情況下快？到底是 FileChannel 快還是 MappedByteBuffer 快......
(零拷貝參考 Zero Copy I: User-Mode Perspective)
天啊，問題太多了?。。。。。?/p>
讓我們慢慢分析。
看看善于利用 IO 零拷貝的 MQ 們
我們知道，Java 世界有很多 MQ：ActiveMQ，kafka，RocketMQ，去哪兒 MQ，而他們則是 Java 世界使用 NIO 零拷貝的大戶。
然而，他們的性能卻大相同，拋開其他的因素，例如網(wǎng)絡(luò)傳輸方式，數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)，文件存儲(chǔ)方式，我們僅僅討論 Broker 端對(duì)文件的讀寫，看看他們有什么不同。
下圖是樓主查看源碼總結(jié)的各個(gè) MQ 使用的文件讀寫方式。
- kafka：record 的讀寫都是基于 FileChannel。index 讀寫基于 MMAP（廝大提示）。
- RocketMQ：讀盤基于 MMAP，寫盤默認(rèn)使用 MMAP，可通過修改配置，配置成 FileChannel，原因是作者想避免 PageCache 的鎖競(jìng)爭(zhēng)，通過兩層架構(gòu)實(shí)現(xiàn)讀寫分離。
- QMQ： 去哪兒 MQ，讀盤使用 MMAP，寫盤使用 FileChannel。
- ActiveMQ 5.15： 讀寫全部都是基于 RandomAccessFile，這也是我們拋棄 ActiveMQ 的原因。
那么，到底是 MMAP 強(qiáng)，還是 FileChannel 強(qiáng)？
MMAP 眾所周知，基于 OS 的 mmap 的內(nèi)存映射技術(shù)，通過 MMU 映射文件，使隨機(jī)讀寫文件和讀寫內(nèi)存相似的速度。
那 FileChannel 呢？是零拷貝嗎？很遺憾，不是。FileChannel 快，只是因?yàn)樗腔?block 的。
接下來，benchmark everything —— 徐媽.
Benchmark ？
如何 Benchmark？ Benchmark 哪些？
既然是讀寫文件，自然就要看讀寫性能，這是最基本的。但，注意，通常 MQ 會(huì)使用定時(shí)刷盤，防止數(shù)據(jù)丟失，MMAP 和 FileChannel 都有 force 方法，用于將 pageCache 的數(shù)據(jù)刷到硬盤上。force 會(huì)影響性能嗎？ 答案是會(huì)。影響到什么程度呢？ 不知道。每次寫入的數(shù)據(jù)大小會(huì)影響性能嗎，毫無疑問會(huì)，但規(guī)則是什么呢？FileOutputStream 真的一無是處嗎？答案是不一定。
一直以來，文件調(diào)優(yōu)都是藝術(shù)，因?yàn)橛绊懶阅艿囊蛩靥?，首先，SSD 的出現(xiàn)，已經(jīng)讓傳統(tǒng)基于 B+ tree 的樹形結(jié)構(gòu)產(chǎn)生了自我疑問，第二，每個(gè)文件系統(tǒng)的性能不同，Linux ext3 和 ext4 性能天壤之別（刪除文件的性能差距在 20 倍左右）。而 Max OS 的 HFS+ 系統(tǒng)被 Linus 稱之為“有史以來最垃圾的文件系統(tǒng)”，幸運(yùn)的是，蘋果終于在 2017 年推送了 macOS High Sierra 和 iOS 10.3 系統(tǒng)，這個(gè)兩個(gè)系統(tǒng)都拋棄了 HFS+，換成了性能更高的 APFS。而每個(gè)文件系統(tǒng)又可以設(shè)置不同的調(diào)度算法，另外，還有虛擬內(nèi)存缺頁中斷帶來的性能毛刺.......
（tips：良心的 RocketMQ 提供了 Linux IO 調(diào)優(yōu)的腳本，這點(diǎn)做的不錯(cuò) ：）
跑題了。
樓主寫了一個(gè)小項(xiàng)目，用于測(cè)試 Java MappedByteBuffer & FileChannel & RandomAccessFile & FileXXXputStream 的讀寫性能。大家也可以在自己的機(jī)器上跑跑看。
測(cè)試環(huán)境
CPU：intel i7 4核8線程 4.2GHz
內(nèi)存：40GB DDR4
磁盤：SSD 讀寫 2GB/s 左右
JDK1.8
OS：Mac OS 10.13.6
虛擬內(nèi)存： 未關(guān)閉，大小 9GB
測(cè)試注意點(diǎn)：
- 為了防止 PageCache 緩存的影響，每次都生成一個(gè)新的文件進(jìn)行讀取。
- 為了測(cè)試不同數(shù)據(jù)包對(duì)性能的影響，需要使用不同大小的數(shù)據(jù)包進(jìn)行多次測(cè)試。
- force 對(duì)性能影響很大，應(yīng)該單獨(dú)測(cè)試。
- 使用 1GB 文件進(jìn)行測(cè)試（小文件沒有參考意義，大文件 mmap 無法映射）
純粹讀測(cè)試
1GB 文件：
測(cè)試 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.
從這張圖里，我們看到，mmap 性能完勝，特別是在小數(shù)據(jù)量的情況下。其他的流，只有在4kb 的情況下，才開始反殺 mmap。因此，讀 4kb 以下的數(shù)據(jù)，請(qǐng)使用 mmap。
再放大看看 mmap 和 FileChannel 的比較：
根據(jù)上圖，我們看到，在寫入數(shù)據(jù)包大于 4kb 以上的情況下，F(xiàn)ileChannel 等一眾非零拷貝，基本完勝 mmap，除了那個(gè)一次讀 1G 文件的 BT 測(cè)試。
因此，如果你的數(shù)據(jù)包大于 4kb，請(qǐng)使用 FileChannel。
純粹寫測(cè)試
1GB 文件：
測(cè)試 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.
從上圖，我們可以看出，mmap 性能還是一樣的穩(wěn)定。FileChannel 也不差，但是在 32 字節(jié)數(shù)據(jù)量的情況下，還差點(diǎn)意思。
再看縮略圖：
我們看到，64字節(jié) 是 FileChannel 和 mmap 性能的分水嶺，從 64字節(jié)開始，F(xiàn)ileChannel 一路反殺，直到 BT 1GB 文件稍稍輸了一丟丟。
因此，我們建議：如果你的數(shù)據(jù)包大小在 64 字節(jié)以上，請(qǐng)使用 FileChannel 寫入。
異步 force 測(cè)試
我們知道，RocketMQ 使用異步刷盤，那么異步 force 對(duì)性能有沒有影響呢？benchmark everything。我們使用異步線程，每 16kb 刷盤一次，看看性能如何。
mmap 一直落后，且性能很差，除了在 2048 字節(jié)那里有一點(diǎn)點(diǎn)抖動(dòng)，基本維持 在 4000 左右，而沒有 force 的情況下，則在 1500 左右。而 FileChannel 則完全不受 force 的影響。在我的測(cè)試中，1GB 的文件，一次 force 需要 800 毫秒左右。buffer 越大，時(shí)間越多，反之則越小。
說個(gè)題外話，Kafka 一直不建議使用 force，大概也有這個(gè)原因。當(dāng)然，Kafka 還有自己的多副本策略保證數(shù)據(jù)安全。
這里，我們得出結(jié)論，如果你需要經(jīng)常執(zhí)行 force，即使是異步的，也請(qǐng)一定不要使用 mmap，請(qǐng)使用 FileChannel。
總結(jié)。
基于以上測(cè)試，我們得出一張圖表：
假設(shè)，我們的系統(tǒng)的數(shù)據(jù)包在 1024 - 2048 左右，我們應(yīng)該使用什么策略？
答：讀使用 mmap，僅僅寫使用 FileChannel。
再回過頭看看 MQ 的實(shí)現(xiàn)者們，似乎只有 QMQ 是 這么做的。當(dāng)然，RocketMQ 也提供了 FileChannel 的寫選項(xiàng)。但默認(rèn) mmap 寫加異步刷盤，應(yīng)該是 broker busy 的元兇吧。
而 Kafka，因?yàn)槟J(rèn)不 force，也是使用 FileChannel 進(jìn)行寫入的，為什么使用 FileChannel 讀呢？大概是因?yàn)橄⒌拇笮≡?4kb 以上吧。
這樣一揣測(cè)，這些 MQ 的設(shè)計(jì)似乎都非常合理。
最后，能不用 force 就別用 force。如果要用 force ，就請(qǐng)使用 FileChannel。
