当前位置：首页 > news >正文

Linux——进程信号

news 来源：原创 2025/5/10 8:27:03

1. 信号入门

1.1 生活中的信号

1.2 代码中的信号

1.3 信号的发送与记录

1.4 信号处理常见方式概述

2. 信号的产生

2.1 使用终端按键产生信号

2.2 通过系统函数/命令向进程发信号

2.2.1 使用命令向进程发送信号

2.2.2 使用函数向进程发送信号

2.3 由软件条件产生信号

2.3.1 SIGPIPE信号

2.3.2 SIGALRM 信号

2.4 由硬件异常产生信号

3. 阻塞信号（信号的保存）

3.1 关于信号的常见概念

3.2 在内核中的表示

3.3 sigset_t

3.4 信号集操作函数

3.5 sigprocmask

3.6 sigpending

4. 捕捉信号

4.1 内核空间与用户空间

4.2 内核态和用户态

4.3 内核如何实现信号的捕捉

4.4 sigaction

5. 穿插话题——操作系统是如何运行的

5.1 硬件中断

编辑

5.2 时钟中断

5.3 死循环

5.4 软中断

5.6 如何理解内核态和用户态

6. 可重入函数

7. volatile

1. 信号入门

1.1 生活中的信号

1、你在网上买了很多件商品，在等待不同商品快递的到来。但即便快递还没有到来，你也知道快递到了的时候应该怎么处理快递，也就是你能“识别快递”。
2、当快递到达目的地了，你收到了快递到来的通知，但是你不一定要马上下楼取快递，也就是说取快递的行为并不是一定要立即执行，可以理解成在“在合适的时候去取”。
3、在你收到快递到达的通知，再到你拿到快递期间，是有一个时间窗口的，在这段时间内你并没有拿到快递，但是你知道快递已经到了，本质上是你“记住了有一个快递要去取”。
4、当你时间合适，顺利拿到快递之后，就要开始处理快递了，而处理快递的方式有三种：

执行默认动作（打开快递，使用商品）、执行自定义动作（快递是帮别人买的，你要将快递交给他）、忽略（拿到快递后，放在一边继续做自己的事）。
快递到来的整个过程，对你来讲是异步的，你不能确定你的快递什么时候到。

1.2 代码中的信号

信号是一种给进程发送的，用来进行事件异步通知的机制。信号的产生相对于进程的运行的异步的，信号是发给进程的。

我们知道该程序的运行结果就是死循环地进行打印，而对于死循环来说，最好的方式就是使用Ctrl+C对其进行终止。

为什么使用Ctrl+C后，该进程就终止了？

实际上当用户按Ctrl+C时，这个键盘输入会产生一个硬件中断，被操作系统获取并解释成信号（Ctrl+C被解释成2号信号），然后操作系统将2号信号发送给目标前台进程，当前台进程收到2号信号后就会退出。

我们可以使用signal函数对2号信号进行捕捉，证明当我们按Ctrl+C时进程确实是收到了2号信号。

使用signal函数时，我们需要传入两个参数，第一个是需要捕捉的信号编号，第二个是对捕捉信号的处理方法，该处理方法的参数是int，返回值是void。

例如，下面的代码中将2号信号进行了捕捉，当该进程运行起来后，若该进程收到了2号信号就会打印出收到信号的信号编号。

#include <stdio.h>
#include <signal.h>
#include <unistd.h>void handler(int sig)
{printf("get a signal:%d\n", sig);
}int main()
{signal(2, handler); //注册2号信号while (1){printf("hello signal!\n");sleep(1);}return 0;
}

此时当该进程收到2号信号后，就会执行我们给出的handler方法，而不会像之前一样直接退出了，因为此时我们已经将2号信号的处理方式由默认改为了自定义了。

这里补充一点：9号/19号信号不能被自定义捕捉。

注意：

1、Ctrl+C产生的信号只能发送给前台进程。在一个命令后面加个&就可以将其放到后台运行，这样Shell就不必等待进程结束就可以接收新的命令，启动新的进程。
2、Shell可以同时运行一个前台进程和任意多个后台进程，但是只有前台进程才能接到像Ctrl+C这种控制键产生的信号。

3、前台进程可以从标准输入（键盘）中获取内容，后台进程不可以。
4、前台进程在运行过程中，用户随时可能按下Ctrl+C而产生一个信号，也就是说该进程的用户空间代码执行到任何地方都可能收到SIGINT信号而终止，所以信号相对于进程的控制流程来说是异步的。
5、信号是进程之间事件异步通知的一种方式，属于软中断。

1.3 信号的发送与记录

