Java面试题：进程间通信的方式有哪些？线程间通讯方式有哪些？
 
一，进程中的通信方式
 
管道( pipe )：
 管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
有名管道 (namedpipe) ：
 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。
信号量(semophore ) ：
 信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
消息队列( messagequeue ) ：
 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
信号 (sinal ) ：
 信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。
共享内存(shared memory ) ：
 共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
套接字(socket ) ：
 套接口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同设备及其间的进程通信。
 
二，线程中的通讯方式
 
锁机制：包括互斥锁、条件变量、读写锁
 互斥锁提供了以排他方式防止数据结构被并发修改的方法。
 读写锁允许多个线程同时读共享数据，而对写操作是互斥的。
 条件变量可以以原子的方式阻塞进程，直到某个特定条件为真为止。对条件的测试是在互斥锁的保护下进行的。条件变量始终与互斥锁一起使用。
信号量机制(Semaphore)：包括无名线程信号量和命名线程信号量
信号机制(Signal)：类似进程间的信号处理
 线程间的通信目的主要是用于线程同步，所以线程没有像进程通信中的用于数据交换的通信机制。
 
 
原文链接：
 https://blog.csdn.net/qq_38225558/article/details/87118551

 
 
由于内存管理的一些机制，导致两个进程间并不能直接的进行通信 (在独立的用户空间), 因此我们需要利用一些介质来完成两个进程之间的通信。以下是常用的进程间通信方式。
 

  “
  
管道（Pipe）：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系进程间的通信，允许一个进程和另一个与它有共同祖先的进程之间进行通信。（半双工：数据传输指数据可以在一个信号载体的两个方向上传输，但是不能同时传输。）
有名管道（named pipe）： 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。命名管道在文件系统中有对应的文件名。命名管道通过命令 mkfifo 或系统调用 mkfifo 来创建。
信号（Signal）：信号是比较复杂的通信方式，用于通知接受进程有某种事件发生。
消息（Message）队列：消息队列是消息的链接表。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
共享内存：使得多个进程可以访问同一块内存空间，是最快的可用 IPC 形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
内存映射（mapped memory）：内存映射允许任何多个进程间通信，每一个使用该机制的进程通过把一个共享的文件映射到自己的进程地址空间来实现它。
信号量（semaphore）：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
套接口（Socket）：更为一般的进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。可用于不同机器之间的进程间通信。
  ”
 
 
可以把 java 进程理解为 jvm 进程，至于通讯方式处理 Socket 以外 我们还可以用 RPC，Webservice，RMI，JMS 等，当然，JAVA 进程间通信的最基本手段大都也是 Socket。
 
RPC
 
远程过程调用（Remote Procedure Call，缩写为 RPC），是一种用于构建基于 C/S（客户端 / 服务器）的分布式应用程序技术。调用者与被调用者可能在同一台服务器上，也可能在由网络连接的不同服务器上，对于他们来说，网络通信是透明的，就是像调用本地方法一样调用远程方法。
 
RPC 框架要做到的最基本的三件事：
 

  “
  
1、服务端如何确定客户端要调用的函数？
  
在远程调用中，客户端和服务端分别维护一个【ID-> 函数】的对应表， ID 在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个 ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
  
2、如何进行序列化和反序列化？
  
客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
  
3、如何进行网络传输？（选择何种网络协议？）
  
多数 RPC 框架选择 TCP 作为传输协议，也有部分选择 HTTP。如 gRPC 使用 HTTP2。不同的协议各有利弊。TCP 更加高效，而 HTTP 在实际应用中更加的灵活。
  ”
 
 
RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。
 
请注意，RPC 只是一种编程模型而非一种规范或协议，并没有规定你具体要怎样实现，你甚至都可以在你的 RPC 框架里面使用 RMI 来实现数据的传输！！！
 
成熟 RPC 框架：
 
