Java中共享内存的任何概念
AFAIK，Java中的内存是基于堆的，内存是动态分配给对象的，并且没有共享内存的概念。
如果没有共享内存的概念，那么Java程序之间的通信应该是很耗时的。在 C 中，与其他通信模式相比，通过共享内存进行进程间通信更快。
如果我错了请纠正我。另外，2 个 Java 编程人员相互交谈的最快方式是什么。
AFAIK, memory in Java is based on heap from which the memory is allotted to objects dynamically and there is no concept of shared memory.
If there is no concept of shared memory, then the communication between Java programs should be time consuming. In C where inter-process communication is quicker via shared memory compared to other modes of communication.
Correct me if I'm wrong. Also what is the quickest way for 2 Java progs to talk to each other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
有几种方法：
详细信息 < a href="http://javaforu.blogspot.com/2011/09/offloading-data-from-jvm-heap-little.html" rel="nofollow noreferrer">此处 和 此处提供了一些性能测量。
A few ways:
Details here and here with some performance measurements.
由于没有官方 API 来创建共享内存段，因此您需要借助辅助库/DDL 和 JNI 来使用共享内存让两个 Java 进程相互通信。
实际上，这很少是一个问题，因为 Java 支持线程，因此您可以在同一个 Java VM 中运行两个“程序”。它们将共享同一个堆，因此通信将是即时的。另外，您不会因为共享内存段的问题而出现错误。
Since there is no official API to create a shared memory segment, you need to resort to a helper library/DDL and JNI to use shared memory to have two Java processes talk to each other.
In practice, this is rarely an issue since Java supports threads, so you can have two "programs" run in the same Java VM. Those will share the same heap, so communication will be instantaneous. Plus you can't get errors because of problems with the shared memory segment.
Java Chronicle 值得一看； Chronicle-Queue 和 Chronicle-Map 使用共享内存。
这些是我的一些测试不久前比较了各种堆外和堆内选项。
Java Chronicle is worth looking at; both Chronicle-Queue and Chronicle-Map use shared memory.
These are some tests that I had done a while ago comparing various off-heap and on-heap options.
需要注意的一件事是使用 内存映射文件，使用 Java NIO 的 FileChannel 类或类似类（请参阅 map() 方法）。我们已经非常成功地使用它在同一台机器上的 Java 进程和 C 本机进程之间进行通信（在我们的例子中是单向）。
我承认我不是文件系统专家（幸运的是我们有一个工作人员！）但我们的性能绝对快得惊人——实际上，您将页面缓存的一部分视为文件并读取+写入直接执行，无需系统调用的开销。我不确定保证和一致性——Java中有一些方法可以强制将更改写入文件，这意味着它们（有时？通常？通常？通常？不确定）写入实际的底层文件（有点？非常？极端？） 懒惰，这意味着在某些时候它基本上只是一个共享内存段。
理论上，据我了解，内存映射文件实际上可以由共享内存段支持（我认为它们只是文件句柄），但我不知道在没有 JNI 的情况下在 Java 中执行此操作的方法。
One thing to look at is using memory-mapped files, using Java NIO's FileChannel class or similar (see the map() method). We've used this very successfully to communicate (in our case one-way) between a Java process and a C native one on the same machine.
I'll admit I'm no filesystem expert (luckily we do have one on staff!) but the performance for us is absolutely blazingly fast -- effectively you're treating a section of the page cache as a file and reading + writing to it directly without the overhead of system calls. I'm not sure about the guarantees and coherency -- there are methods in Java to force changes to be written to the file, which implies that they are (sometimes? typically? usually? normally? not sure) written to the actual underlying file (somewhat? very? extremely?) lazily, meaning that some proportion of the time it's basically just a shared memory segment.
In theory, as I understand it, memory-mapped files CAN actually be backed by a shared memory segment (they're just file handles, I think) but I'm not aware of a way to do so in Java without JNI.
共享内存有时很快。有时并非如此——它会损害 CPU 缓存，并且同步通常很痛苦（如果它依赖于互斥体等，可能会造成重大的性能损失）。
Barrelfish 是一个操作系统，它证明随着内核数量的增加，使用消息传递的 IPC 实际上比共享内存更快（在传统的 X86 架构以及更奇特的 NUMA NUCA 上，你可能会猜到它的目标）。
因此，您假设共享内存很快，需要针对您的特定场景和目标硬件进行测试。如今这不是一个通用的合理假设！
Shared memory is sometimes quick. Sometimes its not - it hurts CPU caches and synchronization is often a pain (and should it rely upon mutexes and such, can be a major performance penalty).
Barrelfish is an operating system that demonstrates that IPC using message passing is actually faster than shared memory as the number of cores increases (on conventional X86 architectures as well as the more exotic NUMA NUCA stuff you'd guess it was targeting).
So your assumption that shared memory is fast needs testing for your particular scenario and on your target hardware. Its not a generic sound assumption these days!
我能想到一些类似的技术：
不幸的是，两者都没有共享内存的正确速度，但它们确实处理了并发访问等问题。
There's a couple of comparable technologies I can think of:
Unfortunately neither will have the out right speed of shared memory, but they do deal with the issues of concurrent access, etc.
最简单的方法是让两个进程实例化同一个内存映射文件。实际上，它们将共享相同的堆外内存空间。您可以获取该内存的物理地址并使用sun.misc.Unsafe来写入/读取原语。它通过 putXXXVolatile/getXXXVolatile 方法支持并发。看看 CoralQueue，它可以轻松提供 IPC 以及线程间通信在同一个 JVM 中。
免责声明：我是 CoralQueue 的开发者之一。
The easiest way to do that is to have two processes instantiate the same memory-mapped file. In practice they will be sharing the same off-heap memory space. You can grab the physical address of this memory and use
sun.misc.Unsafeto write/read primitives. It supports concurrency through the putXXXVolatile/getXXXVolatile methods. Take a look on CoralQueue which offers IPC easily as well as inter-thread communication inside the same JVM.Disclaimer: I am one of the developers of CoralQueue.
与 Peter Lawrey 的 Java Chronicle 类似，您可以尝试 Jocket。
它还使用 MappedByteBuffer 但不保留任何数据，旨在用作 Socket / ServerSocket 的直接替代品。
1kB 乒乓球的往返延迟约为半微秒。
Similar to Peter Lawrey's Java Chronicle, you can try Jocket.
It also uses a MappedByteBuffer but does not persist any data and is meant to be used as a drop-in replacement to Socket / ServerSocket.
Roundtrip latency for a 1kB ping-pong is around a half-microsecond.
MappedBus (http://github.com/caplogic/mappedbus) 是我在 github 上添加的一个库它通过消息传递在多个（两个以上）Java 进程/JVM 之间启用 IPC。
传输可以是内存映射文件或共享内存。要将其与共享内存一起使用，只需遵循 github 页面上的示例，但将读者/编写者指向“/dev/shm/”下的文件。
它是开源的，并且其实现在 github 页面上有完整的解释。
MappedBus (http://github.com/caplogic/mappedbus) is a library I've added on github which enable IPC between multiple (more than two) Java processes/JVMs by message passing.
The transport can be either a memory mapped file or shared memory. To use it with shared memory simply follow the examples on the github page but point the readers/writers to a file under "/dev/shm/".
It's open source and the implementation is fully explained on the github page.
Cowan提供的信息是正确的。然而，即使是共享内存也并不总是同时在多个线程（和/或进程）中显得相同。关键的根本原因是Java内存模型（它是建立在硬件内存模型之上的）。请参阅多个线程能否看到对一个线程的写入在 Java 中直接映射 ByteBuffer？ 对此主题进行了非常有用的讨论。
The information provided by Cowan is correct. However, even shared memory won't always appear to be identical in multiple threads (and/or processes) at the same time. The key underlying reason is the Java memory model (which is built on the hardware memory model). See Can multiple threads see writes on a direct mapped ByteBuffer in Java? for a quite useful discussion of the subject.