java - 读写套接字和文件只使用 native 内存？

Question

最近我一直在研究 JVM 的细节，并遇到了一个术语 Direct Memory。来自 @Peter Lawrey 的回答捕获了我的注意力。

All system calls such as reading and writing sockets and files only use native memory. They can't use the heap.

---

我的问题

1. 这是真的吗？
2. 我可以在哪里整理这份声明？
3. 这是否意味着 NIO 中的任何调用，我就直接使用Direct Memory？

Answer 1

套接字传输(和系统调用)中的 native 内存与堆内存

进出套接字的数据传输只能使用 native (非堆)内存是不正确的。它完全取决于 JVM 实现，甚至可能在同一实现中不时发生变化。

事实上，编写直接使用堆内存并避免复制的 JNI 函数是相当容易的。 JNI API 提供了对 Java 堆中数据进行零拷贝访问的方法:

• GetStringCritical, ReleaseStringCritical
• GetPrimitiveArrayCritical, ReleasePrimitiveArrayCritical

第二个在处理字节数组时非常有用。

与垃圾回收的交互

这些 JNI 函数 may prevent garbage collection from making progress .通常，制作副本更有益。在进行阻塞系统调用时尤其如此(例如在不确定内核是否有缓冲数据要返回时从 TCP 套接字读取)。在其他情况下，可以以较小的部分增量处理数组，以避免长时间停顿和副本的需要。

由于这些挑战，OpenJDK 11 中的当前实现不会尝试与堆分配的(非直接)字节缓冲区之间进行零拷贝传输，即使在内核中不会发生阻塞的情况下也是如此无限制延迟对垃圾收集没有影响。

使用直接字节缓冲区的禁忌症

在 NIO 中使用直接字节缓冲区有不同的问题:这些缓冲区需要某种终结。因此，垃圾收集器无法像处理其他对象那样高效(及时)地处理它们。通常，只有在长期使用直接字节缓冲区(例如，与使用它们的 channel 一起分配)时才谨慎使用直接字节缓冲区。对于临时缓冲区，数组支持的缓冲区(或普通数组)在大多数情况下都更胜一筹。

OpenJDK 实现通过将直接缓冲区与当前线程相关联来避免此问题，透明地将它们用于 channel 上的传输，然后将它们返回到每线程缓存以供将来使用。这样，就不会不断地分配和丢弃直接缓冲区。

较旧的 OpenJDK 版本

上面提到的临界区数组访问函数可以追溯到 Java 1.2。各个虚拟机和垃圾收集实现是否仍然制作临时副本当然是不确定的(接口(interface)经过精心设计，避免复制不是实现它们所必需的)。在 OpenJDK 8 的 Hotspot 中，这些 JNI 函数从不制作副本，但正如 Aleksey Shipilёv 的文章中所解释的，对垃圾收集的影响因收集器而异。