Linux - 进程控制（下篇）- 进程等待

进程等待

为什么进程需要等待？

我们知道，在Linux 当中，父子进程之间一些结构就是一些多叉树的结构，一个父进程可能管理或者创建了很多个字进程。

而其实我们在代码当中使用fork（）函数创建的子进程的父进程，这个父进程其实也是其他的父进程的子进程，我们在命令行当中运行进程，都是 bash 这个命令行解释器的子进程。

在之前谈论进程状态的时候，我们说过，子进程的销毁（死亡状态），要先经历一个僵尸状态，这个状态下，是操作系统帮我们维护这个进程的相关信息，用于个这个子进程的父进程做信息保留（让父进程读取这个进程的结束状态），让父进程知道，这个子进程在销毁时候，执行的认为完成到哪一步了。

但是，如果父进程对这个子场景不管不顾的话，那么就会引发出僵尸状态下的一个大问题 -- 由僵尸状态引发的内存泄漏问题。

因为，操作系统维护这个子进程的信息，本质上就是把这个子进程的信息，在内存当中进行维护，所以是要占用内存空间的。

而且，僵尸状态在操作系统看来就是一个将亡的状态，那么这个进程本质上马上就要死亡了，处于僵尸状态的进程是“刀枪不入的”，就算我们使用 kill -9 xxxx 这个强制关闭进程的命令，也无济于事。

此时，只能通过特殊的方式来将这个进程给删除掉，比如使用进程等待的方式来实现。

所以，结果上述分析，得出一个结论：

僵尸进程是无法被杀死的，需要通过进程等待来杀掉它，进而解决内存泄漏问题。

我们要通过进程等待，获得子进程的退出情况。也就是需要知道这个子进程在退出的时候，它把这个任务完成得怎么样了。

怎么做到进程等待？

通过系统调用接口 wait / waitpid，来对子进程进行状态监测和资源回收的功能。

我们先看下面这个例子：

上述的子进程只会执行 5 次，而父进程是一直执行的。我们在子进程当中使用 exit（）函数来直接结束的掉子进程，防止子进程执行到与父进程共享的当中。

结果输出：

子进程执行5次之后，就exit（）结束了，此时子进程不会直接死亡，互进入僵尸状态，我们可以简单在命令行当中写一个监测这个两个进程检测工具来查看：

 while :; do ps axj | head -1 && ps axj | grep textwait | grep -v grep ; sleep 1 ; echo "----------------" ; done

监测结果：

那么，这个子进程进入僵尸状态之后，就会一直处于僵尸状态，除非父进程去接收这个子进程的结束状态。最终带来的结果就是内存泄漏。

所以，我们要想法子让父进程接收子进程的退出状态。

父进程可以通过调用 wait / waitpid 系统调用接口进行对僵尸进程的回收问题。

wait （）接口

wait（）函数所代表的意思就是， 等待一个进程，直到这个进程的状态发生改变。就是让父进程来等待子进程。只要父进程创建的子进程，有子进程要退出了，那么父进程就会等待这个子进程。
其中有一个 status 参数，放在 waitpid（）当中说明。我们把这个设置为 NULL，表示的就是，我们不关心这个进程的退出状态。
返回值 pid_t，如果父进程等待成功，就会返回这个子进程的PID，所以，这种情况的返回值是 >0 的。

所以，我们对上述的例子示例代码当中的，父进程的执行部分进行修改，给父进程执行 10 次，然后执行 wait（）函数，等待子进程：

此时，当父进程执行10 次之后，就会运行 wait（）函数等待退出的子进程，输出结果如下所示：

发现，最后子进程在等待，回收的子进程就是刚开始创建的子进程，pid 都是可以对上的。

此时，我们再使用监控程序来检查一下此时父子进程的运行过程：

说明，父进程调用 wait（）函数之后，确实把僵尸状态的子进程给回收了。

循环等待

如果一个父进程有不止一个子进程的话，wait（）函数是怎么使用的呢？等待哪一个呢？

注意的是，wait（）等待的是任意一个子进程退出，也就是说，wait（）函数一次只会等待处理一个子进程，如果需要除了多个僵尸子进程的退出问题的话，可以使用循环执行 wait（）函数来实现：

阻塞等待

如果父进程在等待子进程退出之时，这个，或者多个子进程一直都不退出的话，（如果此时父进程也不退出的话），此时，在父进程调用 wait（）的时候，会在 wait（）函数处，进行 阻塞等待。

换言之，子进程一直不退出，父进程调用的 wait（）函数也就一直不回返回，简单点说就是 “等你死”。只要子进程退出了，成为僵尸状态了，那么wait（）函数才会返回。这种等待叫做 阻塞等待。