dubbo：阿里开源的一款高性能 RPC 框架，在国内应用广泛，期间停止维护过一段时间，如今又开始了更新，并且捐献给 Apache 基金会。
 
gRPC：Google 开源，具有平台无关性，基于 http/2 协议，支持服务追踪、负载均衡、健康检查等功能；RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。
 
Thrift：可伸缩的跨语言服务的 RPC 软件框架，最早由 Facebook 开发，2007 年捐献给了 Apache 基金会管理，现在是 Apache 的顶级项目；
 
Finagle：Twitter 基于 Netty 开发的支持容错的、协议无关的 RPC 框架，支撑了 Twitter 的核心服务。
 
Web Service
 
WebService 是一种跨编程语言和跨操作系统平台的远程调用技术。Web Service 提供的服务是基于 web 容器的，底层使用 http 协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个 servlet，提供服务给其他应用请求。
 
WebService 采用 HTTP 协议传输数据，采用 XML 格式封装数据（即 XML 中说明调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。XML 是 WebService 平台中表示数据的格式。除了易于建立和易于分析外，XML 主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。但是 XML 虽然解决了数据表达问题，却留下了数据格式类型问题，XSD(XML Schema) 就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。
 
Web Service 的标准
 

  “
  
Web Service 通过标准的 Web 协议向 Web 用户提供有用的功能。多数情况下使用 SOAP 协议。
Web Service 可以非常详细地说明其接口，这使用户能够创建客户端应用程序与它们进行通信。这种说明通常包含在称为 Web 服务说明语言 (WSDL) 文档的 XML 文档中。
Web Service 已经过注册，以便潜在用户能够轻易地找到这些服务，这是通过通用发现、说明和集成 (UDDI) 来完成的。
Web Service 体系结构的主要优点之一是: 允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。
我们将 Web Service 定义为: 通过 SOAP 在 Web 上提供的软件服务，使用 WSDL 文件进行说明，并通过 UDDI 进行注册。
  ”
 
 
SOAP：
 
WebService 通过 HTTP 协议发送请求和接收结果时，发送的请求内容和结果内容都采用 XML 格式封装，并增加了一些特定的 HTTP 消息头，以说明 HTTP 消息的内容格式，这些特定的 HTTP 消息头和 XML 内容格式就是 SOAP 协议。SOAP 提供了标准 RPC 方法来调用 Web Service。
 

  “
  
SOAP 协议 = HTTP 协议 + XML 数据格式
  
Soap 是 XML Web Service 的通信协议。
SOAP 是一种规范，用来定义消息的 XML 格式 。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。
  ”
 
 
WSDL：
 
好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买，商家的做法就是张贴广告海报。WebService 也一样，WebService 客户端要调用一个 WebService 服务，首先要知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，WebService 务器端首先要通过一个 WSDL 文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个 url 地址表示，服务通过什么方式来调用。
 
WSDL(Web Services Description Language) 就是这样一个基于 XML 的语言，用于描述 Web Service 及其函数、参数和返回值。它是 WebService 客户端和服务器端都能理解的标准格式。因为是基于 XML 的，所以 WSDL 既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的 Web service 生成 WSDL 文档，又能导入 WSDL 文档，生成调用相应 WebService 的代理类代码。
 
WSDL 文件保存在 Web 服务器上，通过一个 url 地址就可以访问到它。客户端要调用一个 WebService 服务之前，要知道该服务的 WSDL 文件的地址。WebService 服务提供商可以通过两种方式来暴露它的 WSDL 文件地址：
 
注册到 UDDI 服务器，以便被人查找；
直接告诉给客户端调用者。
 
UDDI：
 
UDDI 目录条目是介绍所提供的业务和服务的 XML 文件。UDDI 目录条目包括三个部分。
 
“白页” 介绍提供服务的公司: 名称、地址、联系方式等等;
 
“黄页” 包括基于标准分类法的行业类别;
 
