大家好，又见面了，我是你们的朋友全栈君。
为什么要通信
通信是人的基本需求。而进程作为人的发明，自然脱离不了人的习性，也有通信需求。如果进程之间不进行任何通信，那么进程所能完成的任务就要大打折扣。 例如，父进程在创建子进程后，通常须要监督子进程的状态，以便在子进程没有完成给定的任务时，可以再创建一个子进程来继续。这就需要父子进程间通信。
而线程间的通信则需要更多。由于一个进程通常包括多个线程，这多个线程之间因资源共享自然地就存在一种合作关系。这种合作关系虽然可以表现为相互独立，但更多地时候是互相交互。这就是通信。就像舞台上的多个演员，他们之间是一种合作关系，共同将戏演好。虽然这些演员在舞台上的时候可以各自演各自的，不说话，也没有肢体接触，即没有交互，但他们更多的时候会进行对白和拥抱等交互操作。
线程之间的交互我们就称之为线程通信。线程通信是从进程通信演变而来的,进程通信有个专有缩写,叫IPC( Inter-Process Communication)。由于每个进程至少有一个线程,进程的通信就是进程里面的线程通信。在随后的讨论中,我们将统一使用线程通信来进行讲解。
那么线程之间的通信是如何进行的呢? 舞台上的演员可以通过对白，手势和拥抱等方法来交互通信。类似地，线程也可以同样的方式来进行通信。下面我们就来看一下线程的这些交互方式。
管道、记名管道、套接字
演员最常使用的交互手段就是对白。对白就是一方发出声音,另一方接受声音。声音的传递则通过空气(当面或无线交谈)、线缆(有线电话)进行传递。类似地,线程对白就是一个线程发出某种数据信息，另外一方接受数据信息，这些数据信息通过一片共享的存储空间进行传递。
在这种方式下，一个线程向这片存储空间的一端写入信息，另一个线程从存储空间的另外一端读取信息。这看上去像什么？管道。管道所占的空间既可以是内存，也可以是磁盘。就像两人对白的媒介可以是空气,也可以是线缆一样。要创建一个管道，一个线程只需调用管道创建的系统调用即可。
管道(无名管道)
从根本上说，管道是一个线性字节数组，类似文件。使用文件读写的方式进行访问，但却不是文件。因为通过文件系统看不到管道的存在。另外,我们前面说了,管道可以设在内存里，而文件很少设在内存里。创建管道在壳命令行下和在程序里是不同的。壳命令行下,只需要使用符号“|”即可。
在程序里面，创建管道需要使用系统调用popen()或者pipe()。popen需要提供一个目标进程作为参数，然后在调用该函数的的进程和给出的目标进程之间创建一个管道。这很像人们打电话时必须提供对方的号码,才能创建连接一样。
创建时还需要提供一个参数表明管道类型：读管道或者是写管道。而 pipe 调用将返回两个文件描述符(文件描述符是用来识别一个文件流的一个整数,与句柄不同),其中一个用于从管道进行读操作，一个用于写入管道。也就是说, pipe将两个文件描述符连接起来，使得一端可以读，另一端可以写。通常情况下,在使用pipe调用创建管道后，再使用fork产生两个进程，这两个进程使用pipe返回的两个文件描述符进行通信。 例如,下述代码段创建一个管道并利用它在父子进程间通信。int pp [2 ] ; 言
代码语言：javascript复制int fd[2];//用来存放返回的管道的描述符
pipe(fd);//fd[0]读，fd[1]写
int pid = fork();
//assert(pid != -1);
if(pid == 0)
{
………………
}
else
{
………………
}(无名)管道的一个重要特点是使用管道的两个线程之间必须存在某种关系， 例如，使用popen需要提供另一端进程的文件名，使用pipe的两个线程则分别隶属于父子进程。
记名管道
如果要在两个不相关的线程，如两个不同进程里面的线程，之间进行管道通信，则需要使用记名管道。顾名思义，记名管道是一个有名字的通信管道。记名管道与文件系统共享一个名字空间，印我们可以从文件系统中看到记名管道。也就是说，记名管道的名字不能与文件系统里的任何文件名重名。
一个线程通过创一个记名管道后，另外一个线程可使用open来打开这个管道(无名管道则不能使用open)，从而与另外一端进行交流。(或者使用已经存在的管道)。记名管道的名称由两部分组成，计算机名和管道名，例如[主机名]管道[管道名]。
对于同一主机来讲允许有多个同一命名管道的实例，并且可以由不同的进程打开,但是不同的管道都有属于门己的管道缓冲区，而且有自己的通信环境，互不影响。命名管道可以支持多个客户端连接一个服务器端。命名管道客户端不但可以与本机上的服务器通信也可以同其他主机上的服务器通信。
管道和记名管道虽然具有简单，无需特殊设计(指应用程序方面)就可以和另外一个进程远行通信的优点，但其缺点也是显然的。首先是管道和记名管道并不是所有操作系统都支特。主要支持管道通信方式的是UNIX和类UNIX(如Linux )的操作系统。 这样，如果需要在其他操作系统上进行通信，管道机制就多半会力不从心了。其次，管道通信需要在相关的进程间进行(无名管道)，或者需要知道按名字来打开(记名管道)，而这在某些时候会十分不便。
套接字
套接字(socket)是另外一种可以用于进程间通信的机制！套接字首先在BSD中出现，随后几乎渗透到所有主流操作系统。套接字的功能非常强大，可以支持不同层面，不同应用，跨网络的通信。使用套接字进行通信需要双方均创建一个套接字，其中一方作为服务器方，另外一方作为客户方。服务器方必须先创建一个服务器套接字，然后在该套接字上进行监听，等待远方的连接请求。欲与服务器通信的客户则创建一个客户套接字，然后向服务器套接字发送连接请求。服务器套接字在收到连接请求后，将在服务器机器上创建一个客户套接字，与远方的客户机上的客户套接字形成点到点的通信通道。之后，客户端和服务器端就可以通过send和recv命令在这个创建的套接字通道上进行交流了。
服务器套接字有点类似于传说中的虫洞(worm hole)。虫洞的一端是开放的，它在宇宙内或宇宙间漂移着，另外一端处于一个不同的宇宙，监听是否有任何东西从虫洞来。而欲使用虫洞者需要找到虫洞的开口端(发送连接请求），然后穿越虫洞即可。
这里需要指出的是服务器套接字既不发送数据，也不接收数据(指不接受正常的用户数据而不是连接请求数据)，而仅仅是生产出“客户”套接字。 当其他(远方)的客户套接字发出一个连接请求时，我们就创建一个客户套接字。一旦客户套接字clientsocket创建成功，与客户的通信任务就交给了这个刚刚创建的客户套接字。而原本的服务器套接字serversocket则回到其原来的监听操作上。
套接字由于其功能强大而获得了很大发展，并出现了许多种类。不同的操作系统均支持或实现了某种套接字功能。例如按照传输媒介是否为本地，套接字可以分为本地(UNIX域)套接字和网域套接字。而网域套接字又按照其提供的数据传输特性分为几个大类,分别是:
- 数据流套接字(stream socket):揖供双向,有序、可靠、非重复数据通信。
- 电报流套接字( datagram socket)|提供双向消息流。数据不一定按序到达。
- 序列包套接字( sequential packet):提供双向,有序、可靠连接,包有最大限制。
- 裸套接字(raw socket):提供对下层通信协议的访问。
套接字从某种程度上来说非常繁杂，各种操作系统对其处理并不完全一样。因此,如要了解某个特定套接字实现，读者需要查阅关于该套接字实现的具体手册或相关文档。
信号
管道和套接字虽然提供了丰富的通信语义，并且也得到了广泛应用，但它们也存在某些缺点，并且在某些时候，这两种通信机制会显得很不好使。
首先，如果使用管道和套接字方式来通信，必须事先在通信的进程间建立连接(创建管道或套接字)，这需要消耗系统资源。其次,通信是自愿的。 即一方虽然可以随意往管道或套接字发送信息，对方却可以选择接收的时机。即使对方对此充耳不闻，你也奈何不得。再次，由于建立连接消耗时间，一旦建立，我们就想进行尽可能多的通信。而如果通信的信息量微小，,如我们只是想通知一个进程某件事情的发生，则用管道和套接字就有点“杀鸡用牛刀”的味道，效率十分低下。 因此,我们需要一种不同的机制来处理如下通信需求:
- 想迫使一方对我们的通信立即作出回应。
- 我们不愿事先建立任何连接,面是临时突然觉得需要向某个进程通信。
- 传输的信息量微小,使用管道或套接字不划算。
应付上述需求,我们使用的是信号( signal )。
那么信号是什么呢？在计算机里，信号就是一个内核对象，或者说一个内核数据结构。发送方将该数据结构的内容填好，并指明该信号的目标进程后，发出特定的软件中断。操作系统接受到特定的中断请求后，知道是有进程要发送信号,于是到特定的内核数据结构里查找信号接受方，并进行通知。接到通知的进程则对信号进行相应处理。如果对方选择不对信号作出反应,则将终止操作系统运行。
信号量
信号量( Semaphore)是由荷兰人E W. Dijkstra 在60年代所构思出的一种程序设计构造。其原型来源于铁路的运行：在一条单轨铁路上,任何时候只能有一列列车行驶在上面。而管理这条铁路的系统就是信号量。任何一列火车必须等到表明铁路可以行驶的信号后才能进入轨道。当一列火车进入单轨运行后，需要将信号改为禁止进人，从而防止别的火车同时进入轨道。面当火车驶出单轨后，则需要将信号变回到允许进入状态。
在计算机里，信号量实际上就是一个简单整数。一个进程在信号变为0或者1的情况下推进，并且将信号变为1或0来防止别的进程推进。当进程完成任务后,则将信号再改变为0或1，从而允许其他进程执行。
信号量不光是一种通信机制,更是一种同步机制。
共享内存
管道，套接字，信号，信号量，虽然满足了多种通信需要，但还是有一种需要未能满足。这就是两个进程需要共享大量数据。这就像两个人，他们互相喜欢,并想要一起生活时(共享大量数据)，打电话，握手，对白等就显得不够了，这个时候需要的是拥抱，只有将其紧紧拥抱于怀，感觉才最到位，也才能尽可能地共享。
进程的拥抱就是共享内存。共享内存就是两个进程共同拥有同一片内存。 这片内存中的任何内容，二者均可以访问。要使用共享内存进行通信，一个进程首先创建一片内存空间专门作为通信用，而其他进程则将该片内存映射到自己的(虚拟)地址空间。这样，读写自己地址空间中对应共享内存的区域时，就是在和其他进程进行通信。
乍一看，共享内存有点像管道，有些管道不也是一片共享内存吗？这是形似而神不似。首先，使用共享内存机制通信的两个进程必须在同一台物理机器上；其次，共享内存的访问方式是随机的，而不是只能从一端写，另一端读。还有一点，就是管道中的数据一读就没有了(只能读一次)，而共享内存中的数据可以反复读(只要不被覆盖，删除)因此其灵活性比管道和套接字大很多，能够传递的信息也复杂得多。
共享内存的缺点是管理复杂，且两个进程必须在同一台物理机器上才能使用这种通信方式。共享内存的另外一个缺点是安全性脆弱。因为两个进程存在一片共享的内存，如果一个进程染有病毒，很容易就会传给另外一个进程。就像两个紧密接触的人，一个人的病毒是很容易传给另外一个人的。
这里需要提请读者注意的是,使用全局变量在同一个进程的线程间实现通信不称为共享内存。
消息队列
消息队列是一列具有头和尾的消息排列，新来的消息放在队列尾部，而读取消息则从队列头部开始。
乍一看,这不是管道吗？一头儿读、一头儿写？没错。这的确看上去像管道。但它不是管道。首先它无需固定的读写进程，任何进程都可以读写(当然是有权限的讲程)。其次,它可以同时支持多个进程，多个进程可以读写消息队列。即所谓的多对多，而不是管道的点对点。另外，消息队列只在内存中实现。
最后，它并不是只在UNIX和类UNIX操作系统实现。几乎所有主流操作系统都支持消息队列。
其他通信机制
除了上面介绍的主流通信方式外，有些操作系统还提供了一些其操作系统所特有的通信机制，例如Windows支持的进程通信方式就有剪贴板(clipboard)， COM/DCOM，动态数据交换(DDE) ，邮箱( mailslots) ；而 solaris则有所谓的solaris 门机制，让客户通过轻量级(16KB)系统调用使用服务器的服务。
虽然进程之间的通信机制繁多，且每种机制有着自己独特的特性，但归根结底都来源于AT&T的 UNIX V系统。该系统在1983年加入了对共享内存、信号量和消息队列的支持。这三者就是众所周知的System V IPC( POSIX IPC 也是源于该系统并成为当前IPC的标准)。因此，虽然不同操作系统的IPC机制可能不尽相同，但其基本原理则并无大的不同。如果需要了解具体操作系统的IPC机制的实现。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/150741.html原文链接：https://javaforall.cn