所以，一个进程处于等待状态，或者称之为阻塞状态，它不一定，一定是在等待某一个硬件资源，也有可能是在等待某一个软件资源。这叫做 -- 软件条件。在服务器当中，就经常使用这种因为等待软件资源，而进程等待（阻塞）的模式。

像上述的父进程，调用wait（）函数，但是就可以没有等到退出的子进程，那么父进程就是在等待软件资源。

进程等待是必须的！

由上述你也发现，如果父不等待的话，子进程会一直处于僵尸状态，而进程的等待，有一个非常大的作用 --- 回收僵尸子进程。如果不等待的话，这个进程就一直是僵尸状态，那么就会一直占用系统资源，造成内存泄露问题。

所以，一个进程使用过程应该是：创建进程（比如 fork（）） -- 终止进程（比如 exit（））--- 进程等待（比如 wait（））

waitpid（）获取子进程的退出状态

上述我们使用了 wait（）函数来等待了子进程的退出，结束了子进程的僵尸状态；但是，父进程结束僵尸状态，可能不仅仅是为了解决内存泄漏问题的，有的时候，父进程需要知道子进程是为什么而退出的，或者是像知道，子进程在退出之时，把他的任务做到了什么进度，是否完成。

所以，这时，需要使用 waitpid（）函数：

waitpid（）函数是wait（）函数的升级版，你可以理解为，wait（）函数的功能是 waitpid（）函数的功能的子集。

返回值：

当正常返回的时候waitpid返回收集到的子进程的进程ID；
如果设置了选项WNOHANG,而调用中waitpid发现没有已退出的子进程可收集,则返回0；
如果调用中出错,则返回-1,这时errno会被设置成相应的值以指示错误所在；

参数：
pid：

Pid=-1,等待任一个子进程。与wait等效。
Pid>0.等待其进程ID与pid相等的子进程。

status:

WIFEXITED(status): 若为正常终止子进程返回的状态，则为真。（查看进程是否是正常退出）
WEXITSTATUS(status): 若WIFEXITED非零，提取子进程退出码。（查看进程的退出码）

options:

WNOHANG: 若pid指定的子进程没有结束，则waitpid()函数返回0，不予以等待。若正常结束，则返回该子进程的ID。

理解 status 参数

wait（）和 waitlid（）两个函数的 status 参数的作用是是一样的，所以，这里介绍 waitpid（）当中的 status 就可以了。

首先我们会发现，这个 status 参数的类型是 int*，在传参之时，确实是要传一个指针的。

我们需要通过 status 参数，利用 wait（）或者 waitpid（）这两个函数，拿到任意给一个进程或者是指定进程的退出结果的。

从语法上理解，这个 status 参数是一个输出型参数。是专门用于在 wait（）和 waitpid（）两个函数当中，接受返回某个就的退出码的。

如下面这个例子：

相当于是在 waitpid（）函数内部，利用传入的 status 指针来修改到外部的 status 这个变量。

此时我们在打印一下的 status 看看值是不是 1：

此时我们就发现，打印的 status 的值不是1，是 256，这是为什么呢？

要搞清楚这一点，我们就要先搞清楚，父进程究竟想要子进程返回什么？

首先，子进程是一个进程，一个进程运行的执行结果无外乎就是三种：

代码运行完毕，结果正确；
代码运行完毕，结果不正确；
代码异常终止；

那么，这种三种情况就是父进程想要知道的，子进程退出之前的信息。如果正常执行，返回0，那么还好，如果返回的不是0，就是说明出了问题；这两种情况都好说，都可以用返回的退出码来表示。但是，如果是异常信息呢？

其实，父进程在等待的时候，需要关心的事情还是很多的，这就注定了，status 这个变量，就不能被单纯的看做的是一个整数来看待；其实这个 status 变量是把这个整形变量看做好几部分的。

整形的存储是有32 个比特位，系统当中把这个 status 变量的这 32 个比特位分成了几个部分来看待：

首先要确定的是，当前我们先不看高位的16个比特位的含义，也就是前16 个我们先不考虑含义，我们先考虑后 16 位：

可能上图不能更好表示，我们利用各个比特位的数字来表示更加形象：

我们发现，在这后16 个比特位当中，表示了三种信息：

进程的退出状态；
core dump 状态；
进程的终止信号；

所以，此时你应该就明白了，上述为什么输出的是 256了，256.不就是 2^8 吗？

所以，status 使用最后 7 位来表示异常信息的，我们所说的进程异常指的就是这个进程受到了异常信号，比如我们使用 kiil -9 就可以给某一个进程发送一个 9 号信号。