我们使用kill -l命令可以查看Linux当中的信号列表。

其中1~31号信号是普通信号，34~64号信号是实时信号，普通信号和实时信号各自都有31个，每个信号都有一个编号和一个宏定义名称。

信号是如何记录的？

实际上，当一个进程接收到某种信号后，该信号是被记录在该进程的进程控制块（PCB）当中的。

我们都知道进程控制块本质上就是一个结构体变量，而对于信号来说我们主要就是记录某种信号是否产生，因此，我们可以用一个32位的位图来记录信号是否产生。

其中比特位的位置代表信号的编号，而比特位的内容就代表是否收到对应信号，比如第6个比特位是1就表明收到了6号信号。

信号是如何发送的？

一个进程收到信号，本质就是该进程内的信号位图被修改了，也就是该进程的数据被修改了，而只有操作系统才有资格修改进程的数据，因为操作系统是进程的管理者。

信号的发送本质上就是操作系统直接去修改目标进程的task_struct中的信号位图。

1.4 信号处理常见方式概述

1、执行该信号的默认处理动作。

2、提供一个信号处理函数，要求内核在处理该信号时切换到用户态执行这个处理函数，这种方式称为捕捉（Catch）一个信号，我们上面代码中提供的handler方法就是信号处理函数。

3、忽略该信号。

在Linux当中，我们可以通过man手册查看各个信号默认的处理动作。

cp@hcss-ecs-348a:~/test1$ man 7 signal

2. 信号的产生

2.1 使用终端按键产生信号

当面对下面的死循环程序时，我们都知道可以按Ctrl+C可以终止该进程。

但实际上除了按Ctrl+C之外，按Ctrl+\也可以终止该进程。

按Ctrl+C终止进程和按Ctrl+\终止进程，有什么区别？

按Ctrl+C实际上是向进程发送2号信号SIGINT，而按Ctrl+\实际上是向进程发送3号信号SIGQUIT。

查看这两个信号的默认处理动作，可以看到这两个信号的Action是不一样的，2号信号是Term，而3号信号是Core。

Term和Core都代表着终止进程，但是Core在终止进程的时候会进行一个动作，那就是核心转储。

什么是核心转储？

进程异常退出时，OS会将进程在内存中的核心数据从内存拷贝到磁盘上保存起来，这个过程就是核心转储。

在云服务器中，核心转储是默认被关掉的，我们可以通过使用ulimit -a命令查看当前资源限制的设定。

其中，第一行显示core文件的大小为0，即表示核心转储是被关闭的。

我们可以通过ulimit -c size命令来设置core文件的大小。

core文件的大小设置完毕后，就相当于将核心转储功能打开了。此时如果我们再使用Ctrl+\对进程进行终止，就会发现终止进程后会显示core dumped。

核心转储功能有什么用？

核心转储的目的就是为了在调试时，方便问题的定位。

说到这里了，大家看到“core dumped”，想一下我们之前在哪里见过它？

没错，是在进程等待哪里，当时我们没有详细介绍core dumped标志。

pid_t waitpid(pid_t pid, int *status, int options);

waitpid函数的第二个参数status是一个输出型参数，用于获取子进程的退出状态。status是一个整型变量，但status不能简单的当作整型来看待，status的不同比特位所代表的信息不同，具体细节如下（只关注status低16位比特位）：

若进程是正常终止的，那么status的次低8位就表示进程的退出状态，即退出码。

若进程是被信号所杀，那么status的低7位表示终止信号，而第8位比特位是core dump标志，即进程终止时是否进行了核心转储。

2.2 通过系统函数/命令向进程发信号

2.2.1 使用命令向进程发送信号

当我们要使用kill命令向一个进程发送信号时，我们可以以"kill -信号名进程ID"的形式进行发送。

也可以以"kill -信号编号进程ID"的形式进行发送。

2.2.2 使用函数向进程发送信号

kill 函数

实际上kill命令是通过调用kill函数实现的，kill函数可以给指定的进程发送指定的信号，kill函数的函数原型如下：

int kill(pid_t pid, int sig);

kill函数用于向进程ID为pid的进程发送sig号信号，如果信号发送成功，则返回0，否则返回-1。

我们可以用kill函数模拟实现一个kill命令，实现逻辑如下：

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>void Usage(char* proc)
{printf("Usage: %s pid signo\n", proc);
}
int main(int argc, char* argv[])
{if (argc != 3){Usage(argv[0]);return 1;}pid_t pid = atoi(argv[1]);int signo = atoi(argv[2]);kill(pid, signo);return 0;
}

