问题标签 [off-heap]

我知道堆栈和堆内存之间的区别，但是在许多博客中我遇到了这个词off-heap记忆。我浏览了许多博客和 youtube 视频，以了解堆外内存和堆栈内存之间是否存在任何关系？根据这个问题的通俗回答，我可以理解，堆外内存是指由 EHCache 管理且不受垃圾回收的存储对象。这个定义是完美的，但我的问题是，堆外内存是否与堆栈内存相同，或者它们一起是内存管理中的不同实体？

编辑：如果它们不一样，有人可以用一些基本解释详细解释是什么让它们不同。我对java内存管理很陌生。

有人可以解释堆上内存和堆外内存之间的区别吗？堆外内​​存是否显示在 JVM 内存大小上？堆外都是指针吗？

我了解堆外存储有助于避免长时间的 GC 暂停，但我想知道 java 在堆上存储时如何序列化对象以及在堆外存储时如何 ignite 序列化？就像运行 GC 以释放空间一样，关闭时会发生什么-heap 用于释放空间，与 GC 相比如何？堆外票价如何对抗堆存储？

我们正在尝试一个 POC 来评估 ignite 和 hazelcast，ignite 提供堆外存储，所以想了解它的细节来得出结论。

我想使用 mapDb 明智地存储 List 对象语法，不会引发任何错误，但在获取地图数据后获取类强制转换异常。但我确实在 Eclipse 中看到了以下警告：此行的多个标记

• 类型安全：HTreeMap 类型的表达式需要未经检查的
  转换才能符合 ConcurrentMap>。
• 类型安全：GroupSerializer 类型的表达式需要未经检查的
  转换才能符合 Serializer。
• 类型安全：DB 类型的泛型方法 hashMap(String, Serializer, Serializer) 的未经检查的调用 hashMap(String, GroupSerializer, GroupSerializer)。

下面是代码。

不要在我做错的地方使用，您的输入将很有价值

我有一个 JVM，它报告提交的堆内存大约为 8GB（其他部分应该在此之上）。但我的操作系统显示内存使用量约为 5GB。我知道由于非堆、元空间等原因，内存使用量可能会超过提交的内存，但是使用量怎么可能低于 jvm 报告的呢？

free 的输出显示内存使用量为 5.5GB

本机内存跟踪器 (NMT) 的输出显示保留内存约为 11 GB

操作系统 - Debian 9

爪哇 -

我已经阅读了一些很棒的答案，比如这个很好地解释了 NMT 的答案，但它并没有解决这个问题。我想了解这是怎么可能的。

在 Java 中分配堆外内存时（例如通过直接缓冲区或 JNI 本机代码），如果 JVM 使用 -XX:+UseLargePages ，分配的内存是否会由大页面支持？

我们的应用程序通过 nio 的 FileChannel.map() 和 ByteBuffer.allocateDirect() 使用大量 DirectByteBuffer 对象来加载和处理文件（例如 DICOM）。代码用 java 8 编写，但用 java 11.0.3 编译。我们使用 JMC 7.x 和 JxRay（专门显示 DirectByteBuffers 内存）分析了我们的应用程序。JxRay 报告说，即使在应用程序启动时，我们的应用程序也使用了大约 140MB 的大量 DirectByteBuffer（堆外内存），这很不寻常。特别是 JxRay 报告指向持有这个大内存的 jdk.internal.jimage.ImageReader$SharedImageReader 对象。所以我创建了一个小型的 hello world，没有任何对 DirectBuffer 的类/对象的引用，而 JxRay 报告了几乎相同的结果，这让我感到困惑。联系了 JxRay 团队，他们告诉我可能是更新的 JDK 11 jdk。internal.jimage.ImageReader$SharedImageReader 可能已经被初始化并分配了这么大的内存。JxRay 没有在 JDK 1.8 版本上报告这个问题，他们还说堆转储的格式在 JDK 版本（8 和 11）之间没有变化。如果有人遇到此问题或相关知识，我将发布此问题。

谢谢

我有一个 Java 项目，它显示产品环境中的内存泄漏。我们可以使用 'top' 或 'cat /proc/PID/status|grep VmRSS' 看到它的内存越来越大，但它的 JVM 堆仍然处于良好状态，这意味着堆内存由 '- Xmx' 和其他 JVM 选项。我曾使用jmap/dump/jstack我知道的任何其他命令来分析问题所在，但徒劳无功。

最后，我们逐行测试发现了问题所在。这是 JVM JavaScript 引擎中的一个问题。我在这里提取了可以重现问题的代码：

您可以使用以下命令运行它：

java -Xmx 128M -XX:MaxMetaspaceSize=64M -XX:MaxDirectMemorySize=64M -cp js-engine-test.jar com.unionpay.cqp.arch.js.JsEngineMain 2

并通过以下方式监视内存使用情况：

while true; do cat /proc/PID/status|grep VmRSS;sleep 5;done

然后你会看到内存使用量随着时间的推移而增长。

好吧，我的问题是，如果我们不知道问题出在哪里，如何找到问题？以及我们如何通过内存分析或命令工具找到不正确的代码？

我使用pmap并jcmd查看内存被占用的位置，我可以从 jcmd 工具获取一些信息，我知道这是一个堆外问题。但我无法将它与代码连接，所以我找不到我的代码的哪一行不正确。

我是 JVM 中堆外存储的新手，而 ChronicleMap 看起来很适合堆外存储。但我主要关心的是性能。

我确实使用配置运行了简单的测试

并发现以下结果

与并发 HashMap 相比，读取性能相当低。

我已经尝试使用 1024/2048 段，默认膨胀因子，默认 Marshaller。但还是一样的结果。

我只是想利用堆外特性来减少 GC 暂停，并且无意使用持久性事物或复制或使用 JVM 之外的映射。

所以问题是我应该使用 ChronicleMap 还是坚持使用 ConcurrentHashMap？或者在 ChronicleMap 的情况下，我可以使用任何其他配置来提高性能？

提前致谢。

** 使用https://github.com/OpenHFT/Chronicle-Map/blob/master/src/test/java/net/openhft/chronicle/map/perf/MapJLBHTest.java进行基准测试：**

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