8

在我的应用程序中，有一个进程将数据写入文件，然后响应接收请求，将通过网络将（部分）数据发送到请求进程。这个问题的基础是看当两个进程碰巧在同一个主机上时，我们是否可以加快通信速度。（在我的例子中，流程是 Java，但我认为这个讨论可以更广泛地应用。）

有一些项目使用 Java 的 FileChannel.map() 返回的 MappedByteBuffers 作为在同一主机上的 JVM 之间共享内存 IPC 的一种方式（请参阅 Chronicle Queue、Aeron IPC 等）。

加速同一主机通信的一种方法是让我的应用程序使用其中一种技术来为同一主机通信提供请求-响应路径，或者结合现有的写入数据文件的机制，或者通过提供通信和写入文件的统一方式。

另一种方法是允许请求进程直接访问数据文件。

我倾向于支持第二种方法——假设它是正确的——因为它更容易实现，并且似乎比为每个请求复制/传输数据副本更有效（假设我们没有替换现有的写入机制到文件）。

本质上，我想了解当两个进程可以访问同一个文件并使用它进行通信时究竟会发生什么，特别是 Java (1.8) 和 Linux (3.10)。

据我了解，如果两个进程同时打开同一个文件，它们之间的“通信”基本上将通过“共享内存”。

请注意，此问题与是否使用 MappedByteBuffer 的性能影响无关 - 与读取和写入文件相比，使用映射缓冲区以及减少复制和系统调用似乎很有可能会减少开销，但是可能需要对应用程序进行重大更改。

以下是我的理解：

  1. 当 Linux 从磁盘加载文件时，它会将该文件的内容复制到内存中的页面。该内存区域称为页面缓存。据我所知，无论使用哪种 Java 方法（FileInputStream.read()、RandomAccessFile.read()、FileChannel.read()、FileChannel.map()）或本机方法来读取文件，它都会执行此操作（观察“免费”并监控“缓存”值）。
  2. 如果另一个进程尝试加载相同的文件（当它仍然驻留在缓存中时），内核会检测到这一点并且不需要重新加载文件。如果页面缓存已满，页面将被逐出——脏页面被写回磁盘。（如果有明确的磁盘刷新，页面也会被写回，并且定期使用内核线程）。
  3. 缓存中已经有一个（大）文件可以显着提高性能，这比基于我们使用哪些 Java 方法打开/读取该文件的差异要大得多。
  4. 如果使用 mmap 系统调用 (C) 或通过 FileChannel.map() (Java) 加载文件，则基本上文件的页面（在缓存中）被直接加载到进程的地址空间中。使用其他方法打开文件，将文件加载到不在进程地址空间中的页面中，然后读取/写入该文件的各种方法将一些字节从/到这些页面复制到进程地址空间中的缓冲区中. 避免该副本有明显的性能优势，但我的问题与性能无关。

所以总而言之，如果我理解正确的话——虽然映射提供了性能优势，但它似乎并没有提供任何我们还没有从 Linux 和页面缓存的性质中获得的“共享内存”功能。

所以，请让我知道我的理解在哪里。

谢谢。

4

3 回答 3

3

我的问题是，在 Java (1.8) 和 Linux (3.10) 上，MappedByteBuffers 是否真的需要实现共享内存 IPC，或者对公共文件的任何访问都提供相同的功能？

这取决于您为什么要实现共享内存 IPC。

不用共享内存就可以清楚地实现IPC；例如通过套接字。所以，如果你出于性能原因不这样做，那么根本就没有必要进行共享内存 IPC！

因此，性能必须是任何讨论的根源。

通过 Java 经典 io 或 nio API 使用文件访问不提供共享内存功能或性能。

常规文件 I/O 或套接字 I/O 与共享内存 IPC 之间的主要区别在于前者要求应用程序显式地进行系统调用来发送和接收消息read。write这需要额外的系统调用，并且需要内核复制数据。此外，如果有多个线程，您要么需要每个线程对之间的单独“通道”，要么需要在共享通道上多路复用多个“对话”。后者可能导致共享通道成为并发瓶颈。

请注意，这些开销与 Linux 页面缓存正交。

相比之下，使用共享内存实现 IPC，没有read和write系统调用，也没有额外的复制步骤。每个“通道”可以简单地使用映射缓冲区的单独区域。一个进程中的线程将数据写入共享内存，并且几乎立即对第二个进程可见。

