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

语言: CN / TW / HK

在上一篇文章中,主要介绍了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中目前好像还未有支持。