2

我有一个 Java 8 应用程序，它通过网络接收消息并使用 Java NIO MappedByteBuffer 写入多个内存映射文件。我有一个阅读器，它可以按顺序从这些文件中同时读取消息，并使用 MappedByteBuffer 再次删除读取的文件。一切都很顺利，直到我写入和读取了大约 246 GB 的数据并且我的应用程序因以下原因而崩溃

[thread 139611281577728 also had an error][thread 139611278419712 also had an error][thread 139611282630400 also had an error][thread 139611277367040 also had an error][thread 139611283683072 also had an error][thread 139611279472384 also had an error]





[thread 139611280525056 also had an error]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f02d10526de, pid=44460, tid=0x00007ef9c9088700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.101-b13 mixed mode linux-amd64 )
# Problematic frame:
# v  ~StubRoutines::jint_disjoint_arraycopy
#
# Core dump written. Default location: /home/user/core or core.44460
#
# An error report file with more information is saved as:
# /home/user/hs_err_pid44460.log

这hs_err_pid44460.log是空的，核心转储core.44460的大小约为 246 GB，并且充满了我正在尝试编写的消息。

我运行的最大堆大小为 32 GB。根据 JConsole，我用完了Free Physical Memory然后崩溃。 JConsole 屏幕截图

为什么我的 RAM 用完了？我是否忘记关闭某些文件句柄/没有正确关闭我的 MMapped 文件？

4

3 回答 3

1

即使您的程序在使用 MappedByteBuffers 时可能确实是正确的，但请注意，在高速分配速度下，您可能会由于不及时释放所述缓冲区而引发现象，这最终是 JVM 的责任，并且应该仅在缓冲区的垃圾收集期间发生. 简而言之，释放缓冲区最终会成功，但何时会发生应该很难预测。

但是，您可以使用 JVM 的 Cleaner 功能（类）强制释放（“清理”）分配给缓冲区的内存sun.misc.Cleaner。请参考这个 SO question以获得一些方向，但是，长话短说，您应该尽早调用Cleaner.clean()一次性缓冲区，以减少内存分配数字并有效地支持您的用例。

于 2016-08-29T12:17:21.840 回答
0

您必须查看进程的虚拟内存占用或内存映射，以确定直接缓冲区是否可能是罪魁祸首。

如果它确实由于映射或直接缓冲区而崩溃，那么您要么泄漏它们（通过内存分析器运行堆转储可以识别这些），要么 GC 运行太少而无法释放它们。

于 2016-08-28T19:31:41.637 回答
0

您可能还会发现更积极的垃圾收集会有所帮助。

也可能想尝试在 J7 中引入的这个选项： -XX:+UseG1GC -XX:ParallelGCThreads=4 这将允许 4 个线程并行 GC

有许多关于更多地调整垃圾收集器的好文章，我发现其中一篇很有用（https://blogs.oracle.com/java-platform-group/entry/g1_from_garbage_collector_to）

希望这可以帮助。

于 2016-09-15T09:40:56.690 回答