ByteBuffer.allocate（）与ByteBuffer.allocateDirect（）

Question

到allocate()或到allocateDirect()，这就是问题。

几年来，我一直坚持认为，由于DirectByteBuffers是操作系统级别的直接内存映射，因此与get相比，它在执行get / put调用时将执行得更快HeapByteBuffer。到目前为止，我从来没有真正想知道有关该情况的确切细节。我想知道这两种类型中ByteBuffer的哪种更快，以及在什么条件下。

Answer 1

罗恩·希切斯（Ron Hitches）在他的著作《Java NIO》中似乎提供了我认为可以很好地回答您的问题的答案：操作系统在内存区域上执行I / O操作。就操作系统而言，这些存储区是连续的字节序列。因此，只有字节缓冲区才有资格参与I / O操作就不足为奇了。还记得操作系统将直接访问该进程的地址空间，在本例中为JVM进程，以传输数据。这意味着作为I / O操作目标的存储区必须是连续的字节序列。在JVM中，字节数组可能不会连续存储在内存中，否则垃圾回收器可以随时移动它。数组是Java中的对象，数据在该对象中的存储方式可能因一个JVM实现而异。因此，引入了直接缓冲区的概念。直接缓冲区旨在与通道和本机I / O例程进行交互。他们尽最大努力将字节元素存储在通道可用于直接访问或原始访问的存储区中，方法是使用本机代码告诉操作系统直接耗尽或填充存储区。直接字节缓冲区通常是I / O操作的最佳选择。通过设计，它们支持JVM可用的最有效的I / O机制。非直接字节缓冲区可以传递给通道，但是这样做可能会导致性能下降。非直接缓冲区通常不可能成为本机I / O操作的目标。如果将非直接ByteBuffer对象传递给通道进行写入，则该通道可能会在每次调用时隐式执行以下操作：创建一个临时直接ByteBuffer对象。将非直接缓冲区的内容复制到临时缓冲区。使用临时缓冲区执行低级I / O操作。临时缓冲区对象超出范围，最终被垃圾回收。这可能会导致每个I / O上的缓冲区复制和对象流失，这正是我们想要避免的事情。但是，根据实现的不同，情况可能还不错。运行时可能会缓存和重用直接缓冲区，或者执行其他巧妙的技巧来提高吞吐量。如果您只是创建用于一次性使用的缓冲区，则差异并不明显。另一方面，如果您将在高性能场景中重复使用缓冲区，则最好分配直接缓冲区并重新使用它们。直接缓冲区是I / O的最佳选择，但创建起来可能会比非直接字节缓冲区昂贵。直接缓冲区使用的内存是通过绕过标准JVM堆调用本地特定于操作系统的代码来分配的。根据主机操作系统和JVM的实现，设置和拆除直接缓冲区可能比堆驻留缓冲区昂贵得多。直接缓冲区的内存存储区不受垃圾回收的影响，因为它们在标准JVM堆之外。使用直接缓冲区与非直接缓冲区的性能折衷可能因JVM，操作系统和代码设计而有很大差异。通过在堆之外分配内存，您可能会使您的应用程序受到JVM不了解的其他压力。发挥其他活动部件的作用时，请确保达到预期的效果。我建议使用旧的软件准则：首先使其运行，然后使其快速运行。不必太担心预先优化；首先专注于正确性。JVM实现可能能够执行缓冲区缓存或其他优化，从而为您提供所需的性能，而无需您付出很多不必要的努力。

Answer 2

因为DirectByteBuffers是OS级别的直接内存映射他们不是。它们只是正常的应用程序进程内存，而在Java GC期间不会进行重定位，从而极大地简化了JNI层中的内容。您所描述的适用于MappedByteBuffer。使用get / put调用可以更快地执行结论并非来自前提。前提是假的；结论也是错误的。他们更快一旦你的JNI层内，如果你正在阅读和同写DirectByteBuffer他们是多快，因为数据从来没有越过边界JNI在所有。

Answer 3

最好自己做测量。快速的答案似乎是，从allocateDirect()缓冲区发送所需的时间比allocate()变体（测试为将文件复制到/ dev / null）要少25％到75％，具体取决于大小，但是分配本身可能会明显变慢（即使100倍）。