该命令的使用方式为”./mykill 进程id 信号编号“，这里大家如果想不待路径，可以将当前路径导入到环境变量PATH中，这里不做演示了。

这里我们运行自己的程序也可以实现kill命令的效果。

raise 函数

raise函数可以给当前进程发送指定信号，即自己给自己发送信号，raise函数的函数原型如下：

int raise(int sig);

如果信号发送成功，则返回0，否则返回一个非零值。

例如，下列代码当中用raise函数每隔一秒向自己发送一个5号信号。

#include <stdio.h>
#include <unistd.h>
#include <signal.h>void handler(int signo)
{printf("get a signal:%d\n", signo);
}
int main()
{signal(5, handler);while (1){sleep(1);raise(5);}return 0;
}

abort 函数

abort函数可以给当前进程发送SIGABRT信号，使得当前进程异常终止，abort函数的函数原型如下：

void abort(void);

abort函数是一个无参数无返回值的函数。

例如，下列代码当中每隔一秒向当前进程发送一个SIGABRT信号。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>void handler(int sig)
{printf("get a signal:%d\n", sig);
}
int main()
{signal(6, handler);while (1){sleep(1);abort();}return 0;
}

与之前不同的是，虽然我们对SIGABRT信号进行了捕捉，并且在收到SIGABRT信号后执行了我们给出的自定义方法，但是当前进程依然是异常终止了。

abort函数的作用是异常终止进程，exit函数的作用是正常终止进程，而abort本质是通过向当前进程发送SIGABRT信号而终止进程的。

因此使用exit函数终止进程可能会失败，但使用abort函数终止进程总是成功的。

2.3 由软件条件产生信号

2.3.1 SIGPIPE信号

SIGPIPE信号实际上就是一种由软件条件产生的信号，当进程在使用管道进行通信时，读端进程将读端关闭，而写端进程还在一直向管道写入数据，那么此时写端进程就会收到SIGPIPE信号进而被操作系统终止。

例如，下面代码当中，创建匿名管道进行父子进程之间的通信，其中父进程是读端进程，子进程是写端进程，但是一开始通信父进程就将读端关闭了，那么此时子进程在向管道写入数据时就会收到SIGPIPE信号，进而被终止。

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
int main()
{int fd[2] = {0};if (pipe(fd) < 0) // 创建匿名管道{perror("pipe");return 1;}pid_t id = fork();if (id == 0){// 子进程close(fd[0]); // 子进程关闭读端// 子进程向管道写入数据const char *msg = "Hello Father,I am child";int count = 5;while (count--){write(fd[1], msg, strlen(msg));sleep(1);}close(fd[1]); // 子进程关闭写端exit(1);}// 父进程close(fd[1]); // 父进程关闭写端close(fd[0]); // 父进程直接关闭读端（系统将会杀死子进程）int status = 0;waitpid(id, &status, 0);printf("Child get signal:%d\n", status & 0x7F);//打印子进程收到的信号return 0;
}

运行代码后，即可发现子进程在退出时收到的是13号信号，即SIGPIPE信号。

2.3.2 SIGALRM 信号

调用alarm函数可以设定一个闹钟，也就是告诉操作系统在若干时间后发送SIGALRM信号给当前进程，alarm函数的函数原型如下：

unsigned int alarm(unsigned int seconds);

alarm函数的作用就是，让操作系统在seconds秒之后给当前进程发送SIGALRM信号，SIGALRM信号的默认处理动作是终止进程。

alarm函数的返回值：

1、若调用alarm函数前，进程已经设置了闹钟，则返回上一个闹钟时间的剩余时间，并且本次闹钟的设置会覆盖上一次闹钟的设置。

2、如果调用alarm函数前，进程没有设置闹钟，则返回值为0。

例如，我们可以用下面的代码，测试自己的云服务器一秒时间内可以将一个变量累加到多大。

#include <stdio.h>
#include <signal.h>
#include <unistd.h>int main()
{int count = 0;alarm(1);while (1){count++;printf("count: %d\n", count);}return 0;
}

可以发现，我的云服务求一秒可以将一个变量累加到将近8万。

但实际上云服务器一秒内可执行的累加次数远大于8万，那为什么运行结果比较小呢？

主要原因有两个：

1、由于我们每进行一次累加就进行了一次打印操作，而与外设之间的IO操作所需的时间要比累加操作的时间更长。

2、由于我当前使用的是云服务器，因此在累加操作后还需要将累加结果通过网络传输将服务器上的数据发送过来，因此最终显示的结果要比实际一秒内可累加的次数小得多。

