从rocketmq入手，解析各种零拷贝的jvm层原理

在上一篇文章中，主要介绍了rocketmq消息的存储流程。其主要使用了mmap的零拷贝技术实现了硬盘和内存的映射，从而提高了读写性能。在流程中有一个非常有意思的预热方法并没有详细分析，因为其中涉及到了一些系统方法的调用。而本文就从该方法入手，进而分享除了mmap之外，还有哪些零拷贝方法，以及他们的系统底层调用是怎样的。
本文的主要内容
1.page cache与mmap的关系
2.rocketmq对零拷贝的使用和优化
3.transferTo/From的零拷贝
4.splice的零拷贝

1.page cache与mmap的关系

page cache允许系统将一部分硬盘上的数据存放在内存中，使得对这部分数据的访问不需要再读取硬盘了，从而提高了读写性能。我理解这就是所谓的内核缓存。page cache以页为单位，一般一页为4kb。当程序需要将数据写入文件时，并不会，也不能直接将数据写到磁盘上，而是先将数据复制到page cache中，并标记为dirty，等待系统的flusher线程定时将这部分数据落到硬盘上。
对于用户程序来说，因为不能直接访问内核缓存，所以读取文件数据都必须等待系统将数据从磁盘上复制到page cache中，再从page cache复制一份到用户态的内存中。于是读取文件就产生了2次数据的复制：硬盘=>page cache，page cache=>用户态内存。同样的数据在内存中会存在2份，这既占用了不必要的内存空间，也产生了冗余的拷贝。针对此问题，操作系统提供了内存映射机制，对于linux来说，就提供了mmap操作。
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的内存中，实现文件磁盘地址和进程内存地址的映射关系。映射完成后，进程就可以直接读写操作这一段内存，而系统会自动回写dirty页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。

2.rocketmq对零拷贝的使用和优化

map的底层调用

rocketmq创建mappedFile对象后，会调用其init方法，完成了最终的映射操作。调用的方法是fileChannel.map。
查看FileChannelImpl.map：

public MappedByteBuffer map(MapMode var1, long var2, long var4) throws IOException {
    ...
    //调用map0方法完成映射，并返回内存地址
    var7 = this.map0(var6, var36, var10);
    ...
    //根据内存地址创建MappedByteBuffer对象，供java层面的操作
    var37 = Util.newMappedByteBuffer(var35, var7 + (long)var12, var13, var15);
    return var37;
    ...
}

继续查看map0方法：

 private native long map0(int var1, long var2, long var4) throws IOException;

发现其是一个native方法，于是就需要去jdk源码中看看了。
查看jdk源码：/src/java.base/unix/native/libnio/ch/FileChannelImpl.c

#define mmap64 mmap

JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
                                     jint prot, jlong off, jlong len)
{
    ...
    //这里调用的是mmap64，但是在文件开头define了mmap64就是mmap方法
    mapAddress = mmap64(
        0,                    /* Let OS decide location */
        len,                  /* Number of bytes to map */
        protections,          /* File permissions */
        flags,                /* Changes are shared */
        fd,                   /* File descriptor of mapped file */
        off);                 /* Offset into file */
    ...
    //返回映射完成的内存地址
    return ((jlong) (unsigned long) mapAddress);
}

因此fileChannel.map最底层调用就是linux的系统方法mmap。
mmap系统方法：为进程创建虚拟地址空间映射
参考说明：https://man7.org/linux/man-pages/man2/mmap.2.html

warmMappedFile的底层调用

rocketmq在创建完mmap映射后，还会作一个预热
查看mappedFile.warmMappedFile方法：

public void warmMappedFile(FlushDiskType type, int pages) {
    ByteBuffer byteBuffer = this.mappedByteBuffer.slice();
    int flush = 0;
    //用0来填充文件，特别注意这里i每次递增都是OS_PAGE_SIZE，查看可以看到是1024*4，即4kb
    //因此初始化是以页为单位填充的
    for (int i = 0, j = 0; i < this.fileSize; i += MappedFile.OS_PAGE_SIZE, j++) {
        byteBuffer.put(i, (byte) 0);
        //如果需要同步刷盘，那么如果写入mappedByteBuffer的数据超过了指定页数，就做一次强制刷盘
        if (type == FlushDiskType.SYNC_FLUSH) {
            //i是当前写入的数据位置，flush是已经刷盘的数据位置，如果差值大于指定的页数pages，就做一次强制刷盘
            if ((i / OS_PAGE_SIZE) - (flush / OS_PAGE_SIZE) >= pages) {
                flush = i;
                mappedByteBuffer.force();
            }
        }
        ...
    }
    //全部填充完毕后，如果配置了同步刷盘，就再做一次强制刷盘操作
    if (type == FlushDiskType.SYNC_FLUSH) {
        mappedByteBuffer.force();
    }
    //这里是对内存再做一些预处理
    this.mlock();
}

接着查看mlock方法：

public void mlock() {
    final long address = ((DirectBuffer) (this.mappedByteBuffer)).address();
    Pointer pointer = new Pointer(address);
    int ret = LibC.INSTANCE.mlock(pointer, new NativeLong(this.fileSize));
    int ret = LibC.INSTANCE.madvise(pointer, new NativeLong(this.fileSize), LibC.MADV_WILLNEED);
}

