FileChannel 和 MappedByteBuffer 实现上有什么不同？为什么性能差这么多？

Question

环境

mac 10.14
2.2 GHz Intel Core i7
APPLE SSD AP0512M （底下有小伙伴测出相反的结果，跟硬盘有关系）

问题描述

看RocketMQ源码的时候看到数据写到MappedFile有两种方式：

1. 先写入 writeBuffer， 再将writeBuffer 写入到 FileChannel 再调用 force()刷盘；
2. 数据直接写入MappedByteBuffer， 调用force() 刷盘；

我的问题是为什么不直接采用第二种方法？于是我通过下面的代码验证两种方式的写性能。

相关代码

import java.io.*;
import java.nio.ByteBuffer;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
public class MMapTest {

    static File file= new File("./test.txt");
    static ByteBuffer buffer;

    static int fileSize = 8 * 1024 * 1024;
    static boolean del = true;

    public static void main(String[] args) {
        init(1);
        deleteFile();
        int[] sizes = {128,256,512,4096,8192,1024*16,1024*32,1024*128,1024*512};
        try {
            for (int size : sizes) {
                testDBChannel(size);
                testMappedByteBuffer(size);
                System.out.println();
            }

        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    private static void init(int size) {
        buffer = ByteBuffer.allocateDirect(size);
    }

    private static void deleteFile() {
        file.delete();
    }

    private static void testDBChannel(int size) throws IOException {
        init(size);
        RandomAccessFile rw = new RandomAccessFile(file, "rw");
        FileChannel channel = rw.getChannel();
        int writeSize = 0;
        Long start = System.currentTimeMillis();
            while (writeSize < fileSize) {
            buffer.clear();
            buffer.put(new byte[size]);
            buffer.flip();
            channel.position(writeSize);
            channel.write(buffer);
            channel.force(false);
            writeSize += size;
        }
        //channel.force(false);
        System.out.println("DirectBuffer + FileChannel write " + size + " bytes every time cost: " + (System.currentTimeMillis() - start) + "ms");
        if(del)
        deleteFile();

    }

    private static void testMappedByteBuffer(int size) throws IOException {
        init(size);
        RandomAccessFile rw = new RandomAccessFile(file, "rw");
        FileChannel channel = rw.getChannel();
        MappedByteBuffer map = channel.map(FileChannel.MapMode.READ_WRITE, 0, fileSize);
        int writeSize = 0;
        Long start = System.currentTimeMillis();
        while (writeSize < fileSize) {
            map.put(new byte[size]);
            map.force();
            writeSize += size;
        }
        //map.force();
        System.out.println("MappedByteBuffer write " + size + " bytes every time cost: " + (System.currentTimeMillis() - start) + "ms");
        if(del)
            deleteFile();
    }
}

输出：

DirectBuffer + FileChannel write 128 bytes every time cost: 3577ms
MappedByteBuffer write 128 bytes every time cost: 13518ms

DirectBuffer + FileChannel write 256 bytes every time cost: 1968ms
MappedByteBuffer write 256 bytes every time cost: 7044ms

DirectBuffer + FileChannel write 512 bytes every time cost: 1001ms
MappedByteBuffer write 512 bytes every time cost: 3037ms

DirectBuffer + FileChannel write 1024 bytes every time cost: 659ms
MappedByteBuffer write 1024 bytes every time cost: 1274ms

DirectBuffer + FileChannel write 4096 bytes every time cost: 214ms
MappedByteBuffer write 4096 bytes every time cost: 331ms

DirectBuffer + FileChannel write 8192 bytes every time cost: 137ms
MappedByteBuffer write 8192 bytes every time cost: 168ms

DirectBuffer + FileChannel write 16384 bytes every time cost: 77ms
MappedByteBuffer write 16384 bytes every time cost: 86ms

DirectBuffer + FileChannel write 32768 bytes every time cost: 44ms
MappedByteBuffer write 32768 bytes every time cost: 58ms

DirectBuffer + FileChannel write 131072 bytes every time cost: 16ms
MappedByteBuffer write 131072 bytes every time cost: 25ms

DirectBuffer + FileChannel write 524288 bytes every time cost: 10ms
MappedByteBuffer write 524288 bytes every time cost: 21ms

我的理解是两种方式都都是将数据写入到pageCache中再刷盘的，为什么耗时差这么多，具体两种方式的实现原理是什么？

一般情况下使用RocketMQ 都是异步刷盘，会利用OS的pageCache机制达到很高的性能；上面描述的这个问题是针对同步刷盘情况，按照 @Tyrael 第一种测试，SATA盘情况下，mbb 的性能 是要高于 db+fc 的，更加让我怀疑为什么不直接用mbb。

Answer 1

MappedByteBuffer在写盘时会自己创建一个DirectBuffer暂存的。因为写盘时操作系统要求传递的内存地址不能变，但是java堆管理在gc中可能把数据搬来搬去，所以需要一个堆外的DirectBuffer来存临时数据。相比直接DirectBuffer操作，是增加了一步的。 以上是看错了问题。我测试了三种情况，macpro 14mid，阿里云ecs，macpro18。从测试情况上看应该是跟系统硬件，系统本身有关系。但是没有什么规律的样子 2019-01-15更新 这几天参阅了大量资料，总结了一个应该是正确答案的答案：关于java8下，linux与mac得到的结果不同的解答，FileChannel的force方法与MappedByteBuffer的force方法，最终调用的是系统中的fsync与msync方法。 mac中，fsync方法明确说明了该方法不一定强制写盘（man page里也没有明确说写到哪了，我认为应该是写到了kernel自己的缓存里，此时fsync就返回成功了，然后kernel再缓慢的写盘 可以参考这篇文章中间的关于macos下的说明），但是同时提供了一个F_FULLFSYNC fcntl来进行强制写盘操作，msync没有说明，可以认为是强制写盘。 linux中， fsync方法明确说明了该方法只有写盘后才返回否则一直阻塞。这跟msync其实是类似的效果了。也有人说这种情况下，msync类似于fsync。这也是我在评论里有一个耗时差不多的情况的原因。但是从理论上，msync应该快于fsync，我怀疑是测试代码并没有达到fsync的瓶颈。 关于java11下FileChannel慢的要死的问题，这里我发现其实是FileChannel#write()方法拖慢了节奏，尝试着找了一下java8与java11在c下的write0方法的实现，看write0()代码上都是一样的，所以也没找出具体原因。怀疑可能跟write0调用的write方法有区别。 总结。jni的效率其实跟系统强关联，不同系统实现不同，可能会导致不同的结果，所以评论中的问题关于要用哪个，我建议是，在实际的机器环境上写测试脚本测试一下，哪个符合你的需求，就用哪个。然后以后的机器环境做统一。