虽然异常的报错很多，都是以字符串的方式展现给用户的，但是进程的信号是有编号的，我们使用 kill -l 就可以查看所以信号：

发现，每一个信号都是有编号的。

而且，编号都是从1 开始，没有 0 号异常信号的，所以，如果我们像检测一个进程退出之时，是否发生异常，可以查看这个进程的信号是不是 0 。（也就是查看 status 的低7位是否为 0）
那么在上述判定进程是否发生异常之后，还需要判断这个进程是否执行完毕，如果执行完毕，结果对不对，这就要看进程的退出信号了，也就是 status的 15 - 8 这 16 个比特位。

在提一个简单区分为问题：

那么，我为什么要用这个 wait/waitpid 这些系统调用接口来获取到某一个进程的各种退出码和各种信号呢？

我们直接在全局定义一个变量，当子进程出现问题，或者没有会出现问题，按照不同的情况，像 wait的系统调用接口当中区分这些情况的方式一样去却分这些情况，然后把这些计算出的值直接赋值个这个全局变量不行吗？

答案肯定是不行的。因为，进程之间是具有独立性的，我们之间再谈进程地址空间当中谈过，父子进程，在子进程刚开始创建之时，父子进程是共用一个数据和代码的。但是如果父子进程其中的某一个先修改了某一个变量的值（或者是修改了某一块的数据的话），那么操作系统就会发生写时拷贝，为这个先修改的进程单独创建一个空间，用于存储这个进程修改的变量的数据。

所以，如果子进程当中对这全局变量进行修改的话，那么就会发生写时拷贝，当发生写时拷贝之后，那么父子进程就不在共用一个这个全局变量的数据了。

Linux - 进程地址空间-CSDN博客

所以，只能使用 wait 这些系统调用接口来实现。

简单验证上述所说的 status 的取值结构

要想验证的话，就要使用位操作运算符了。

我们使用一下方式来验证：

status & 0x7F

status 按位与上 0x7F ，0x7F 的后8位就是 0111 1111：
这样的话，上述式子的运算符结果就是，原本 status 在除去后8位之外的其他位的干扰之外，后7位本来的值。

接着，还要提取出 15 - 8 这16 个比特位的值：
同样使用按位与：

(status>>8) & 0xFF

0xFF 就是 1111 1111 。

程序代码：

取的子进程还是上述例子当中子进程，输出结果：

发现，此时的退出码是1，进程信号是0；验证成功。

使用宏来更好的从 status 当中提取出程序信息

像上述使用的类似于按位与上 0x7F 或者是 0xFF 这样的方式来提取出 status 当中的程序信息，还是太麻烦了，而且，对于初学C语言，不了解位操作的新手来说，上手需要成本。

所以，在库当中有两个常用的宏函数，可以帮助我们从 status 当中提取出两个进程信息：

WIFEXITED(status): 若为正常终止子进程返回的状态，则为真。（查看进程是否是正常退出）
WEXITSTATUS(status): 若WIFEXITED非零，提取子进程退出码。（查看进程的退出码）

这两个宏函数可以帮助我们从传入处参数 status 当中提取出进程的返回状态和进程退出码。

其实两个函数也就是替换了一下上述我们实现的类似 0x7F 位操作，只不过可能取了逻辑反的操作。

但是在使用上来说，比以前就非常的直观了。

需要注意区分的是：上述两个if 当中的else语句代表的是不同的意思，两者是不同的概念。

进程等待的原理

我们之前说过，子进程在转变为死亡状态之前，要先转换为僵尸状态，在僵尸状态的时候，子进程的代码和数据在内存当中所占的空间可以释放掉，但是存储子进程信息的 PCB对象不能，操作系统要维护子进程退出信息。

子进程的退出信息就主要的是： exit_code 退出码；exit_signal 退出信号，这两个信息。这两个信息，就被父进程当中的 wait/waitpid 之类的函数所捕获，然后修改到父进程数据区当中是变量当中。

把 exit_code 退出码；exit_signal 退出信号 这两个信号，结果位运算，合并为一个 status 变量当中存储。

从上述当中也体现了，操作系统不相信任何人，他不允许用户直接访问到操作系统当中当中数据，或者是硬件存储的数据，只能通过接口来访问。向上述，在子进程 PCB 当中的两个重要信息，我们直接访问是访问不到的，只要通过操作系统提供的类似的 wait（）一样的接口才能访问到。也就是说，访问和修改数据可以，但是必须要在操作系统的监督之下，因为有些数据非常的重要，不能修改掉，只有操作系统去监督，操作系统才给你去访问和修改数据。