mlock方法主要做了2个系统方法的调用，mlock和madvise
mlock系统方法：锁定内存中的虚拟地址空间，防止其被交换系统的swap空间中。
swap空间就是磁盘上的一块空间，当内存不够用时，系统会将部分内存中不常用的数据放到磁盘上。mmap本身就是为了提高读写性能，如果被映射的内存数据被放到了磁盘上，那就失去了mmap的意义了，所以要做一个mlock进行内存的锁定。
参考说明：https://man7.org/linux/man-pages/man2/mlock.2.html
madvise系统方法:该方法功能很多，主要是给系统内核提供内存处理建议，可以根据需要传入参数。
在rocketmq中，传入的参数是MADV_WILLNEE，该参数的意思是告诉系统内核，这块内存一会儿就会用到，于是系统就会提前加载被映射的文件数据到内存中，这样就不会在需要使用的时候才去读取磁盘，影响性能。其他建议类型可以参考下面的链接。
参考说明：https://man7.org/linux/man-pages/man2/madvise.2.html

落盘的底层调用

上面的分析仅仅是创建mappedFile的过程，而在实际存储消息的时候，无论是使用堆外内存还是直接使用mappedByteBuffer，都需要额外的刷盘任务负责保证数据写入磁盘。因此接下去看下刷盘的底层调用是什么。
查看MappedFile.flush方法：

public int flush(final int flushLeastPages) {
    ...
    if (writeBuffer != null || this.fileChannel.position() != 0) {
        //如果使用了堆外内存，则调用fileChannel的force方法
        this.fileChannel.force(false);
    } else {
        //如果使用的是mappedByteBuffer，则调用相应的force方法
        this.mappedByteBuffer.force();
    }
    ...
}

该方法比较简单，根据是否启用堆外内存，调用不同的force方法。
查看FileChannelImpl.force方法：

public void force(boolean var1) throws IOException {
    ...
    do {
        //调用FileDispatcher的force方法
        var2 = this.nd.force(this.fd, var1);
    } while(var2 == -3 && this.isOpen());
    ...
}

查看FileDispatcherImpl.force方法，会发现其调用的force0的natvie方法，因此直接看jdk源码

JNIEXPORT jint JNICALL
Java_sun_nio_ch_FileDispatcherImpl_force0(JNIEnv *env, jobject this,
                                          jobject fdo, jboolean md)
{
    ...
    result = fsync(fd);
    ...
}

因此fileChannel.force的底层就是调用了fsync方法
fsync系统方法：将内核内存中有修改的数据同步到相应文件的磁盘空间
参考说明：https://man7.org/linux/man-pages/man2/fsync.2.html
查看MappedByteBuffer的force方法，可以看到直接调用了force0的native方法：

JNIEXPORT void JNICALL
Java_java_nio_MappedByteBuffer_force0(JNIEnv *env, jobject obj, jobject fdo,
                                      jlong address, jlong len)
{
    int result = msync(a, (size_t)len, MS_SYNC);
    ...
}

因此mappedByteBuffer.force的底层调用了msync方法
msync系统方法：将mmap映射的内存空间中的修改同步到文件系统中
参考说明：https://man7.org/linux/man-pages/man2/msync.2.html

因此做一个总结，rocketmq对零拷贝的使用和优化分为5步：
1.调用系统mmap方法进行虚拟内存地址映射
2.用0来填充page cache，初始化文件
3.调用系统mlock方法，防止映射的内存被放入swap空间
4.调用系统madvise方法，使得文件会被系统预加载
5.根据是否启用堆外内存，调用fsync或者msync刷盘

transferTo/From的零拷贝

在使用fileChannel时，如果不需要对数据作修改，仅仅是传输，那么可以使用transferTo或者transferFrom进行2个channel间的传递，这种传递是完全处于内核态的，因此性能较好。
简单的例子如下：

SocketChannel sc = SocketChannel.open(new InetSocketAddress("localhost", 8090));
FileChannel fc = new RandomAccessFile("filename", "r").getChannel();
fc.transferTo(0, 100, sc);

查看FileChannelImpl.transferTo方法，最终会调用到transfer0方法，调用链如下：
transferTo->transferToDirectly->transferToDirectlyInternal->transferTo0
查看jdk源码：/src/java.base/unix/native/libnio/ch/FileChannelImpl.c

...
JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_transferTo0(JNIEnv *env, jobject this,
                                            jobject srcFDO,
                                            jlong position, jlong count,
                                            jobject dstFDO)
{
#if defined(__linux__)
    off64_t offset = (off64_t)position;
    jlong n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
    ...
#elif defined (__solaris__)
    result = sendfilev64(dstFD, &sfv, 1, &numBytes);
    ...
#elif defined(__APPLE__)
    result = sendfile(srcFD, dstFD, position, &numBytes, NULL, 0);
    ...
#endif
}
...

根据不同的系统调用sendfile方法。
sendfile系统方法：在内核态中进行两个文件描述符之间数据的传输
参考说明：https://man7.org/linux/man-pages/man2/sendfile.2.html

splice的零拷贝

在查询资料的过程中，了解到Linux 2.6.17支持了splice。该方法和sendFile类似，也是直接在内核中完成了数据的传输。区别在于sendfile将磁盘数据加载到内核缓存后，需要一次CPU拷贝将数据拷贝到socket缓存，而splice是更进一步，连这个CPU拷贝也不需要了，直接将两个内核空间的buffer进行pipe。
好像java对此并没有支持，所以就不深究了。
参考说明：https://man7.org/linux/man-pages/man2/splice.2.html

到此从rocketmq的mmap到其他零拷贝的底层调用分析就结束了，总结如下：
1.rocketmq底层采用了mmap的零拷贝技术提高读写性能。
2.使用了mlock和madvise进一步优化性能
3.根据是否使用堆外内存选择调用fsync或者msync进行刷盘
4.sendfile实现了内核态的数据拷贝，java中有fileChannel.transferTo/From支持该操作
5.Linux2.6.17新支持了splice的零拷贝，可能比sendfile更优秀，但java中目前好像还未有支持。