进程间通信应该是很常见了，如 VScode 的 Eh 和 Main 的通信（这个应该算 RPC），不同进程间的通信等，接下来让我们进入IPC的世界。

说到进程间通讯，那么第一想法就是通过共享内存，每一个进程之间的隔离很好，就那通过共享一片内存区域来达到通讯的目的，如果是通过磁盘通信效率过慢。

同时共享也就会带来竞争，我们就要思考怎么在同步消息的基础上又不会出现消息被覆盖等。

目前我们思考下沟通双方该怎么进行沟通。

第一种，也就是当要进程通信的时候，进程双方停下手头的工作就等着信息来，这种很明显信息传递效率很高，但问题也很明显，如果没有立刻发送，就会导致工作效率降低等，接收方占用着算力资源。

所以…我们有没有不需要让进程们忙等待，而是自己做自己的事情，等通信完了再接收通讯信息呢？

让我们的内核接入吧~

如果要进行 IPC，何不让发送方把信息发给内核，内核将信息拷贝到内核缓冲区，再将接收方从 blocked 切换到 ready，接收方醒来后通过 receive() 取出信息？

这样接收方就不用忙等待的浪费算力，也能及时的收到信息。

再继续前，我们聊聊进程间通讯的一些思考。

你是否有过这样的疑问：

A 进程想向 B 进程发送消息，那么 A 进程在发送后会阻塞的等待 B 的回复，但 B 又怎么知道会有消息进来让它知道它需要发送消息给 A 呢？因为我们讲的前提都是，接收方明白会有消息来，所以它会堵塞的等待消息，在消息到后内核唤醒阻塞的进程。如果 A 要接受消息需要先发给 B，而 B 需要接收消息需要先发给 A，这不就成了套娃问题吗？

让我们看看几段代码：

生产者与消费者：

// ——— 进程 A：生产者 ———
while (1) {
    item = produce();      // 生产数据
    send(B, item);         // 发给 B，这是写死的
}

// ——— 进程 B：消费者 ———
while (1) {
    item = receive(A);     // 从 A 那收，这也是写死的
    consume(item);         // 消费数据
}

客户端和服务器：

// ——— 服务器 ———
while (1) {
    request = receive();        // 等客户端消息（阻塞）
    response = handle(request); // 处理
    send(client, response);     // 回复
}

// ——— 客户端 ———
send(server, "查询xxx");        // 发请求
result = receive();             // 等回复（阻塞）

发现了吗，当发出请求时，对应的一直在等，而是接收方的程序逻辑本身就设计为等待并处理请求，如服务器进程天生就是循环等待客户端消息，它一直在等待着请求，然后将信息传过去。

接下来让我们想想通讯的方式，很符合直觉的是，我既然想发送消息，那我指定是哪个人不就好了，这就是直接通讯，那同样也会出现一个问题，如我进程换了一个，但它也需要这个信息，那就要手动的更改目标，或者新增目标，当大片的进程发生更改，就会带来大量的问题，因此有了另一种，不指定目标是哪个进程，我放到某个公共区，你想要就自己要公共区拿。

而公共区是什么？分为邮箱 (Mailbox) 和端口 (Port)，邮箱是由内核维护的数据结构，一个队列，receiver 读取数据弹出队头，sender 放入数据加入队尾。而端口是特殊一点的邮箱，只允许绑定对应端口的进程来读取。

接下来就是消息的同步和异步问题，我们回忆一下，在上面讲的，我们都说想要信息发送后就进入堵塞的等待信息，但如果不堵塞呢？自己一直跑效率会不会更高点：

同步也分多钟，一种是发送方发给内核，内核接受完确认接收完毕了发给信号给发送方，发送方继续走；另一种是发送方不止是内核接受完，还要接收方也接受到才继续工作。

异步则类似同步一，发送信息给内核后，内核将其 copy 过来，但不同是的，比如邮箱满了，同步一会堵塞的等待邮箱空出位置然后放进去，而异步就直接报错。

操作	正常情况	邮箱满了
异步 send	拷贝到内核，立刻返回	也立刻返回（报错）
同步 send	拷贝到内核，立刻返回	阻塞等空位
严格同步 send	拷贝到内核，等对方收	阻塞

Go 的无缓冲 channel 对应同步二，有缓冲 channel 对应同步一，发送数据的人不关注谁来接收数据，然后同步的等待数据被接收后才继续。