前两天的生产者和消费者是同一个进程里的两条线程。它们能访问同一块内存所以我们用锁保护共享数据。如果生产者和消费者变成两个进程情况就不同了。两个进程通常各有自己的地址空间在父进程里修改一个普通变量子进程不会因此看到修改。它们需要一条专门的通信通道。今天先用最容易看清的管道传一次话然后追一个很常见的故障数据明明已经传完程序却一直不退出。管道是一条字节通道在终端输入printfhello\n|wc-cprintf产生文字wc -c统计收到的字节数。中间的|让 Shell 建立管道把前一个程序的输出接到后一个程序的输入。管道可以理解成由内核管理的一条字节通道。一端写入另一端读取写入进程 ──写端 [ 内核中的管道 ] 读端──→ 读取进程读端暂时没有数据、但仍有写端开着时读取会等待。所有写端都关闭而且剩余数据已读完后读取才会得到“结束了”的结果。在 C 里这表现为read返回0。**管道传的是字节流没有替你划分“第一条消息”“第二条消息”。**写入方一次写了多少字节读取方不一定恰好用一次read收到同样多的字节。自己用pipe和fork传一次把下面代码保存为pipe_demo.c。父进程写入Hi!子进程一直读到管道结束#includestdio.h#includesys/types.h#includesys/wait.h#includeunistd.hintmain(void){intfd[2];if(pipe(fd)-1){perror(pipe);return1;}pid_tpidfork();if(pid-1){perror(fork);close(fd[0]);close(fd[1]);return1;}if(pid0){close(fd[1]);/* 子进程只读关掉自己的写端 */charch;ssize_tn;while((nread(fd[0],ch,1))1){putchar(ch);}close(fd[0]);if(n-1){perror(read);return1;}return0;}close(fd[0]);/* 父进程只写关掉自己的读端 */constchar*messageHi!\n;for(constchar*pmessage;*p!\0;p){if(write(fd[1],p,1)!1){perror(write);close(fd[1]);waitpid(pid,NULL,0);return1;}}close(fd[1]);/* 告诉读端不会再有数据了 */if(waitpid(pid,NULL,0)-1){perror(waitpid);return1;}return0;}编译运行gcc-Wall-Wextra-opipe_demo pipe_demo.c ./pipe_demo输出是Hi!这里一次只写、读一个字节是为了让例子集中在管道和关闭操作上。实际程序通常按缓冲区读写还要处理一次调用只传输部分数据的情况。最关键的是那几个closepipe(fd)给出两个文件描述符fd[0]是读端。fd[1]是写端。随后调用fork。第二天讲过子进程会继承父进程已打开的文件描述符。所以fork之后父子进程各自都持有读端和写端。它们必须关掉自己不用的那一端。试着把子进程里的这一行注释掉close(fd[1]);再运行程序很可能一直不退出。原因值得沿着代码走一遍父进程写完Hi!关闭自己的写端。子进程读完这些字节再次调用read等着管道结束。可子进程自己还开着一个写端。内核看到仍有写端就不能告诉读端“以后再也没有数据”。父进程正在waitpid中等子进程退出子进程正在等一个不会到来的结束信号。这类故障不靠多分 CPU 时间解决。两个进程都在等待真正需要查的是各自等什么让它继续的条件还能发生吗实验卡住时可以按CtrlC结束再恢复那行close。管道代码里关闭不用的端口不是收尾细节它会直接影响读端能否判断结束。进程通信不止管道管道适合传递连续的字节Shell 里把几个程序接起来尤其方便。它也有边界普通管道是单向的要双向通信需要两条管道或使用其他机制。如果两个进程需要访问同一大块数据可以使用共享内存。它减少来回复制数据的需要但共享之后也会遇到前两天的问题谁先写、谁能读、怎样避免同时修改。管道把传输过程交给内核管理共享内存则把协调访问的责任更多地留给程序。还有消息队列、套接字等方式。今天先抓住共同点进程默认没有“直接读取对方普通变量”的能力通信必须通过明确建立的机制。两把锁也能让线程永久等待管道里的等待提醒了我们再回头看锁。如果两条线程需要两把锁却按相反顺序获取线程 A先拿 X再等 Y 线程 B先拿 Y再等 X假设 A 已拿到 XB 已拿到 Y。接下来 A 等 B 放开 YB 等 A 放开 X谁都无法继续。这就是典型的死锁。它成立时几件事同时发生锁一次只能归一方持有线程拿着已有的锁还要等另一把别人不能强行夺走它手里的锁等待关系最后绕成了一个圈。只说“程序在等锁”还不足以判定死锁——如果持锁线程还能继续工作并最终释放锁等待就会结束。对上面的例子一个直接的修法是规定顺序**所有线程都先拿 X再拿 Y释放时反过来。**这样不会出现 A 拿 X 等 Y、B 拿 Y 等 X 的等待圈。实际项目中一旦某段代码要持有多把锁统一加锁顺序比事后排查死锁省心得多。今天两个例子表面不同排查方法却相通。看到程序“卡住”别急着猜它是不是运行太慢。先画出等待关系**谁在等谁谁手里还握着让对方继续所需的资源**管道的写端、互斥锁都可能是那张图上的关键一环。到这里我们从进程、线程一路讲到了它们怎样协作。下一天换一个方向程序使用的内存地址真的是内存条上的位置吗