資訊專欄INFORMATION COLUMN
摘要：而每個文件系統又可以設置不同的調度算法，另外，還有虛擬內存缺頁中斷帶來的性能毛刺良心的提供了調優的腳本，這點做的不錯跑題了。測試環境核線程內存磁盤讀寫左右虛擬內存未關閉，大小測試注意點為了防止緩存的影響，每次都生成一個新的文件進行讀取。
前言
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
測試注意點：
為了防止 PageCache 緩存的影響，每次都生成一個新的文件進行讀取。
為了測試不同數據包對性能的影響，需要使用不同大小的數據包進行多次測試。
force 對性能影響很大，應該多帶帶測試。
使用 1GB 文件進行測試（小文件沒有參考意義，大文件 mmap 無法映射）
純粹讀測試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。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/77634.html
摘要：與此同時，因新冠疫情的影響使得用戶對移動應用程序的需求激增。調查報告顯示年移動應用程序已經產生了億美元的收入，預計到年將產生億美元的收入。 引言 計劃在2021年進...
摘要：關于中順序的基本操作關于中順序的基本操作寫在前面最近研究一下中的順序，在網絡上找了一會兒，發現少有詳細的介紹，顧此在此處說說順序，才學疏淺，如有不對，望賜教。上述代碼中標記位置中，返回下一次操作時的位置。關于JAVA中順序IO的基本操作 寫在前面 最近研究一下JAVA中的順序IO，在網絡上找了一會兒，發現少有詳細的介紹，顧此在此處說說順序IO，才學疏淺，如有不對，望賜...
摘要：此處補充說明下，不論是還是都不提供指定區間的刷盤策略，只提供一個方法，所以無法精確控制落盤數據的大小。一、概述由前文可知，RocketMQ有幾個非常重要的概念：broker 服務端，負責存儲、收發消息producer 客戶端1，負責產生消息consumer 客服端2，負責消費消息既然是消息隊列，那消息的存儲的重要程度不言而喻，本節我們聚焦broker服務端，看下消息在broker端是如何存儲...
摘要：前言從字面意思理解就是數據不需要來回的拷貝，大大提升了系統的性能這個詞我們也經常在，，，等框架中聽到，經常作為其提升性能的一大亮點下面從的幾個概念開始，進而在分析零拷貝。 前言 從字面意思理解就是數據不需要來回的拷貝，大大提升了系統的性能；這個詞我們也經常在java nio，netty，kafka，RocketMQ等框架中聽到，經常作為其提升性能的一大亮點；下面從I/O的幾個概念開始，...
摘要：壓縮文件從秒到秒的優化過程有一個需求需要將前端傳過來的張照片，然后后端進行處理以后壓縮成一個壓縮包通過網絡流傳輸出去。源碼如下使用映射文件開始時間內存中的映射文件打印如下可以看到速度和使用的速度差不多的。 壓縮20M文件從30秒到1秒的優化過程 有一個需求需要將前端傳過來的10張照片，然后后端進行處理以后壓縮成一個壓縮包通過網絡流傳輸出去。之前沒有接觸過用Java壓縮文件的，所以就直接...
閱讀 1994·2021-11-15 18:09
閱讀 889·2021-09-06 15:13
閱讀 2636·2021-08-23 09:43
閱讀 2016·2019-08-30 15:54
閱讀 2208·2019-08-30 13:56
閱讀 2476·2019-08-26 11:31
閱讀 3069·2019-08-26 10:56
閱讀 684·2019-08-26 10:28
