java - 内存映射文件 : pros and cons?

Question

我需要在同一台机器(两个不同的 JVM)上运行的两个 Java 应用程序之间共享数据。我确切地说要共享的数据很大(大约 7 GB)。应用程序必须非常快速地访问数据，因为它们必须以非常高的速度回答传入的查询。我不希望应用程序为每个应用程序保存一份数据副本。

我看到一种选择是使用内存映射文件。应用程序 A 从某处(假设是数据库)获取数据并将其存储在文件中。然后应用程序 B 可以使用 java.nio 访问这些文件。我不知道内存映射文件究竟是如何工作的，我只知道数据存储在一个文件中，并且这个文件(或其中的一部分)被映射到内存的一个区域(虚拟内存？)。因此，这两个应用程序可以读写内存中的数据，并且更改会自动(我猜？)提交到文件中。我也不知道是否存在将文件完全映射到内存中的最大大小。

我的第一个问题是，在这种情况下，两个应用程序共享数据的不同可能性有哪些(我的意思是考虑到数据量非常大，并且对这些数据的访问必须非常快)？我明确表示这个问题与内存映射 I/O 无关，只是想知道解决相同问题的其他方法是什么。

我的第二个问题是使用内存映射文件的优缺点是什么？

谢谢

Answer 1

My first question is what are the different possibilities for two applications to share data?

正如 S.Lott 指出的那样，有很多机制:

• 操作系统级 message queues
• 操作系统级 POSIX shared memory segments (进程死亡后仍然存在)
• 操作系统级 memory mappings (可以是匿名的或文件支持的)
• 操作系统级 anonymous pipes (单向)
• 操作系统级 named pipes (单向)
• 操作系统级 sockets (双向)——是否AF_UNIX或 AF_INET或 AF_INET6
• 操作系统级 shared global memory -- 适用于多线程程序
• 在文件中存储数据
• 应用级 message queues
• 应用级 blackboard-style tuplespaces
• 应用级 key/value stores
• 应用级 remote procedure call frameworks -- many are available
• 应用级 web-based frameworks

My second question is what are the pros and cons of using memory-mapped files?

优点:

• 非常快——取决于您访问数据的方式，可能是 zero-copy机制可用于直接对数据进行操作，而不会造成速度损失。必须注意以一致的方式更新对象。
• 应该非常便携——在 Unix 系统上可用大约 25 年(或多或少)，and apparently Windows has mechanisms too .

缺点:

• 单系统共享。如果你想在多台机器上分发你的应用程序，共享内存不是一个好的选择。 Distributed shared memory systems are available ，但它们非常像是我思维方式的错误界面。
• 即使在单个系统上，如果内存位于单个 NUMA node 上但需要由来自多个节点的处理器访问，与为每个节点提供自己的内存段相比，节点间请求可能会显着减慢处理速度。
• 您不能只存储指针——所有内容都必须存储为基地址的偏移量，因为内存可能映射到不同进程的不同位置。我不知道这对 Java 对象意味着什么，尽管可能有人聪明地尽力使它对 Java 程序员透明。如果您不使用他们提供的机制，那么您可能必须自己完成这项工作。 (在 Java 中没有实际的指针，也许这不是很麻烦。)
• 事实证明，始终如一地更新对象非常困难。路过immutable objects相反，在消息传递系统中，通常会导致并发错误较少的程序。 (Erlang 中的并发编程感觉非常自然和直接。更多imperative languages 中的并发编程往往会引入一大堆新的并发控制:semaphores、mutexes、spinlocks、monitors)。