为了尽可能避免上述问题，我们可以先让count变量一直执行累加操作，直到一秒后进程收到SIGALRM信号后再打印累加后的数据。

#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<signal.h>long long count=0;
void handler(int sig)
{printf("get a signal:%d\n",sig);printf("count:%lld\n",count);exit(1);
}
int main()
{signal(SIGALRM,handler);alarm(1);while(1){count++;}return 0;
}

此时可以看到，count变量在一秒内被累加的次数变成了30亿多，由此也证明了，与计算机单纯的计算相比较，计算机与外设进行IO时的速度是非常慢的。

2.4 由硬件异常产生信号

为什么C/C++程序会崩溃？

当我们程序当中出现类似于除0、野指针、越界之类的错误时，为什么程序会崩溃？

本质上是因为进程在运行过程中收到了操作系统发来的信号进而被终止，那操作系统是如何识别到一个进程触发了某种问题的呢？

我们知道，CPU当中有一堆的寄存器，当我们需要对两个数进行算术运算时，我们是先将这两个操作数分别放到两个寄存器当中，然后进行算术运算并把结果写回寄存器当中。

此外，CPU当中还有一组寄存器叫做状态寄存器，它可以用来标记当前指令执行结果的各种状态信息，如有无进位、有无溢出等等。

而操作系统是软硬件资源的管理者，在程序运行过程中，若操作系统发现CPU内的某个状态标志位被置位，而这次置位就是因为出现了某种除0错误而导致的，那么此时操作系统就会马上识别到当前是哪个进程导致的该错误，并将所识别到的硬件错误包装成信号发送给目标进程。

本质就是操作系统去直接找到这个进程的task_struct，并向该进程的位图中写入8信号，写入8号信号后这个进程就会在合适的时候被终止。

那对于下面的野指针问题，或者越界访问的问题时，操作系统又是如何识别到的呢？

这里大家可以看到运行结果，显示“段错误”，说明程序中存在野指针问题。

那OS怎么知道我们的程序中存在野指针问题呢？

我们必须知道的是，当我们要访问一个变量时，一定要先经过页表的映射，将虚拟地址转换成物理地址，然后才能进行相应的访问操作。

其中页表属于一种软件映射关系，而实际上在从虚拟地址到物理地址映射的时候还有一个硬件叫做MMU，它是一种负责处理CPU的内存访问请求的计算机硬件，因此映射工作不是由CPU做的，而是由MMU做的，但现在MMU已经集成到CPU当中了。

当需要进行虚拟地址到物理地址的映射时，我们先将页表的左侧的虚拟地址导给MMU，然后MMU会计算出对应的物理地址，我们再通过这个物理地址进行相应的访问。

而MMU既然是硬件单元，那么它当然也有相应的状态信息，当我们要访问不属于我们的虚拟地址时，MMU在进行虚拟地址到物理地址的转换时就会出现错误，然后将对应的错误信息写入到自己的状态信息当中，这时硬件上面的信息也会立马被操作系统识别到，进而将对应进程发送SIGSEGV信号。

总结一下：
C/C++程序会崩溃，是因为程序当中出现的各种错误最终一定会在硬件层面上有所表现，进而会被操作系统识别到，然后操作系统就会发送相应的信号将当前的进程终止。

3. 阻塞信号（信号的保存）

3.1 关于信号的常见概念

1、实际执行信号的处理动作，称为信号递达（Delivery）。
2、信号从产生到递达之间的状态，称为信号未决（pending）。
3、进程可以选择阻塞（Block）某个信号。
4、被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞，才执行递达的动作。
需要注意的是，阻塞和忽略是不同的，只要信号被阻塞就不会递达，而忽略是在递达之后的一种处理动作。

3.2 在内核中的表示

每个信号都有两个标志位分别表示阻塞（block）和未决（pending），还有一个函数指针表示处理动作。信号产生时，内核在进程控制块中设置该信号的未决标志，直到信号递达才清除该标志。

1、在block位图中，比特位的位置代表某一个信号，比特位的内容代表该信号是否被阻塞。
2、在pending位图中，比特位的位置代表某一个信号，比特位的内容代表是否收到该信号。
3、handler表本质上是一个函数指针数组，数组的下标代表某一个信号，数组的内容代表该信号递达时的处理动作，处理动作包括默认、忽略以及自定义。
block、pending和handler这三张表的每一个位置是一一对应的。

在上图中：