需要注意的是，进程需要 1) 同步，以及 2) 实现内存屏障以确保读取器不会看到陈旧的数据。但是这些都可以在没有系统调用的情况下实现。

在清理过程中，使用内存映射文件的共享内存 IPC >><< 比使用传统文件或套接字快，这就是人们这样做的原因。

您还隐含地询问是否可以在没有内存映射文件的情况下实现共享内存 IPC。

  • 一种实用的方法是为存在于仅内存文件系统中的文件创建内存映射文件；例如 Linux 中的“tmpfs”。

    从技术上讲，这仍然是一个内存映射文件。但是，您不会产生将数据刷新到磁盘的开销，并且避免了私有 IPC 数据最终在磁盘上的潜在安全问题。

  • 理论上，您可以通过执行以下操作在两个进程之间实现共享段：

    • 在父进程中，使用 mmap 创建一个带有MAP_ANONYMOUS | MAP_SHARED.
    • 分叉子进程。这些最终将全部与彼此和父进程共享段。

    但是，为 Java 进程实现这一点将是……具有挑战性的。AFAIK，Java 不支持这一点。

参考：

于 2020-05-31T04:17:33.107 回答
3

本质上，我试图了解当两个进程同时打开同一个文件时会发生什么，以及是否可以使用它来安全、高效地提供进程之间的通信。

如果您使用read和write操作使用常规文件（即不是内存映射它们），那么这两个进程不共享任何内存。

  • Buffer与文件关联 的 Java 对象中的用户空间内存不跨地址空间共享。
  • 当进行write系统调用时，数据从一个进程地址空间中的页面复制到内核空间中的页面。（这些可能是页面缓存中的页面。这是特定于操作系统的。）
  • 当进行read系统调用时，数据会从内核空间中的页面复制到读取进程地址空间中的页面。

必须这样做。如果操作系统在后台共享与读写器相关的页面处理缓冲区，那么这将是一个安全/信息泄漏漏洞：

  • 读者将能够看到作者地址空间中尚未通过 写入的数据write(...)，而且可能永远不会。
  • 写入器将能够看到读取器（假设地）写入其读取缓冲区的数据。
  • 巧妙地使用内存保护是不可能解决这个问题的，因为内存保护的粒度是一个页面，而不是read(...)一个write(...)字节的粒度。

当然：您可以安全地使用读写文件在两个进程之间传输数据。但是你需要定义一个协议，让读者知道作者写了多少数据。并且读者知道作者何时写了一些东西可能需要轮询；例如查看文件是否已被修改。

如果您仅从通信“通道”中的数据复制来看这一点

  • 使用内存映射文件，您可以将数据从应用程序堆对象复制（序列化）到映射缓冲区，然后再从映射缓冲区复制（反序列化）到应用程序堆对象。

  • 对于普通文件，有两个额外的副本：1）从写入进程（非映射）缓冲区到内核空间页面（例如在页面缓存中），2）从内核空间页面到读取进程（非映射）缓冲区.

下面的文章解释了传统的读/写和内存映射发生了什么。（它是在复制文件和“零复制”的情况下，但你可以忽略它。）

参考：

于 2020-06-02T01:21:22.560 回答
0

值得一提的三点：性能、并发更改、内存利用率。

您的评估是正确的，即基于 MMAP 通常会比基于文件的 IO 提供性能优势。特别是，如果代码在文件的任意点执行大量小 IO，则性能优势非常显着。

考虑更改第 N 个字节：使用 mmapbuffer[N] = buffer[N] + 1和基于文件的访问，您需要（至少）4 个系统调用 + 错误检查：

   seek() + error check
   read() + error check
   update value
   seek() + error check
   write + error check

确实，实际 IO（到磁盘）的数量很可能是相同的。

第二点值得注意的是并发访问。使用基于文件的 IO，您必须担心潜在的并发访问。您将需要发出显式锁定（在读取之前）和解锁（在写入之后），以防止两个进程同时错误地访问该值。使用共享内存，原子操作可以消除对额外锁的需要。

第三点是实际内存使用情况。对于共享对象的大小很大的情况，使用共享内存可以允许大量进程访问数据而无需分配额外的内存。如果系统受内存限制，或者系统需要提供实时性能，这可能是访问数据的唯一方法。

于 2020-05-29T08:35:55.497 回答