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