每当使用new / malloc时，OS都会创建一个新的（或重用）堆内存段，与页面大小对齐并将其返回给调用进程。所有这些分配将构成进程的虚拟内存。在32位计算中，任何进程最多只能扩展到4 GB。堆分配越高，进程内存的增加率就越高。虽然有很多可用的内存管理/内存池，但所有这些实用程序最终都会在创建堆并有效地重用它时再次出现。
另一方面，mmap（内存映射）提供了将文件可视化为内存流的能力，并使程序能够直接在文件上使用指针操作。但在这里，mmap实际上是在进程空间中分配地址范围。因此，如果我们对3GB大小的3GB文件进行mmap并获取该进程的pmap，则可以看到该进程消耗的总内存大于＆gt; = 3GB。
我的问题是，是否有可能有一个基于文件的内存池[就像mmaping一个文件]，但是，不构成进程内存空间。我想象一个类似于内存数据库的东西，它由一个文件支持，它的读/写速度非常快，它支持指针操作[即获取指向记录的指针并存储任何内容，就好像我们使用new / malloc一样]，可以在磁盘上增长，而不会触及进程虚拟4GB限制。
有可能吗？如果是这样，我开始工作有什么指示。 我不是要求现成的解决方案/链接，而是要从概念上理解如何实现它。
答案 0 :(得分：1)
通常可能但非常复杂。如果您想访问文件的不同3Gb段，则必须重新映射，这可能会在分散访问的情况下破坏性能。指针只会变得更难以处理，因为重新调整数据会使地址变得相同。 我看过你可能感兴趣的STXXL项目;或者它可能不会。我从未使用它，所以我不能给你任何其他建议。
答案 1 :(得分：0)
您正在寻找的，原则上是内存支持的文件缓存。在数据库实现中存在许多这样的事情（其中整个数据库比机器的内存大，并且应用程序开发人员可能希望留下一些内存用于应用程序的东西）。这将涉及具有某种间接性 - 索引，散列或某些内容，以指示您要访问的文件的哪个区域，并使用该间接来确定内存是在内存中还是在磁盘上。您实际上必须复制操作系统和处理器的虚拟内存处理，通过使表指示物理内存中“虚拟堆”的位置，以及它是否存在于物理内存中，读取它（如果缓存已满，删除了一些 - 如果已写入，则再次写回来）。
然而，在当今世界，您最有可能拥有一台能够进行64位寻址的计算机，因此，将应用程序重新编译为64位应用程序会更容易，使用mmap或类似于访问大内存。在这种情况下，即使RAM不足，您也可以通过虚拟内存系统访问文件的内存，它可以处理磁盘和RAM（物理内存）之间的所有映射。