面试题：NIO/Netty 中的零拷贝体现在哪里？

最新推荐文章于 2024-07-16 09:46:01 发布

原创最新推荐文章于 2024-07-16 09:46:01 发布 · 692 阅读

6 ·

CC 4.0 BY-SA版权

网络编程与Netty 同时被 2 个专栏收录

17 篇文章

订阅专栏

9 篇文章

订阅专栏

本文深入探讨NIO中DirectByteBuffer与HeapByteBuffer的关系，揭示Java内存到网络的零拷贝原理，包括DirectBuffer如何减少内存间的数据拷贝，以及Netty如何进一步优化零拷贝。

前言

关于 NIO 里的零拷贝，很多博客提及的都是关于磁盘到网络的拷贝，他们写得很清楚了。总结起来就是，关于磁盘到网络（或磁盘到磁盘）的拷贝，与底层系统有关，Java 做的是封装。这种零拷贝是不能给我们 Java 程序操作数据的。因为 Java 程序在这里面起到的作用仅仅是发一个“系统调用”（以及封装），其它工作都是内核完成的。

现在的 Java 程序员，更多关注地是 Java 程序（内存）到网络之间的拷贝。因为关于磁盘的读写往往是通过数据库来做的，而不是通过 FileChannel 来读文件。本文想讲明白的，就是内存到网络的零拷贝。

DirectByteBuffer 与 HeapByteBuffer 的关系

我们创建一个 DirectByteBuffer：
类 ByteBuffer

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

底层是通过 c++ 的 malloc 方法分配内存。这个内存是堆外内存，也就是直接内存。

SocketChannelImpl 的源码得在 OpenJDK 中看，它里面有 write 和 read 方法，我们只看 write，因为它们是类似的。

public int write(ByteBuffer buf) throws IOException {
    if (buf == null)
        throw new NullPointerException();
    synchronized (writeLock) {
        ensureWriteOpen();
        int n = 0;
        try {
            begin();
            synchronized (stateLock) {
                if (!isOpen())
                    return 0;
                writerThread = NativeThread.current();
            }
            for (;;) {
            	//这里
                n = IOUtil.write(fd, buf, -1, nd);
                if ((n == IOStatus.INTERRUPTED) && isOpen())
                    continue;
                return IOStatus.normalize(n);
            }
        } finally {
            writerCleanup();
            end(n > 0 || (n == IOStatus.UNAVAILABLE));
            synchronized (stateLock) {
                if ((n <= 0) && (!isOutputOpen))
                    throw new AsynchronousCloseException();
            }
            assert IOStatus.check(n);
        }
    }
}

类 IOUtil

static int write(FileDescriptor fd, ByteBuffer src, long position,
                     NativeDispatcher nd)
        throws IOException
{
	//如果是DirectBuffer
    if (src instanceof DirectBuffer)
        return writeFromNativeBuffer(fd, src, position, nd);

	//不是DirectBuffer，就是一种堆内Buffer,Java里没有HeapBuffer这个接口
    // Substitute a native buffer
    int pos = src.position();
    int lim = src.limit();
    assert (pos <= lim);
    int rem = (pos <= lim ? lim - pos : 0);
    //还是要创建一个临时的DirectBuffer
    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);
    }
}

如果src为DirectBuffer，那么就直接调用writeFromNativeBuffer
否则src为一个HeapBuffer（Java中没有这个接口），先通过getTemporaryDirectBuffer创建一个临时的DirectBuffer，然后将HeapBuffer中的数据拷贝到这个临时的DirectBuffer，最后再调用writeFromNativeBuffer发送数据

writeFromNative本质是JVM发起了系统调用，将直接内存地址给内核操作。内核由于权限最高，所以可以通过我们发起JNI调用时传递的直接内存地址来帮我们直接操作堆外内存，也就减少了我们正常方式中需要将数据从用户态内存（堆内内存和堆外内存）拷贝到内核态内存。

为什么不能让内核系统直接操作堆内内存?因为 JVM 不让。

总结一下上面的内容：
在 NIO 里，通过 Buffer 的方式，Java 程序与外设（网卡、磁盘）交流，必须通过堆外内存。

如果不用 DirectBuffer 的内存复制过程：堆内内存 => 堆外内存 == 内核内存=> 外设（磁盘或者网卡缓存，它们与内核之间的数据读写不由 CPU 完成）
其中，堆外内存 == 内核内存 是因为：用户态的逻辑地址和内核态的逻辑地址使用的是同一个物理空间，内核态直接操作了用户态内存。