java - 为什么ByteBuffer.allocate()和ByteBuffer.allocateDirect()之间的奇异性能曲线差异

Question

我正在研究一些SocketChannel到SocketChannel的代码，这些代码最适合直接字节缓冲区-长寿且很大(每个连接数十到数百兆字节)。在用FileChannel散列确切的循环结构时，我运行了关于ByteBuffer.allocate()和ByteBuffer.allocateDirect()性能的一些微基准测试。

结果令人惊讶，我无法真正解释。在下图中，对于ByteBuffer.allocate()传输实现，在256KB和512KB处有一个非常明显的悬崖-性能下降了约50％! ByteBuffer.allocateDirect()似乎也有较小的性能下降。 (％增益系列有助于可视化这些更改。)

缓冲区大小(字节)与时间(MS)的比较

为什么ByteBuffer.allocate()和ByteBuffer.allocateDirect()之间的奇数性能曲线有所不同？ 幕后到底发生了什么？

可能与硬件和操作系统有关，因此非常详细，因此以下是这些详细信息:

带双核Core 2 CPU的MacBook Pro

英特尔X25M SSD驱动器

OSX 10.6.4

源代码，根据要求:

package ch.dietpizza.bench;

import static java.lang.String.format;
import static java.lang.System.out;
import static java.nio.ByteBuffer.*;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.UnknownHostException;
import java.nio.ByteBuffer;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;
import java.nio.channels.WritableByteChannel;

public class SocketChannelByteBufferExample {
    private static WritableByteChannel target;
    private static ReadableByteChannel source;
    private static ByteBuffer          buffer;

    public static void main(String[] args) throws IOException, InterruptedException {
        long timeDirect;
        long normal;
        out.println("start");

        for (int i = 512; i <= 1024 * 1024 * 64; i *= 2) {
            buffer = allocateDirect(i);
            timeDirect = copyShortest();

            buffer = allocate(i);
            normal = copyShortest();

            out.println(format("%d, %d, %d", i, normal, timeDirect));
        }

        out.println("stop");
    }

    private static long copyShortest() throws IOException, InterruptedException {
        int result = 0;
        for (int i = 0; i < 100; i++) {
            int single = copyOnce();
            result = (i == 0) ? single : Math.min(result, single);
        }
        return result;
    }


    private static int copyOnce() throws IOException, InterruptedException {
        initialize();

        long start = System.currentTimeMillis();

        while (source.read(buffer)!= -1) {    
            buffer.flip();  
            target.write(buffer);
            buffer.clear();  //pos = 0, limit = capacity
        }

        long time = System.currentTimeMillis() - start;

        rest();

        return (int)time;
    }   


    private static void initialize() throws UnknownHostException, IOException {
        InputStream  is = new FileInputStream(new File("/Users/stu/temp/robyn.in"));//315 MB file
        OutputStream os = new FileOutputStream(new File("/dev/null"));

        target = Channels.newChannel(os);
        source = Channels.newChannel(is);
    }

    private static void rest() throws InterruptedException {
        System.gc();
        Thread.sleep(200);      
    }
}

Answer 1

ByteBuffer的工作方式以及为什么Direct(Byte)Buffers现在才是真正有用的。

首先，我有点惊讶，这不是常识，但要带我

直接字节缓冲区在Java堆外部分配地址。

这是最重要的:所有OS(和 native C)功能都可以利用该地址，而无需将对象锁定在堆上并复制数据。复制的简短示例:为了通过Socket.getOutputStream()。write(byte [])发送任何数据， native 代码必须“锁定” byte []，将其复制到Java堆外，然后调用OS函数，例如send。复制是在堆栈上执行(对于较小的byte [])，或者通过malloc/free进行复制(对于较大的字节)。
DatagramSockets没有什么不同，它们也可以复制-除了它们限于64KB并分配在堆栈上，如果线程堆栈不够大或深度递归，它们甚至可以杀死进程。
注意:锁定可防止JVM/GC在堆周围移动/重新分配对象

因此，在引入NIO的前提下，避免了复制和大量流传输/间接调用。在数据到达目的地之前，通常有3-4种缓冲类型的流。 (是的，波兰以出色的射门扳平了(!))
通过引入直接缓冲区，java可以直接与C native 代码通信，而无需任何必要的锁定/复制。因此，sent函数可以将缓冲区的地址添加到该位置，并且性能与 native C几乎相同。
那就是直接缓冲区。

有直接缓冲区的主要问题-对于allocate and expensive to deallocate来说它们很昂贵，并且使用起来很麻烦，没有像byte []这样的东西。

非直接缓冲区不能提供直接缓冲区的真正本质-即直接桥接到 native /OS，而它们是轻量级的并且共享完全相同的API-甚至，它们可以wrap byte[]甚至它们的支持数组都可用直接操纵-不爱什么？好吧，他们必须被复制!

因此，由于OS/native不能自然地使用em，因此Sun/Oracle如何处理非直接缓冲区。使用非直接缓冲区时，必须创建直接计数器部分。该实现足够聪明，可以使用ThreadLocal并通过SoftReference *缓存一些直接缓冲区，从而避免了高昂的创建成本。天真的部分是在复制它们时出现的-每次尝试复制整个缓冲区(remaining())。

现在想像一下:512 KB非直接缓冲区将变为64 KB套接字缓冲区，套接字缓冲区占用的空间不会超过其大小。因此，第一次将512 KB从非直接复制到线程本地直接，但仅会使用其中的64 KB。下次将复制512-64 KB，但仅使用64 KB，第三次将复制512-64 * 2 KB，但仅使用64 KB，依此类推...这是乐观的，因为总是套接字缓冲区将完全为空。因此，您不仅要总共复制n KB，而且要复制n×n÷m(n = 512，m = 16(套接字缓冲区剩余的平均空间))。

复制部分是所有非直接缓冲区的公共(public)/抽象路径，因此实现永远不知道目标容量。复制会破坏缓存，而不会破坏缓存，减少内存带宽等。

*有关SoftReference缓存的说明:它取决于GC的实现，并且体验可能会有所不同。 Sun的GC使用可用的堆内存来确定SoftRefence的生命周期，这将导致释放时有些尴尬的行为-应用程序需要再次分配以前缓存的对象-即分配更多(直接ByteBuffer在堆中占很小的一部分，因此至少它们不会影响额外的缓存垃圾，而是会受到影响)

我的经验法则-池直接缓冲区的大小与套接字读/写缓冲区的大小相同。操作系统绝不会复制过多的内容。

此微基准测试主要是内存吞吐量测试，操作系统会将文件完全放在缓存中，因此它主要测试memcpy。一旦缓冲区用完了L2缓存，性能下降就会很明显。同样地运行基准会增加和累积GC收集成本。 (rest()不会收集软引用的ByteBuffers)