1、SIGHUP信号未阻塞也未产生过，当它递达时执行默认处理动作。
2、SIGINT信号产生过，但正在被阻塞，所以暂时不能递达。虽然它的处理动作是忽略，但在没有解除阻塞之前不能忽略这个信号，因为进程仍有机会在改变处理动作之后再解除阻塞。
3、SIGQUIT信号未产生过，但一旦产生SIGQUIT信号，该信号将被阻塞，它的处理动作是用户自定义函数sighandler。如果在进程解除对某信号的阻塞之前，这种信号产生过多次，POSIX.1允许系统递达该信号一次或多次。Linux是这样实现的：普通信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里，这里只讨论普通信号。

3.3 sigset_t

根据信号在内核中的表示方法，每个信号的未决标志只有一个比特位，非0即1，如果不记录该信号产生了多少次，那么阻塞标志也只有一个比特位。

因此，未决和阻塞标志可以用相同的数据类型sigset_t来存储。在我当前的云服务中，sigset_t类型的定义如下：（不同操作系统实现sigset_t的方案可能不同）

#define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
{unsigned long int __val[_SIGSET_NWORDS];
} __sigset_t;typedef __sigset_t sigset_t;

sigset_t称为信号集，这个类型可以表示每个信号的“有效”或“无效”状态。

1、在阻塞信号集中“有效”和“无效”的含义是该信号是否被阻塞。
2、在未决信号集中“有效”和“无效”的含义是该信号是否处于未决状态。

阻塞信号集也叫做当前进程的信号屏蔽字（Signal Mask），这里的“屏蔽”应该理解为阻塞而不是忽略。

3.4 信号集操作函数

#include <signal.h>int sigemptyset(sigset_t *set);int sigfillset(sigset_t *set);int sigaddset(sigset_t *set, int signum);int sigdelset(sigset_t *set, int signum);int sigismember(const sigset_t *set, int signum);

函数解释：

1、sigemptyset函数：初始化set所指向的信号集，使其中所有信号的对应bit清零，表示该信号集不包含任何有效信号。
2、sigfillset函数：初始化set所指向的信号集，使其中所有信号的对应bit置位，表示该信号集的有效信号包括系统支持的所有信号。
3、sigaddset函数：在set所指向的信号集中添加某种有效信号。
4、sigdelset函数：在set所指向的信号集中删除某种有效信号。
5、sigemptyset、sigfillset、sigaddset和sigdelset函数都是成功返回0，出错返回-1。
6、sigismember函数：判断在set所指向的信号集中是否包含某种信号，若包含则返回1，不包含则返回0，调用失败返回-1。
注意：在使用sigset_t类型的变量之前，一定要调用sigemptyset或sigfillset做初始化，使信号处于确定的状态。

3.5 sigprocmask

sigprocmask函数可以用于读取或更改进程的信号屏蔽字（阻塞信号集，block位图），该函数的函数原型如下：

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

参数说明：

1、如果oldset是非空指针，则读取进程当前的信号屏蔽字通过oset参数传出，这是一个输出型参数。

2、如果set是非空指针，则更改进程的信号屏蔽字，参数how指示如何更改。

3、如果oldset和set都是非空指针，则先将原来的信号屏蔽字备份到oset里，然后根据set和how参数更改信号屏蔽字。

假设当前的信号屏蔽字为mask，下表说明了how参数的可选值及其含义：

返回值说明：

sigprocmask函数调用成功返回0，出错返回-1。

3.6 sigpending

sigpending函数可以用于读取进程的未决信号集，该函数的函数原型如下：

int sigpending(sigset_t *set);

sigpending函数读取当前进程的未决信号集，并通过set参数传出。

该函数调用成功返回0，出错返回-1。

下面我们来实现一个demo，将前面的函数综合使用一下。

我们要实现下列步骤：

1、先用上述的函数将2号信号进行屏蔽（阻塞）。

2、使用kill命令或组合按键向进程发送2号信号。

3、此时2号信号会一直被阻塞，并一直处于pending（未决）状态。

4、使用sigpending函数获取当前进程的pending信号集进行验证。

#include <cstdio>
#include <unistd.h>
#include <signal.h>
void Printpending(sigset_t *pending)
{for (int i = 31; i > 0; i--){if (sigismember(pending, i)){printf("1");}else{printf("0");}}printf("\n");
}
int main()
{sigset_t set, oldset;sigemptyset(&set);sigemptyset(&oldset);sigaddset(&set, 2);                      // 将2号信号添加到set信号集中sigprocmask(SIG_SETMASK, &set, &oldset); // 阻塞2号信号sigset_t pending;sigemptyset(&pending);while (1){sigpending(&pending);   // 获取pendingprintf("pid:%d,",getpid());Printpending(&pending); // 打印pending位图sleep(1);}return 0;
}

