java - 为什么我使用 Java MappedByteBuffers 得到 "Not enough storage is available to process this command"？

Question

我有一个非常大的 double 组，我正在使用基于磁盘的文件和 MappedByteBuffers 的分页列表来处理，请参阅 this question更多背景信息。我在使用 Java 1.5 的 Windows XP 上运行。

这是我的代码的关键部分，它针对文件分配缓冲区...

try 
{
 // create a random access file and size it so it can hold all our data = the extent x the size of a double
 f = new File(_base_filename);
 _filename = f.getAbsolutePath();
 _ioFile = new RandomAccessFile(f, "rw");
 _ioFile.setLength(_extent * BLOCK_SIZE);
    _ioChannel = _ioFile.getChannel();

    // make enough MappedByteBuffers to handle the whole lot
 _pagesize = bytes_extent;
 long pages = 1;
 long diff = 0;
 while (_pagesize > MAX_PAGE_SIZE)
 {
  _pagesize  /= PAGE_DIVISION;
  pages *= PAGE_DIVISION;

  // make sure we are at double boundaries.  We cannot have a double spanning pages
  diff = _pagesize  % BLOCK_SIZE;
  if (diff != 0) _pagesize  -= diff;

 }

 // what is the difference between the total bytes associated with all the pages and the
 // total overall bytes?  There is a good chance we'll have a few left over because of the
 // rounding down that happens when the page size is halved
 diff = bytes_extent - (_pagesize  * pages);
 if (diff > 0)
 {
  // check whether adding on the remainder to the last page will tip it over the max size
  // if not then we just need to allocate the remainder to the final page
  if (_pagesize  + diff > MAX_PAGE_SIZE)
  {
   // need one more page
   pages++;
  }
 }

 // make the byte buffers and put them on the list
 int size = (int) _pagesize ;  // safe cast because of the loop which drops maxsize below Integer.MAX_INT
 int offset = 0;
 for (int page = 0; page < pages; page++)
 {
  offset = (int) (page * _pagesize );

  // the last page should be just big enough to accommodate any left over odd bytes
  if ((bytes_extent - offset) < _pagesize )
  {
   size = (int) (bytes_extent - offset);
  }

  // map the buffer to the right place 
     MappedByteBuffer buf = _ioChannel.map(FileChannel.MapMode.READ_WRITE, offset, size);

     // stick the buffer on the list
     _bufs.add(buf);
 }

 Controller.g_Logger.info("Created memory map file :" + _filename);
 Controller.g_Logger.info("Using " + _bufs.size() + " MappedByteBuffers");
    _ioChannel.close();
    _ioFile.close(); 
} 
catch (Exception e) 
{
 Controller.g_Logger.error("Error opening memory map file: " + _base_filename);
 Controller.g_Logger.error("Error creating memory map file: " + e.getMessage());
 e.printStackTrace();
 Clear();
    if (_ioChannel != null) _ioChannel.close();
    if (_ioFile != null) _ioFile.close();
 if (f != null) f.delete();
 throw e;
} 

分配第二个或第三个缓冲区后出现标题中提到的错误。

我认为这与可用的连续内存有关，因此尝试了不同大小和页数的情况，但总体上没有任何好处。

“没有足够的存储空间来处理此命令” 到底是什么意思，如果有的话，我能做些什么？

我认为 MappedByteBuffers 的重点在于能够处理比您可以在堆上容纳的结构更大的结构，并将它们视为内存中的结构。

有什么线索吗？

编辑:

为了回应下面的回答 (@adsk)，我更改了我的代码，因此我在任何时候都不会有超过一个 Activity 的 MappedByteBuffer。当我引用当前未映射的文件区域时，我会丢弃现有 map 并创建一个新 map 。大约 3 次 map 操作后，我仍然遇到相同的错误。

引用的 GC 不收集 MappedByteBuffers 的错误在 JDK 1.5 中似乎仍然是一个问题。

Answer 1

I thought the point of MappedByteBuffers was the ability to be able to handle structures larger than you could fit on the heap, and treat them as if they were in memory.

没有。这个想法是/曾经允许您处理超过 2**31 个 double ...假设您有足够的内存，并且使用的是 64 位 JVM。

(我假设这是 this question 的后续问题。)

编辑:显然，需要更多解释。

有许多限制在起作用。

1. Java 有一个基本限制，即数组的length 属性，数组索引的类型为int。这一点，再加上 int 是有符号的并且数组不能有负数的事实意味着最大可能的数组可以有 2**31 元素。此限制适用于 32 位和 64 位 JVM。它是 Java 语言的基本组成部分……例如 char 值从 0 到 65535。

2. 使用 32 位 JVM 为 JVM 可寻址的字节数设置了一个(理论上的)上限 2**32。这包括整个堆、您的代码和您使用的库类、JVM 的 native 代码核心、用于映射缓冲区的内存……一切。 (事实上​​ ，根据您的平台，如果地址空间，操作系统可能给您的地址空间远远少于 2**32 字节。)

3. 您在 java 命令行上提供的参数决定了 JVM 允许您的应用程序使用多少堆内存。映射到使用 MappedByteBuffer 对象的内存不计入此。

4. 操作系统为您提供的内存量取决于(在 Linux/UNIX 上)配置的交换空间总量、“进程”限制等。类似的限制可能适用于 Windows。当然，如果主机操作系统支持 64 位，并且您使用的是支持 64 位的硬件，那么您只能运行 64 位 JVM。 (如果你有 Pentium，那你就很倒霉了。)

5. 最后，系统中的物理内存量开始发挥作用。理论上，您可以要求您的 JVM 使用比您机器的物理内存大很多倍的堆等。实际上，这是一个坏主意。如果您过度分配虚拟内存，您的系统将崩溃，应用程序性能将下降。

要点是:

• 如果您使用 32 位 JVM，您的可寻址内存可能被限制在 2**31 和 2**32 字节之间。这足以容纳 2**29 和 2**30 之间的 MAXIMUM 双倍空间，无论您使用数组还是映射缓冲区。

• 如果您使用 64 位 JVM，您可以表示一个 2**31 double 组。映射缓冲区的理论限制是 2**63 字节或 2**61 的两倍，但实际限制大致是您机器的物理内存量。