在windows操作系统中进程通信的方式都有哪些

Posted 2023-04-18

# 管道( pipe )：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
# 有名管道 (named pipe) ： 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。
# 信号量( semophore ) ： 信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
# 消息队列( message queue ) ： 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
# 信号 ( sinal ) ： 信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。
# 共享内存( shared memory ) ：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
# 套接字( socket ) ： 套解口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。 参考技术A 说详细一点好么 ？你这样让我们如何去回答你想要问的问题.

Java 进程通信都有哪些选择？

【中文标题】Java 进程通信都有哪些选择？

【英文标题】：Which options do I have for Java process communication?Java 进程通信有哪些选择？

【发布时间】：2010-03-10 14:18:42

【问题描述】：

我们在这种形式的代码中占有一席之地：

void processParam(Object param)

   wrapperForComplexNativeObject result = jniCallWhichMayCrash(param);
   processResult(result);

processParam - 使用许多不同参数调用的方法。

jniCallWhichMayCrash - 一种本机方法，旨在对其参数进行一些复杂的处理并创建一些复杂的对象。在某些情况下它可能会崩溃。

wrapperForComplexNativeObject - SWIG 生成的包装器类型

processResult - 一种用纯 Java 编写的方法，它通过创建几种对象（我不是指类，可能是层次结构）来处理它的参数： 1 - 一些相互引用的非唯一对象（来自同一层次结构），这些对象可以具有通过调用具有不同参数值的 processParam() 方法创建的副本。由于保留所有重复项的成本很高，因此有必要缓存它们。 2 - 一些相互引用的独特对象（来自同一层次结构）和一些第一种对象。

在为某个集合中的每个参数执行 processParam 之后，在 processResult 中创建的数据将被一起处理。问题实际上是 jniCallWhichMayCrash 方法可能会使整个 JVM 崩溃，这将是非常糟糕的。崩溃的原因可能是它可能发生在一个参数值而不是另一个参数值上。我们决定最好忽略 JVM 内部的崩溃，并在发生此类崩溃时跳过一些数据块。为了做到这一点，我们应该在单独的进程中运行 processParam 函数，并以某种方式将结果 （HOW？HOW？！这是一个问题） 传递给主进程，如果发生任何崩溃，我们只会丢失部分数据（没关系）而不会丢失其他所有数据。所以目前主要的问题是不同进程之间的传输实现。我有哪些选择？我可以考虑通过流进行二进制数据的序列化和传输，但是由于对象的复杂性，序列化可能不是很快。也许我还有其他一些实施方式？

【参考方案1】：

让我们假设这些进程在同一台机器上。您的选择包括：

使用 Process.exec() 为每个请求启动一个新进程，将参数对象作为命令行参数或通过进程标准输入传递并从 thr 进程标准输出读取结果。该进程在单个请求完成后退出。

使用 Process.exec() 启动长时间运行的进程，使用 Processes 标准输入/输出发送请求和回复。流程实例处理多个请求。

使用“命名管道”向现有的本地（或可能是远程）进程发送请求/回复。

使用原始 TCP/IP 套接字或 Unix 域套接字向现有的本地（或可能是远程）进程发送请求/回复。

对于以上每一个，您都需要设计自己的请求格式，并在双方处理参数/结果的编码和解码。

将流程实现为 Web 服务，并使用 JSON 或 XML（或其他）对参数和结果进行编码。根据您选择的编码方案，将有现有的库处理编码/解码和（可能）映射到 Java 类型。

SOAP / WSDL - 使用这些，您通常会在更高的抽象级别设计应用程序协议，框架库负责编码/解码、调度请求等。

CORBA 或类似 ICE 的等价物。这些选项类似于 SOAP / WSDL，但使用更高效的线路表示等。

消息队列系统，如 MQ 系列。

请注意，最后四个通常用于客户端和服务器位于不同机器上的系统中，但当客户端和服务器位于同一位置时，它们的工作效果一样好（而且可能更快）。

---

我或许应该补充一点，另一种方法是摆脱有问题的 JNI 代码。要么用纯 Java 代码替换它，要么将其作为外部命令或服务运行，而无需围绕它的 Java 包装器。

【参考方案2】：

您是否考虑过使用受网络启发的方法？在您的情况下，通常情况下，Web 服务可能/将是一个多样化的解决方案：

REST 调用 WSDL 和所有重量级机制 即使是基于 http 的 XML-RPC，例如 Spring remoting 或 JSPF net export 使用的那种，也能激发您的灵感

【讨论】：

我担心使用网络服务会有点过头了。我也认为它不会有很好的性能，XMLs 不是我们的选择。

你能详细说明原因吗？实现一个接收 4kb XML 块的网络服务器不会让你的机器爆炸，我认为......因为像 dns-323 和其他等效模型这样的家庭 nas 支持使用 lighttpd，即使你的 iPhone 有一个芯片也会认为可以忽略不计.

好吧，你能想象设计一个编译器，其中一个模块会将一些数据（例如整个源文件或文件集的中间表示）作为大量的小 XML 传递，这有多好？我认为这根本不会好，我们的应用程序是同类。

【参考方案3】：

如果您可以隔离流程的职责，即 P1 是数据的生产者，而 P2 是消费者，那么最可靠的答案是使用文件来传达您的数据。序列化/反序列化涉及开销（读取 CPU 周期），但是您的进程不会崩溃，并且非常容易调试/同步。