可以看到，程序刚刚运行时，因为没有收到任何信号，所以此时该进程的pending表一直是全0，而当我们使用kill命令向该进程发送2号信号后，由于2号信号是阻塞的，因此2号信号一直处于未决状态，所以我们看到pending表中的第二个数字一直是1。

为了看到2号信号递达后pending表的变化，我们可以设置一段时间后，自动解除2号信号的阻塞状态，解除2号信号的阻塞状态后2号信号就会立即被递达。因为2号信号的默认处理动作是终止进程，所以为了看到2号信号递达后的pending表，我们可以将2号信号进行捕捉，让2号信号递达时执行我们所给的自定义动作。

#include <cstdio>
#include <unistd.h>
#include <signal.h>
void Printpending(sigset_t *pending)
{for (int i = 31; i > 0; i--){if (sigismember(pending, i)){printf("1");}else{printf("0");}}printf("\n");
}
void handler(int sig)
{printf("获得了一个信号,sig:%d\n",sig);
}
int main()
{signal(2,handler);sigset_t set, oldset;sigemptyset(&set);sigemptyset(&oldset);sigaddset(&set, 2);                      // 将2号信号添加到set信号集中sigprocmask(SIG_SETMASK, &set, &oldset); // 阻塞2号信号sigset_t pending;sigemptyset(&pending);int count=0;while (1){sigpending(&pending);   // 获取pendingprintf("pid:%d,",getpid());Printpending(&pending); // 打印pending位图sleep(1);count++;if(count==20){sigprocmask(SIG_SETMASK,&oldset,nullptr);//解除对2号信号的屏蔽printf("恢复成功\n");}}return 0;
}

此时就可以看到，进程收到2号信号后，该信号在一段时间内处于未决状态，当解除2号信号的屏蔽后，2号信号就会立即递达，执行我们所给的自定义动作，而此时的pending表也变回了全0，当我们准备递达时，会首先清空pending信号集中对应的信号位图（1->0）。

4. 捕捉信号

4.1 内核空间与用户空间

每一个进程都有自己的进程地址空间，该进程地址空间由内核空间和用户空间组成：

1、用户所写的代码和数据位于用户空间，通过用户级页表与物理内存之间建立映射关系。

2、内核空间存储的实际上是操作系统代码和数据，通过内核级页表与物理内存之间建立映射关系。

内核级页表是一个全局的页表，它用来维护操作系统的代码与进程之间的关系。

因此，在每个进程的进程地址空间中，用户空间是属于当前进程的，每个进程看到的代码和数据是完全不同的，但内核空间所存放的都是操作系统的代码和数据，所有进程看到的都是一样的内容。

需要注意的是，虽然每个进程都能够看到操作系统，但并不意味着每个进程都能够随时对其进行访问。

如何理解进程切换？

1、在当前进程的进程地址空间中的内核空间，找到操作系统的代码和数据。
2、执行操作系统的代码，将当前进程的代码和数据剥离下来，并换上另一个进程的代码和数据。
注意：当你访问用户空间时你必须处于用户态，当你访问内核空间时你必须处于内核态。

4.2 内核态和用户态

1、内核态通常用来执行操作系统的代码，是一种权限非常高的状态。

2、用户态是一种用来执行普通用户代码的状态，是一种受监管的普通状态。

进程收到信号之后，并不是立即处理信号，而是在合适的时候，这里所说的合适的时候实际上就是指从内核态切换回用户态的时候。

内核态和用户态之间是进行如何切换的？

从用户态切换为内核态通常有如下几种情况：

1、需要进行系统调用时。

2、当前进程的时间片到了，导致进程切换。

3、产生异常、中断、陷阱等。

同理，与上面对应，从内核态切换为用户态有如下情况：

1、系统调用返回时。

2、进程切换完毕。

3、异常、中断、陷阱等处理完毕。

由用户态切换为内核态我们称之为陷入内核。

每当我们需要陷入内核的时，本质上是因为我们需要执行操作系统的代码，比如系统调用函数是由操作系统实现的，我们要进行系统调用就必须先由用户态切换为内核态。

4.3 内核如何实现信号的捕捉

1、当我们在执行主控制流程的时候，可能因为某些情况而陷入内核，当内核处理完毕准备返回用户态时，就需要进行信号pending的检查。（此时仍处于内核态，有权力查看当前进程的pending位图）。

2、在查看pending位图时，如果发现有未决信号，并且该信号没有被阻塞，那么此时就需要该信号进行处理。