“绿页” 详细介绍了访问服务的接口，以便用户能够编写应用程序以使用 Web 服务。
 
服务的定义是通过一个称为类型模型 (或 tModel) 的 UDDI 文档来完成的。多数情况下，tModel 包含一个 WSDL 文件，用于说明访问 XMLWeb Service 的 SOAP 接口，但是 tModel 非常灵活，可以说明几乎所有类型的服务。
 
RMI
 
Java RMI，即 远程方法调用 (Remote Method Invocation)，一种用于实现远程过程调用 (RPC) 的 Java API， 能直接传输序列化后的 Java 对象和分布式垃圾收集。它的实现依赖于 Java 虚拟机 (JVM)，因此它仅支持从一个 JVM 到另一个 JVM 的调用。甚至，它可以直接看成 RPC 的 java 版本。
 
RMI 采用 **stubs（占位程序）**和 skeletons 来进行远程对象 (remote object) 的通讯。
 
stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象 stub 来完成的，通过该机制 RMI 就好比它是本地工作，采用 tcp/ip 协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于 JAVA 语言，客户机与服务器紧耦合，缺点是只能使用 java。
 
总结起来，RMI 的工作原理大致可以理解为：
 

  “
  
服务器端提供服务，服务中要暴露可以调用的远程方法，以接口的形式表现，这样在客户端可以通过服务接口来调用远程方法，实现复杂的业务逻辑。在服务器端，首先要对接口中提供的方法实现，以便客户端调用能够完成一定的业务逻辑；接着需要生成 Skeleton，在 Skeleton 中真正地实现了对商业方法的调用，完成了客户请求的调用的过程，将获取到的调用方法的结果通过序列化机制返回给客户端，进行应答。
  
在客户端，通过 Stub 来接收服务器返回的数据（对象），即在这里进行了反序列化，也就是读取网络传输的字节流，进而进行重构。在 Skeleton 和 Stub 中，都对网络通信进行了处理，例如建立套接字，建立网络连接，为实际的业务需要做好准备。
  ”
 
 
JMS
 
JMS 是 Java 的消息服务，JMS 的客户端之间可以通过 JMS 服务进行异步的消息传输。JMS 支持两种消息模型：Point-to-Point（P2P）和 Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。
 

 
作者：图图不糊涂

 
来源链接：
 
https://blog.csdn.net/ljy950914/article/details/100079674
 
 

前言
 
在多线程的世界里，线程与线程之间的交互无处不在，只不过在平时的开发过程中，大多数情况下，我们都在单线程的模式下进行编码，即使有，也直接借助框架自身的机制实现了，其实线程之间的通信在JDK中是一个比较深的问题，比如大家熟知的消息中间件的实现，从某种角度上讲，就借助了多线程通信的思想，下面总结了JDK中常用的几种实现线程通信的方式，提供参考
 
1、synchronized实现方式
 
可能很多小伙伴们会有疑问，synchronized是对共享资源加锁使用的，怎么和线程通信扯在一起呢？这里纠正一个小小的偏见，也是我近期才矫正过来的
 
我们要弄明白的一点是，为什么会存在线程通讯这个问题呢？根据一些技术大牛们的说法就是，多个线程之间需要相互传递一些参数、变量或者是各个线程的执行需要互相依赖各自的结果，比如我们熟知的生产者消费者模式，只有生产者生产出来了东西，消费者才能进行消费啊
 
这里模拟假如有2个线程，需要操作一个共享资源，即修改共享资源的数据，使用synchronized的方式如下：
 
public class SycDemo1 {

    private static Object lock = new Object();

    private static String weather = "sunny";

