to or to ，这就是问题所在。allocate()allocateDirect()
几年来，我只是坚持认为，由于s是操作系统级别的直接内存映射，因此它在get/put调用时比s执行得更快。直到现在，我从未真正有兴趣找出有关情况的确切细节。我想知道这两种类型的s中哪一种更快以及在什么条件下。DirectByteBufferHeapByteBufferByteBuffer
Ron Hitches在他的优秀著作《Java NIO》中似乎提供了我认为可以很好地回答你的问题：
操作系统对内存区域执行 I/O 操作。就操作系统而言，这些内存区域是连续的字节序列。因此，只有字节缓冲区才有资格参与 I/O 操作也就不足为奇了。还要回想一下，操作系统将直接访问进程的地址空间，在本例中为JVM进程，以传输数据。这意味着作为 I/O 分析目标的内存区域必须是连续的字节序列。在 JVM 中，字节数组可能不会连续存储在内存中，或者垃圾回收器可以随时移动它。数组是 Java 中的对象，数据存储在该对象中的方式可能因 JVM 实现而异。
因此，引入了直接缓冲区的概念。直接缓冲区用于与通道和本机 I/O 例程进行交互。他们尽最大努力将字节元素存储在通道可用于直接或原始访问的内存区域中，方法是使用本机代码告诉操作系统直接耗尽或填充内存区域。
直接字节缓冲区通常是 I/O 操作的最佳选择。根据设计，它们支持 JVM 可用的最高效的 I/O 机制。非直接字节缓冲区可以传递到通道，但这样做可能会降低性能。非直接缓冲区通常不可能成为本机 I/O 操作的目标。如果将非直接 ByteBuffer 对象传递到通道进行写入，则该通道可能会在每次调用时隐式执行以下操作：
- 创建一个临时的直接字节缓冲器对象。
- 将非直接缓冲区的内容复制到临时缓冲区。
- 使用临时缓冲区执行低级 I/O 操作。
- 临时缓冲区对象超出范围，最终被垃圾回收。
这可能会导致每个 I/O 上的缓冲区复制和对象改动，这正是我们想要避免的事情。但是，根据实现的不同，事情可能不会那么糟糕。运行时可能会缓存并重用直接缓冲区或执行其他巧妙的技巧来提高吞吐量。如果只是创建一次性使用的缓冲区，则差异不大。另一方面，如果要在高性能方案中重复使用缓冲区，则最好分配直接缓冲区并重用它们。
直接缓冲区是 I/O 的最佳选择，但它们的创建成本可能比非直接字节缓冲区高。直接缓冲区使用的内存是通过调用特定于操作系统的本机代码来分配的，绕过标准 JVM 堆。设置和拆除直接缓冲区可能比堆驻留缓冲区昂贵得多，具体取决于主机操作系统和 JVM 实现。直接缓冲区的内存存储区域不受垃圾回收的影响，因为它们位于标准 JVM 堆之外。
使用直接缓冲区与非直接缓冲区的性能权衡可能因 JVM、操作系统和代码设计而异。通过在堆外部分配内存，可能会使应用程序受到 JVM 无法察觉的其他力的影响。在使用其他活动部件时，请确保您正在达到预期的效果。我推荐旧的软件格言：首先让它工作，然后让它变得快速。不要太担心预先优化;首先关注正确性。JVM 实现可能能够执行缓冲区缓存或其他优化，这些优化将为您提供所需的性能，而无需您付出大量不必要的努力。
没有理由期望直接缓冲区在 jvm 内部访问速度更快。当您将它们传递给本机代码时，它们的优势就来了 - 例如，各种通道后面的代码。
