堆外内存是 Java/JVM 标准吗？

Question

我正在阅读 HBase 文档并遇到了 Off-heap read path 据我了解，堆外是内存中的一个位置，Java 将字节/对象存储在垃圾收集器范围之外。我还去搜索了一些有助于使用堆外内存的库，并找到了Ehcatche 但是，我找不到任何来自 oracle 或 JVM 的关于他的官方文档。那么这是 JVM 的标准功能还是某种 hack，如果它是用于执行此操作的底层类和技术是什么？

Answer 1

你应该寻找ByteBuffer

直接与非直接缓冲区

字节缓冲区可以是直接的，也可以是非直接的。给定一个直接字节 缓冲区，Java 虚拟机将尽最大努力执行 直接对其进行本地 I/O 操作。也就是说，它将尝试 避免将缓冲区的内容复制到（或从）中间缓冲区 在每次调用基础操作之一之前（或之后） 系统的本机 I/O 操作。

可以通过调用 allocateDirect 创建直接字节缓冲区 这个类的工厂方法。此方法返回的缓冲区 分配和解除分配的成本通常比 非直接缓冲区。 直接缓冲区的内容可能驻留在外部 正常的垃圾收集堆，因此它们对 应用程序的内存占用可能并不明显。它是 因此建议将直接缓冲区主要分配给 受底层系统影响的大型、长寿命缓冲区 本机 I/O 操作。一般来说，最好直接分配 仅当它们在程序中产生可测量的增益时才缓冲 性能。

也可以通过映射文件的区域来创建直接字节缓冲区 直接进入内存。 Java 平台的实现可以 可选地支持从本机创建直接字节缓冲区 通过 JNI 编写代码。如果其中一种缓冲区的实例引用 到不可访问的内存区域，然后尝试访问该区域 区域不会改变缓冲区的内容，并且会导致 在访问时抛出未指定的异常或 稍后。

字节缓冲区是直接的还是非直接的可以由 调用它的 isDirect 方法。提供此方法以便显式 缓冲区管理可以在性能关键代码中完成。

它如何处理直接 ByteBuffers 取决于 JVM 实现，但至少 OpenJDK JVM 是在堆外分配内存。

JEP 383: Foreign-Memory Access API (Second Incubator) 特征是Java 15 中的incubating。此功能将通过提供公共 API 使访问堆外内存成为标准。