    public static void main(String[] args) {

        new Thread(()->{
            synchronized (lock){
                System.out.println("

1、传统的线程通信。
 
    在synchronized修饰的同步方法或者修饰的同步代码块中使用Object类提供的wait(),notify()和notifyAll()3个方法进行线程通信。
 
    关于这3个方法的解释：
 
    wait():导致当前线程等待，直到其他线程调用该同步监视器的notify()方法或notifyAll()方法来唤醒该线程。
     notify():唤醒在此同步监视器上等待的单个线程。
     notifyAll():唤醒在此同步监视器上等待的所有线程。
 

 2、使用Condition控制线程通信。
 
    当程序使用Lock对象来保证同步，系统不存在隐式的同步监视器，只能用Condition类来控制线程通信。
 
     await():类似于隐式同步监视器上的wait()方法，导致当前线程等待，直到其他线程调用该Condition的signal()方法或signalAll()方法来唤醒该线程。
     signal():唤醒在此Lock对象上等待的单个线程。如果所有的线程都在该Lock对象上等待，则会选择唤醒其中一个线程。选择是任意性的。
     signalAll():唤醒在此Lock对象上等待的所有线程，只有当前线程放弃对该Lock对象的锁定后，才可以执行被唤醒的线程。
 
 
 
3、使用阻塞队列（BlockingQueue）控制线程通信（也实现了生产者消费者模式）
 
    BlockingQueue提供如下两个支持阻塞的方法：
     put(E e):尝试把E元素放入BlockingQueue中，如果该队列的元素已满，则阻塞该线程。
     take():尝试从BlockingQueue的头部取出元素，如果该队列的元素已空，则阻塞该线程。
     示例代码如下：
     
 package edu.Utils;
  
 import java.util.concurrent.ArrayBlockingQueue;
 import java.util.concurrent.BlockingQueue;
  
 /**
  * Created by hpp on 2017/7/4.
  */
  
 class Producer extends Thread{
     private BlockingQueue<String> bq;
     public Producer(BlockingQueue<String> bq){
         this.bq = bq;
     }
     public void run(){
         String[] strArr = new String[]{
                 "java",
                 "Struts",
                 "Spring"
         };
         for(int i = 0;i<99999;i++){
             System.out.println(getName() + "生产者准备生产集合元素！");
             try{
                 Thread.sleep(1000);
                 bq.put(strArr[i%3]);
             }catch (Exception e){
                 e.printStackTrace();
             }
             System.out.println(getName() + "生成完成：" + bq);
         }
     }
 }
  
 class Consumer extends Thread{
     private BlockingQueue<String> bq;
     public Consumer(BlockingQueue<String> bq){
         this.bq = bq;
     }
     public void run(){
         while(true){
             System.out.println(getName() + "消费者准备消费集合元素！");
             try{
                 Thread.sleep(1000);
                 bq.take();
             }catch (Exception e){
                 e.printStackTrace();
             }
             System.out.println(getName() + "消费完成：" + bq);
         }
     }
 }
  
  
 public class BlockingQueueTest {
  
     public static void main(String[] args){
         //创建一个容量为1的BlockingQueue
         BlockingQueue<String> bq = new ArrayBlockingQueue<String>(1);
         //启动3个生产者线程
         new Producer(bq).start();
         new Producer(bq).start();
         new Producer(bq).start();
         //启动1个消费者线程
         new Consumer(bq).start();
  
     }
  
 }
 运行结果：
 Thread-0生产者准备生产集合元素！
 Thread-1生产者准备生产集合元素！
 Thread-2生产者准备生产集合元素！
 Thread-3消费者准备消费集合元素！
 Thread-0生成完成：[java]
 Thread-0生产者准备生产集合元素！
 Thread-1生成完成：[java]
 Thread-1生产者准备生产集合元素！
 Thread-3消费完成：[java]
 Thread-3消费者准备消费集合元素！
 Thread-2生成完成：[java]
 Thread-2生产者准备生产集合元素！
 Thread-3消费完成：[java]
 Thread-3消费者准备消费集合元素！
 Thread-0生成完成：[Struts]
 Thread-0生产者准备生产集合元素！
 Thread-3消费完成：[Struts]
 Thread-3消费者准备消费集合元素！