3、如果待处理信号的处理动作是默认或者忽略，则执行该信号的处理动作后清除对应的pending标志位，如果没有新的信号要递达，就直接返回用户态，从主控制流程中上次被中断的地方继续向下执行即可。

4、但如果待处理信号是自定义捕捉的，即该信号的处理动作是由用户提供的，那么处理该信号时就需要先返回用户态执行对应的自定义处理动作，执行完后再通过特殊的系统调用sigreturn再次陷入内核并清除对应的pending标志位，如果没有新的信号要递达，就直接返回用户态，继续执行主控制流程的代码。

当待处理信号是自定义捕捉时的情况比较复杂，可以借助下图进行记忆：

其中，该图形与直线有几个交点就代表在这期间有几次状态切换，而箭头的方向就代表着此次状态切换的方向，图形中间的圆点就代表着检查pending表。

4.4 sigaction

捕捉信号除了用前面用过的signal函数之外，我们还可以使用sigaction函数对信号进行捕捉，sigaction函数的函数原型如下：

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

sigaction函数可以读取和修改与指定信号相关联的处理动作，该函数调用成功返回0，出错返回-1。

参数说明：

1、signum代表指定信号的编号。

2、若act指针非空，则根据act修改该信号的处理动作。

3、若oldact指针非空，则通过oldact传出该信号原来的处理动作。

其中，参数act和oldact都是结构体指针变量，该结构体的定义如下：

struct sigaction {void(*sa_handler)(int);void(*sa_sigaction)(int, siginfo_t *, void *);sigset_t   sa_mask;int        sa_flags;void(*sa_restorer)(void);
};

结构体的第一个成员sa_handler：

1、将sa_handler赋值为常数SIG_IGN传给sigaction函数，表示忽略信号。
2、将sa_handler赋值为常数SIG_DFL传给sigaction函数，表示执行系统默认动作。
3、将sa_handler赋值为一个函数指针，表示用自定义函数捕捉信号，或者说向内核注册了一个信号处理函数。

结构体的第二个成员sa_sigaction：

sa_sigaction是实时信号的处理函数，我们不关心实时信号。

结构体的第三个成员sa_mask：

首先需要说明的是，当某个信号的处理函数被调用，内核自动将当前信号加入进程的信号屏蔽字，当信号处理函数返回时自动恢复原来的信号屏蔽字，这样就保证了在处理某个信号时，如果这种信号再次产生，那么它会被阻塞到当前处理结束为止。

说白了，系统不允许同一个信号同时递达，例如系统正在处理2号信号，就会将屏蔽这个2号信号（block表对应比特位由0置1），此时我们再发2号信号，将会直接被放在pending表中（未决状态）。

如果没有这个逻辑，当信号正在被处理时，我们重复发起相同的信号，那么此时信号的处理方法就会被递归式地调用，就可能导致内存资源被耗尽。

下面通过一个实验来验证上面的理论：

