Netty 零拷贝（一）NIO 对零拷贝的支持

Netty 零拷贝（二）NIO 对零拷贝的支持

目录

• Netty 零拷贝（二）NIO 对零拷贝的支持
  • 一、非直接缓冲区和直接缓冲区
  • 二、直接缓冲区应用
  • 三、DirectByteBuffer

Netty 之美系列目录 (https://www.cnblogs.com/binarylei/p/10117436.html)

相关文章：

• Netty 零拷贝（一）Linux 零拷贝
• Netty 零拷贝（二）NIO 对零拷贝的支持
• Netty 零拷贝（三）Netty 对零拷贝的改进

• 非直接缓冲区(HeapByteBuffer)：在 JVM 内存上分配一个字节数组 byte[] hb
• 直接缓冲区(DirectByteBuffer)：保存一个指向系统内核的地址 long address

一、非直接缓冲区和直接缓冲区

(1) Buffer 分配

// 分配非直接缓冲区
public static ByteBuffer allocate(int capacity) {
    if (capacity < 0)
        throw new IllegalArgumentException();
    return new HeapByteBuffer(capacity, capacity);
}

// 分配直接缓冲区
public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

(2) ByteBuffer 内存存储

public abstract class Buffer {
    // Invariants: mark <= position <= limit <= capacity
    private int mark = -1;
    private int position = 0;
    private int limit;
    private int capacity;

    // 直接缓冲区指向系统内核的一个地址，之所以放到父类中是为了加快 JNI 的访问速度
    long address;
}

public abstract class ByteBuffer extends Buffer {
    // 非直接缓冲区在 JVM 内存上分配一个字节数组
    final byte[] hb;
}

(3) DirectByteBuffer

DirectByteBuffer(int cap) {
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null
}

public byte get() {
    return ((unsafe.getByte(ix(nextGetIndex()))));
}

public ByteBuffer put(byte x) {
    unsafe.putByte(ix(nextPutIndex()), ((x)));
    return this;
}

DirectByteBuffer 对直接缓冲区的操作都委托给了类 sun.misc.Unsafe，Unsafe 都是一些本地方法 native。

public final class Unsafe {
    public native long allocateMemory(long bytes);
    public native byte    getByte(long address);
    public native void    putByte(long address, byte x);
}

二、直接缓冲区应用

使用直接缓冲区可以避免用户空间和系统空间之间的拷贝过程，即零拷贝。

FileChannel inChannel = FileChannel.open(Paths.get("1.png"), StandardOpenOption.READ);
FileChannel outChannel = FileChannel.open(Paths.get("3.png"),
        StandardOpenOption.WRITE, StandardOpenOption.READ, StandardOpenOption.CREATE);

// 方式一：内存映射文件，直接缓冲区
MappedByteBuffer inMappedBuf = inChannel.map(FileChannel.MapMode.READ_ONLY, 0, inChannel.size());
//只有 READ_WRITE，没有 WRITE，因此 outChannel 也要加上 READ
MappedByteBuffer outMappedBuf = outChannel.map(FileChannel.MapMode.READ_WRITE, 0, inChannel.size());

byte[] bytes = new byte[inMappedBuf.limit()];
inMappedBuf.get(bytes);
outMappedBuf.put(bytes);

// 方式二：transferTo 也是使用直接缓冲区
//inChannel.transferTo(0, inChannel.size(), outChannel);
//outChannel.transferFrom(inChannel, 0, inChannel.size());

三、DirectByteBuffer

Java NIO中的 direct buffer（主要是 DirectByteBuffer）其实是分两部分的：

       Java        |      native
                   |
 DirectByteBuffer  |     malloc'd
 [    address   ] -+-> [   data    ]

其中 DirectByteBuffer 自身是一个 Java 对象，在 Java 堆中；而这个对象中有个 long 类型字段 address，记录着一块调用 malloc() 申请到的 native memory。

FileChannel 的 read(ByteBuffer dst) 函数，write(ByteBuffer src) 函数中，如果传入的参数是 HeapBuffer 类型，则会临时申请一块 DirectBuffer，进行数据拷贝，而不是直接进行数据传输，这是出于什么原因？

// OpenJDK 的 sun.nio.ch.IOUtil
static int write(FileDescriptor fd, ByteBuffer src, long position,
                     NativeDispatcher nd) throws IOException {
    if (src instanceof DirectBuffer)
        return writeFromNativeBuffer(fd, src, position, nd);

    // Substitute a native buffer
    int pos = src.position();
    int lim = src.limit();
    assert (pos <= lim);
    int rem = (pos <= lim ? lim - pos : 0);
    ByteBuffer bb = Util.getTemporaryDirectBuffer(rem);
    try {
        bb.put(src);
        bb.flip();
        // Do not update src until we see how many bytes were written
        src.position(pos);

        int n = writeFromNativeBuffer(fd, bb, position, nd);
        if (n > 0) {
            // now update src
            src.position(pos + n);
        }
        return n;
    } finally {
        Util.offerFirstTemporaryDirectBuffer(bb);
    }
}

这里其实是在迁就 OpenJDK 里的 HotSpot VM 的一点实现细节。

HotSpot VM 里的 GC 除了 CMS 之外都是要移动对象的，是所谓 “compacting GC”。

如果要把一个 Java 里的 byte[] 对象的引用传给 native 代码，让 native 代码直接访问数组的内容的话，就必须要保证 native 代码在访问的时候这个 byte[] 对象不能被移动，也就是要被“pin”（钉）住。

可惜 HotSpot VM 出于一些取舍而决定不实现单个对象层面的 object pinning，要 pin 的话就得暂时禁用 GC ——也就等于把整个 Java 堆都给 pin 住。HotSpot VM 对 JNI 的 Critical 系 API 就是这样实现的。这用起来就不那么顺手。

所以 Oracle/Sun JDK / OpenJDK 的这个地方就用了点绕弯的做法。 它假设把 HeapByteBuffer 背后的 byte[] 里的内容拷贝一次是一个时间开销可以接受的操作，同时假设真正的 I/O 可能是一个很慢的操作。

于是它就先把 HeapByteBuffer 背后的 byte[] 的内容拷贝到一个 DirectByteBuffer 背后的 native memory 去，这个拷贝会涉及 sun.misc.Unsafe.copyMemory() 的调用，背后是类似 memcpy() 的实现。这个操作本质上是会在整个拷贝过程中暂时不允许发生 GC 的，虽然实现方式跟 JNI 的 Critical 系 API 不太一样。（具体来说是 Unsafe.copyMemory() 是 HotSpot VM 的一个 intrinsic 方法，中间没有 safepoint 所以 GC 无法发生）。

然后数据被拷贝到 native memory 之后就好办了，就去做真正的 I/O，把 DirectByteBuffer 背后的 native memory 地址传给真正做 I/O 的函数。这边就不需要再去访问 Java 对象去读写要做 I/O 的数据了。

参考：

1. 《Java NIO中，关于DirectBuffer，HeapBuffer的疑问？》：https://www.zhihu.com/question/57374068/answer/152691891

---

每天用心记录一点点。内容也许不重要，但习惯很重要！