ByteBuffer.allocate（）与ByteBuffer.allocateDirect（）

Question

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

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

Answer 1

操作系统在内存区域上执行I / O操作。就操作系统而言，这些存储区是连续的字节序列。因此，只有字节缓冲区才有资格参与I / O操作就不足为奇了。还记得操作系统将直接访问该进程的地址空间，在本例中为JVM进程，以传输数据。这意味着作为I / O操作目标的存储区必须是连续的字节序列。在JVM中，字节数组可能不会连续存储在内存中，否则垃圾收集器可以随时移动它。数组是Java中的对象，数据在该对象中的存储方式可能因一个JVM实现而异。

因此，引入了直接缓冲区的概念。直接缓冲区旨在与通道和本机I / O例程进行交互。他们尽最大努力将字节元素存储在通道可用于直接或原始访问的内存区域中，方法是使用本机代码告诉操作系统直接耗尽或填充内存区域。

直接字节缓冲区通常是I / O操作的最佳选择。通过设计，它们支持JVM可用的最有效的I / O机制。可以将非直接字节缓冲区传递给通道，但是这样做可能会导致性能下降。非直接缓冲区通常不可能成为本机I / O操作的目标。如果将非直接ByteBuffer对象传递给通道进行写入，则该通道可能会在每次调用时隐式执行以下操作：

1. 创建一个临时直接ByteBuffer对象。
2. 将非直接缓冲区的内容复制到临时缓冲区。
3. 使用临时缓冲区执行低级I / O操作。
4. 临时缓冲区对象超出范围，最终被垃圾回收。
   这可能会导致每个I / O上的缓冲区复制和对象流失，这正是我们想要避免的事情。但是，根据实现的不同，情况可能还不错。运行时可能会缓存和重用直接缓冲区，或者执行其他巧妙的技巧来提高吞吐量。如果你只是创建用于一次性使用的缓冲区，则差异并不明显。另一方面，如果你将在高性能场景中重复使用缓冲区，则最好分配直接缓冲区并重新使用它们。
   

直接缓冲区是I / O的最佳选择，但创建起来可能会比非直接字节缓冲区昂贵。直接缓冲区使用的内存是通过调用本地特定于操作系统的代码而绕过标准JVM堆分配的。根据主机操作系统和JVM的实现，设置和拆除直接缓冲区可能比堆驻留缓冲区昂贵得多。直接缓冲区的内存存储区不受垃圾回收的影响，因为它们在标准JVM堆之外。

使用直接缓冲区与非直接缓冲区的性能折衷可能因JVM，操作系统和代码设计而有很大差异。通过在堆外部分配内存，你可能会使你的应用程序受到JVM不了解的其他压力。发挥其他活动部件的作用时，请确保达到预期的效果。我建议使用旧的软件准则：首先使其运行，然后使其快速运行。不必太担心预先的优化；首先专注于正确性。JVM实现可能能够执行缓冲区缓存或其他优化，从而为你提供所需的性能，而无需你付出很多不必要的努力。