#include <iostream>
#include <cstdlib>
#include <unistd.h>
#include <signal.h>
void handler(int signum)
{std::cout << "hello signal:" << signum << std::endl;while (1){// 不断获取pending表sigset_t pending;sigpending(&pending);for (int i = 31; i > 0; i--){if (sigismember(&pending, i)){std::cout << "1";}else{std::cout << "0";}}std::cout << std::endl;sleep(2);}exit(0);
}
int main()
{struct sigaction act, oact;act.sa_handler = handler;sigemptyset(&act.sa_mask);act.sa_flags = 0;sigaction(2, &act, &oact); // 对2号信号进行捕捉while (1){std::cout << "hello world: " <<getpid()<< std::endl;sleep(1);}return 0;
}

大家来看上面这段代码，我们在信号处理函数中不断打印pending表，这个时候当我们重复发2号信号时，pending表中第二个比特位就会由0变1。

通过上面的结果，就可以证明信号在处理的过程中会被自动屏蔽。

如果在调用信号处理函数时，除了当前信号被自动屏蔽之外，还希望自动屏蔽另外一些信号，则用sa_mask字段说明这些需要额外屏蔽的信号，当信号处理函数返回时，自动恢复原来的信号屏蔽字。

结构体的第四个成员sa_flags：

sa_flags字段包含一些选项，这里直接将sa_flags设置为0即可。

结构体的第五个成员sa_restorer：

这个参数我们不用，在此不做深究。

5. 穿插话题——操作系统是如何运行的

5.1 硬件中断

1、中断向量表（函数指针数组）就是操作系统的⼀部分，启动就加载到内存中了。

2、通过外部硬件中断，操作系统就不需要对外设进行任何周期性的检测或者轮询。

3、由外部设备触发的，中断系统运行流程，叫做硬件中断。

5.2 时钟中断

1、进程可以在操作系统的指挥下，被调度，被执行，那么操作系统自己被谁指挥，被谁推动执行呢？

2、外部设备可以触发硬件中断，但是这个是需要用户或者设备自己触发，有没有自己可以定期触发的设备?

在CPU内部，集成了时钟源，会定期向CPU发起中断，CPU就会根据中断号执行中断方法，这样一来，操作系统就在硬件的推动下，自动调度起来了。

5.3 死循环

操作系统自己不做任何事情，需要什么功能，就向中断向量表里面添加方法即可。

操作系统的本质：就是⼀个死循环！

void main(void) /* 这⾥确实是void，并没错。 */ 
{ /* 在startup 程序(head.s)中就是这样假设的。 */ .../** 注意!! 对于任何其它的任务，'pause()'将意味着我们必须等待收到⼀个信号才会返 * 回就绪运⾏态，但任务0（task0）是唯⼀的意外情况（参⻅'schedule()'），因为任 * 务0 在任何空闲时间⾥都会被激活（当没有其它任务在运⾏时）， * 因此对于任务0'pause()'仅意味着我们返回来查看是否有其它任务可以运⾏，如果没 * 有的话我们就回到这⾥，⼀直循环执⾏'pause()'。 */for (;;)pause();
} // end main

5.4 软中断

• 上述外部硬件中断，需要硬件设备触发。

• 有没有可能，因为软件原因，也触发上面的逻辑？有！

• 为了让操作系统支持进行系统调用，CPU也设计了对应的汇编指令(int或者syscall)，可以让CPU内部触发中断逻辑。

• 系统调用的过程，其实就是先int 0x80、syscall陷入内核，本质就是触发软中断，CPU就会自动执行系统调用的处理方法，而这个方法会根据系统调用号，自动查表，执行对应的方法

• 系统调用号的本质：数组下标。

• 可是为什么我们用的系统调用，从来没有见过什么 int 0x80 或者 syscall 呢？都是直接调用上层的函数的啊？

• 那是因为Linux的gnuC标准库，给我们把几乎所有的系统调用全部封装了，OS只提供系统调用号。

说到这里，我们之前说到的缺页中断、内存碎片处理、除零野指针错误等，这些问题，全部都会被转换成为CPU内部的软中断，然后走中断处理例程，完成所有处理。

有的是进行申请内存，填充页表，进行映射的（这里对应之前说过的一个点，就是当我们向系统申请空间资源时，OS不会立马在物理地址空间上给我们开辟好，而是先会在虚拟地址空间上开辟对应空间，等我们真的要用的时候，再为我们开辟实际的物理内存空间，这一过程就是通过缺页中断实现的）；有的是用来处理内存碎篇的；有的是用来给目标进行发送信号，杀掉进程等等。

所以综上，我们可以得到一个重要结论：操作系统就是躺在中断处理例程上的代码块。

注意：

• CPU内部的软中断，比如int 0x80或者syscall，我们叫做陷阱。

• CPU内部的软中断，比如除零/野指针等，我们叫做异常。

5.6 如何理解内核态和用户态

• 操作系统无论怎么切换进程，都能找到同⼀个操作系统！换句话说操作系统系统调用方法的执行，是在进程的地址空间中执行的。

• 用户态就是执行用户[0,3]GB时所处的状态。

• 内核态就是执行内核[3,4]GB时所处的状态。

6. 可重入函数

上面这张图就说明了一个现象：函数重入。

insert函数被不同的控制流程调用,有可能在第⼀次调用还没返回时就再次进入该函数,这称为重入。

最终结果是，main函数和sighandler函数先后向链表中插入了两个结点，但最后只有node1结点真正插入到了链表中，而node2结点就再也找不到了，造成了内存泄漏。

如果一个函数符合以下条件之一则是不可重入的：

1、调用了malloc或free，因为malloc也是用全局链表来管理堆的。

2、调用了标志I/O库函数，因为标准I/O库的很多实现都以不可重入的方式使用全局数据结构。

7. volatile

volatile是C语言的一个关键字，该关键字的作用是保持内存的可见性。

先来看一段代码：

#include <iostream>
#include <cstdlib>
#include <unistd.h>
#include <signal.h>
int flag=0;
void handler(int sig)
{std::cout<<"更改全局变量,"<<flag<<"->1"<<std::endl;flag=1;
}
int main()
{signal(2,handler);while(!flag){}std::cout<<"程序正常退出"<<std::endl;return 0;
}