摘要：而每个文件系统又可以设置不同的调度算法，另外，还有虚拟内存缺页中断带来的性能毛刺良心的提供了调优的脚本，这点做的不错跑题了。测试环境核线程内存磁盘读写左右虚拟内存未关闭，大小测试注意点为了防止缓存的影响，每次都生成一个新的文件进行读取。
前言
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。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/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压缩文件的，所以就直接...
阅读 1763·2021-11-15 18:09
阅读 650·2021-09-06 15:13
阅读 2531·2021-08-23 09:43
阅读 1876·2019-08-30 15:54
阅读 2114·2019-08-30 13:56
阅读 2378·2019-08-26 11:31
阅读 2935·2019-08-26 10:56
阅读 483·2019-08-26 10:28
