进程模型

在Linux系统中进程由以下三部分组成：

进程控制块PCB

有了这个数据结构，进程才能成为内核调度的一个基本单位接受内核的调度。同时，这个结构还记录着进程所占用的各项资源。

Linux系统为了节省进程控制块所占的内存空间，把每个进程控制块分成两部分。

一部分常驻内存，不管进程是否正占有处理器运行，系统经常会对这部分内容进行查询和处理，常驻部分内容包括：进程状态、优先数、过程特征、数据段始址、等待原因和队列指针等，这是进行处理器调度时必须使用的一些主要信息。

另一部分非常驻内存，当进程不占有处理器时，系统不会对这部分内容进行查询和处理，因此这部分内容可以存放在磁盘的对换区中，它随用户的程序和数据部分换进或换出内存。

数据段

Linux系统把进程的数据段又划分成三部分:

  1. 用户栈区(供用户程序使用的信息区)；

  2. 用户数据区(包括用户工作数据和非可重入的程序段)；

  3. 系统数据区(包括系统变量和对换信息)。

正文段

正文段是可重入的程序，能被若干进程共享。为了管理可共享的正文段，Linux设置了一张正文表，每个正文段都占用一个表目，用来指出该正文段在内存和磁盘上的位置、段的大小以及调用该段的进程数等情况。

进程状态

  1. R (task_running) : 可执行状态

    只有在该状态的进程才可能在CPU上运行。而同一时刻可能有多个进程处于可执行状态，这些进程的task_struct结构（进程控制块）被放入对应CPU的可执行队列中（一个进程最多只能出现在一个CPU的可执行队列中）。进程调度器的任务就是从各个CPU的可执行队列中分别选择一个进程在该CPU上运行。

    很多操作系统教科书将正在CPU上执行的进程定义为RUNNING状态、而将可执行但是尚未被调度执行的进程定义为READY状态，这两种状态在linux下统一为 TASK_RUNNING状态。

  2. S (task_interruptible): 可中断的睡眠状态

    处于这个状态的进程因为等待某某事件的发生（比如等待socket连接、等待信号量），而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时（由外部中断触发、或由其他进程触发），对应的等待队列中的一个或多个进程将被唤醒。

    通过ps命令我们会看到，一般情况下，进程列表中的绝大多数进程都处于task_interruptible状态（除非机器的负载很高）。毕竟CPU就这么一两个，进程动辄几十上百个，如果不是绝大多数进程都在睡眠，CPU又怎么响应得过来。

  3. D (task_uninterruptible): 不可中断的睡眠状态

    与task_interruptible状态类似，进程处于睡眠状态，但是此刻进程是不可中断的。不可中断，指的并不是CPU不响应外部硬件的中断，而是指进程不响应异步信号。

    绝大多数情况下，进程处在睡眠状态时，总是应该能够响应异步信号的。但是uninterruptible sleep 状态的进程不接受外来的任何信号，因此无法用kill杀掉这些处于D状态的进程，无论是”kill”, “kill -9″还是”kill -15″，这种情况下，一个可选的方法就是reboot。

    处于uninterruptible sleep状态的进程通常是在等待IO，比如磁盘IO，网络IO，其他外设IO，如果进程正在等待的IO在较长的时间内都没有响应，那么就被ps看到了，同时也就意味着很有可能有IO出了问题，可能是外设本身出了故障，也可能是比如挂载的远程文件系统已经不可访问了.

    而task_uninterruptible状态存在的意义就在于，内核的某些处理流程是不能被打断的。如果响应异步信号，程序的执行流程中就会被插入一段用于处理异步信号的流程（这个插入的流程可能只存在于内核态，也可能延伸到用户态），于是原有的流程就被中断了。

    在进程对某些硬件进行操作时（比如进程调用read系统调用对某个设备文件进行读操作，而read系统调用最终执行到对应设备驱动的代码，并与对应的物理设备进行交互），可能需要使用task_uninterruptible状态对进程进行保护，以避免进程与设备交互的过程被打断，造成设备陷入不可控的状态。这种情况下的task_uninterruptible状态总是非常短暂的，通过ps命令基本上不可能捕捉到。

  4. T(task_stopped or task_traced)：暂停状态或跟踪状态

    向进程发送一个sigstop信号，它就会因响应该信号而进入task_stopped状态（除非该进程本身处于task_uninterruptible状态而不响应信号）。（sigstop与sigkill信号一样，是非常强制的。不允许用户进程通过signal系列的系统调用重新设置对应的信号处理函数。） 向进程发送一个sigcont信号，可以让其从task_stopped状态恢复到task_running状态。

    当进程正在被跟踪时，它处于task_traced这个特殊的状态。“正在被跟踪”指的是进程暂停下来，等待跟踪它的进程对它进行操作。比如在gdb中对被跟踪的进程下一个断点，进程在断点处停下来的时候就处于task_traced状态。而在其他时候，被跟踪的进程还是处于前面提到的那些状态。

    对于进程本身来说，task_stopped和task_traced状态很类似，都是表示进程暂停下来。 而task_traced状态相当于在task_stopped之上多了一层保护，处于task_traced状态的进程不能响应sigcont信号而被唤醒。只能等到调试进程通过ptrace系统调用执行ptrace_cont、ptrace_detach等操作（通过ptrace系统调用的参数指定操作），或调试进程退出，被调试的进程才能恢复task_running状态。

  5. Z (task_dead - exit_zombie)：退出状态，进程成为僵尸进程

    在Linux进程的状态中，僵尸进程是非常特殊的一种，它是已经结束了的进程，但是没有从进程表中删除。太多了会导致进程表里面条目满了，进而导致系统崩溃，倒是不占用其他系统资源。

    它已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集，除此之外，僵尸进程不再占有任何内存空间。

    进程在退出的过程中，处于TASK_DEAD状态。在这个退出过程中，进程占有的所有资源将被回收，除了task_struct结构（以及少数资源）以外。于是进程就只剩下task_struct这么个空壳，故称为僵尸。

    之所以保留task_struct，是因为task_struct里面保存了进程的退出码、以及一些统计信息。而其父进程很可能会关心这些信息。比如在shell中，$?变量就保存了最后一个退出的前台进程的退出码，而这个退出码往往被作为if语句的判断条件。

    当然，内核也可以将这些信息保存在别的地方，而将task_struct结构释放掉，以节省一些空间。但是使用task_struct结构更为方便，因为在内核中已经建立了从pid到task_struct查找关系，还有进程间的父子关系。释放掉task_struct，则需要建立一些新的数据结构，以便让父进程找到它的子进程的退出信息。

    子进程在退出的过程中，内核会给其父进程发送一个信号，通知父进程来“收尸”。 父进程可以通过wait系列的系统调用（如wait4、waitid）来等待某个或某些子进程的退出，并获取它的退出信息。然后wait系列的系统调用会顺便将子进程的尸体（task_struct）也释放掉。

    这个信号默认是SIGCHLD，但是在通过clone系统调用创建子进程时，可以设置这个信号。

    如果他的父进程没安装SIGCHLD信号处理函数调用wait或waitpid()等待子进程结束，又没有显式忽略该信号，那么它就一直保持僵尸状态，子进程的尸体（task_struct）也就无法释放掉。

    如果这时父进程结束了，那么init进程自动会接手这个子进程，为它收尸，它还是能被清除的。但是如果如果父进程是一个循环，不会结束，那么子进程就会一直保持僵尸状态，这就是为什么系统中有时会有很多的僵尸进程。

    当进程退出的时候，会将它的所有子进程都托管给别的进程（使之成为别的进程的子进程）。托管的进程可能是退出进程所在进程组的下一个进程（如果存在的话），或者是1号进程。所以每个进程、每时每刻都有父进程存在。除非它是1号进程。1号进程，pid为1的进程，又称init进程。

父子进程的联系

在父进程创建子进程之后，父、子进程除了pid外，几乎所有的部分几乎一样，子进程创建时拷贝父进程PCB中大部分内容，而PCB的内容实际上是各种数据、代码的地址或索引表地址，所以复制了PCB中这些指针实际就等于获取了全部父进程可访问数据。所以简单来说，创建新进程需要复制整个PCB，之后操作系统将PCB添加到进程核心堆栈底部，这样就可以被操作系统感知和调度了。

父、子进程共享全部数据，但并不是说他们就是对同一块数据进行操作，子进程在读写数据时会通过写时复制机制将公共的数据重新拷贝一份，之后在拷贝出的数据上进行操作。如果子进程想要运行自己的代码段，还可以通过调用execv()函数重新加载新的代码段，之后就和父进程独立开了。我们在shell中执行程序就是通过shell进程先fork()一个子进程再通过execv()重新加载新的代码段的过程。

子进程得到父进程的数据空间，堆和栈的副本，但是两者是互相独立的，子进程数据空间中的内容是父进程的完整拷贝，指令指针也完全相同，子进程拥有父进程当前运行到的位置（两进程的程序计数器pc值相同，也就是说，子进程是从fork返回处开始执行的），但有一点不同，如果fork成功，子进程中fork的返回值是0，父进程中fork的返回值是子进程的进程号，如果fork不成功，父进程会返回错误。

由子进程自父进程继承到:

  1. 进程的资格(真实(real)/有效(effective)/已保存(saved)用户号(UIDs)和组号(GIDs))

  2. 环境(environment) 子进程复制的不仅是父进程的代码和数据，还包括状态，这个状态就包含有PC指针寄存器的值。也就是说子进程创建完成后，他和父进程一样，PC指针都指向下一条语句，因此子进程是从自身创建完成后的地方继续运行，而父进程运行过得代码将不再运行。

  3. 堆栈

  4. 内存

  5. 打开文件的描述符(注意对应的文件的位置由父子进程共享，这会引起含糊情况)

  6. 执行时关闭(close-on-exec) 标志 (译者注：close-on-exec标志可通过fnctl()对文件描述符设置，POSIX.1要求所有目录流都必须在exec函数调用时关闭。更详细说明，参见《UNIX环境高级编程》 W. R. Stevens, 1993, 尤晋元等译(以下简称《高级编程》), 3.13节和8.9节)

  7. 信号(signal)控制设定

  8. nice值 (译者注：nice值由nice函数设定，该值表示进程的优先级，数值越小，优先级越高)

  9. 进程调度类别(scheduler class)(译者注：进程调度类别指进程在系统中被调度时所属的类别，不同类别有不同优先级，根据进程调度类别和nice值，进程调度程序可计算出每个进程的全局优先级(Global process prority)，优先级高的进程优先执行)

  10. 进程组号

  11. 对话期ID(Session ID) (译者注：译文取自《高级编程》，指：进程所属的对话期(session)ID， 一个对话期包括一个或多个进程组， 更详细说明参见《高级编程》9.5节)

  12. 当前工作目录

  13. 根目录 (译者注：根目录不一定是“/”，它可由chroot函数改变)

  14. 文件方式创建屏蔽字(file mode creation mask (umask))(译者注：译文取自《高级编程》，指：创建新文件的缺省屏蔽字)

  15. 资源限制

  16. 控制终端

注意：

  1. Linux系统中采用“写时拷贝”的技术，创建进程时，父子共享同一个地址空间，在需要写入的时候才进行地址空间的复制。

  2. 打开的文件描述符在父子进程之间是共享的。当close一个文件描述符时候会将文件描述符的引用计数-1。只有当引用计数为0才能真正关闭该文件描述符；

子进程所独有:

  1. fork的返回值

  2. 进程ID

  3. 不同的父进程ID

  4. 子进程的tms_utime,tms_stime,tms_cutime以及tms_ustime设置为0

  5. 父进程设置的锁，子进程不继承

  6. 子进程的未决告警被清除

  7. 子进程的未决信号集设置为空集

特别注意:

程序中fork与I/O函数之间的关系

write是不带缓冲的，因为在fork之前调⽤用write，所以其数据只写到标准输出一次。

标准I/O是缓冲的，如果标准输出到终端设备，则它是行缓冲，否则它是全缓冲。

当以交互方式运行该程序时，只得到printf输出的⾏一次，因为标准输出到终端缓冲区由换⾏行符冲洗。

将标准输出重定向到⼀个文件时，由于缓冲区是全缓冲，遇到换⾏行符不输出，当调用fork时，其printf的数据仍然在缓冲区中，缓冲区被复制到子进程中。于是父⼦进程都有了带该行内容的标准I/O缓冲区，所以每个进程终⽌时，会冲洗其缓冲区中的数据，得到一个printf输出两次。

子进程会影响父进程的变量

不同的进程使用不同的地址空间，子进程被创建之后，父进程的全局变量、静态变量和 fork 处的静态变量会复制到子进程的地址空间中，自此以后，二者开始“各行其是”，互不干扰，所以，所有的“变量”都将各自独立。而对于指针来说，虽然复制过，指针做为“变量”已经互不干扰，但是你在进行指针操作的时候，会通过物理地址的映射反映到父进程当中。

进程创建与结束

进程有两种创建方式，一种是操作系统创建的一种是父进程创建的。从计算机启动到终端执行程序的过程为：0号进程 -> 1号内核进程 -> 1号用户进程(init进程) -> getty进程 -> shell进程 -> 命令行执行进程。所以我们在命令行中通过 ./program执行可执行文件时，所有创建的进程都是shell进程的子进程，这也就是为什么shell一关闭，在shell中执行的进程都自动被关闭的原因。从shell进程到创建其他子进程需要通过以下接口。

相关接口：

创建进程

pid_t fork(void);

返回值：出错返回-1；父进程中返回pid > 0；子进程中pid == 0

结束进程

void exit(int status);

status是退出状态，保存在全局变量中S?，通常0表示正常退出。

获得PID

pid_t getpid(void);

返回调用者pid。

获得父进程PID

pid_t getppid(void);

返回父进程pid。

其他补充

正常退出方式：

exit()、_exit()、return（在main中）。

exit()和_exit()区别：exit()是对_exit()的封装，都会终止进程并做相关收尾工作，最主要的区别是_exit()函数关闭全部描述符和清理函数后不会刷新流，但是exit()会在调用_exit()函数前刷新数据流。

return和exit()区别：exit()是函数，但有参数，执行完之后控制权交给系统。return若是在调用函数中，执行完之后控制权交给调用进程，若是在main函数中，控制权交给系统。

异常退出方式：

abort()、终止信号。

僵尸进程、孤儿进程

linux系统启动后，第一个被创建的用户态进程就是init进程。它有两项使命：

  1. 执行系统初始化脚本，创建一系列的进程（它们都是init进程的子孙）；

  2. 在一个死循环中等待其子进程的退出事件，并调用waitid系统调用来完成“收尸”工作；

init进程不会被暂停、也不会被杀死（这是由内核来保证的）。它在等待子进程退出的过程中处于task_interruptible状态，“收尸”过程中则处于task_running状态。

父进程在调用fork接口之后和子进程已经可以独立开，之后父进程和子进程就以未知的顺序向下执行（异步过程）。所以父进程和子进程都有可能先执行完。当父进程先结束，子进程此时就会变成孤儿进程，不过这种情况问题不大，孤儿进程会自动向上被init进程收养，init进程完成对状态收集工作。而且这种过继的方式也是守护进程能够实现的因素。如果子进程先结束，父进程并未调用wait或者waitpid获取进程状态信息，那么子进程描述符就会一直保存在系统中，这种进程称为僵尸进程。

相关接口：

回收进程（1）

pid_t wait(int *status);

一旦调用wait()，就会立即阻塞自己，wait()自动分析某个子进程是否已经退出，如果找到僵尸进程就会负责收集和销毁，如果没有找到就一直阻塞在这里。

status：指向子进程结束状态值。

回收进程（2）

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

返回值：返回pid：返回收集的子进程id。返回-1：出错。返回0：没有被手机的子进程。

pid：子进程识别码，控制等待哪些子进程。

pid < -1，等待进程组识别码为pid绝对值的任何进程。

pid = -1，等待任何子进程。

pid = 0，等待进程组识别码与目前进程相同的任何子进程。

pid > 0，等待任何子进程识别码为pid的子进程。

status：指向返回码的指针。

options：选项决定父进程调用waitpid后的状态。

options = WNOHANG，即使没有子进程退出也会立即返回。

options = WUNYRACED，子进程进入暂停马上返回，但结束状态不予理会。

僵尸进程解决办法：

  1. 改写父进程，在子进程死后要为它收尸。

    具体做法是接管SIGCHLD信号。子进程死后，会发送SIGCHLD信号给父进程，父进程收到此信号后，执行 waitpid()函数为子进程收尸。这是基于这样的原理：就算父进程没有调用wait，内核也会向它发送SIGCHLD消息，尽管对的默认处理是忽略，如果想响应这个消息，可以设置一个处理函数。

  2. 把父进程杀掉。

    父进程死后，僵尸进程成为”孤儿进程”，过继给1号进程init，init始终会负责清理僵尸进程．它产生的所有僵尸进程也跟着消失。如：

     kill -9 `ps -ef | grep "Process Name" | awk '{ print $3 }'`

    其中，“Process Name”为处于zombie状态的进程名。

  3. 杀父进程不行的话，就尝试用skill -t TTY关闭相应终端，TTY是进程相应的tty号(终端号)。但是，ps可能会查不到特定进程的tty号，这时就需要自己判断了。

  4. 重启系统，这也是最常用到方法之一。

线程模型

在现代操作系统中，进程支持多线程。进程是资源管理的最小单元；而线程是程序执行的最小单元。一个进程的组成实体可以分为两大部分：线程集合和资源集合。进程中的线程是动态的对象；代表了进程指令的执行。资源，包括地址空间、打开的文件、用户信息等等，由进程内的线程共享。线程有自己的私有数据：程序计数器，栈空间以及寄存器。

传统进程的缺点:

现实中有很多需要并发处理的任务，如数据库的服务器端、网络服务器、大容量计算等。一个任务是一个进程，传统的UNIX进程是单线程（执行流）的，单线程意味着程序必须是顺序执行，单个任务不能并发；既在一个时刻只能运行在一个处理器上，因此不能充分利用多处理器框架的计算机。如果采用多进程的方法，即把一个任务用多个进程解决，则有如下问题：

  1. fork一个子进程的消耗是很大的，fork是一个昂贵的系统调用，即使使用现代的写时复制(copy-on-write)技术。
  2. 各个进程拥有自己独立的地址空间，进程间的协作需要复杂的IPC技术，如消息传递和共享内存等。

多线程的优缺点:

线程：其实可以先简单理解成cpu的一个执行流，指令序列。多支持多线程的程序(进程)可以取得真正的并行(parallelism)，且由于共享进程的代码和全局数据，故线程间的通信是方便的。它的缺点也是由于线程共享进程的地址空间，因此可能会导致竞争，因此对某一块有多个线程要访问的数据需要一些同步技术。

线程是操作系统能够调度和执行的基本单位，在Linux中也被称之为轻量级进程。从定义中可以看出，线程它是操作系统的概念，在不同的操作系统中的实现是不同的.

对于Linux操作系统而言，它对Thread的实现方式比较特殊。在Linux内核中，其实是没有线程的概念的，它把所有的线程当做标准的进程来实现，也就是说Linux内核，并没有为线程提供任何特殊的调度语义，也没有为线程实现特定的数据结构。取而代之的是，线程只是一个与其他进程共享某些资源的进程。每一个线程拥有一个唯一的task_struct结构，Linux内核它仅仅把线程当做一个正常的进程，或者说是轻量级进程，LWP(Lightweight processes)。

既然称作轻量级进程，可见其本质仍然是进程，与普通进程相比，LWP与其它进程共享所有（或大部分）逻辑地址空间和系统资源，一个进程可以创建多个LWP，这样它们共享大部分资源；LWP有它自己的进程标识符，并和其他进程有着父子关系；这是和类Unix操作系统的系统调用vfork()生成的进程一样的。LWP由内核管理并像普通进程一样被调度。Linux内核是支持LWP的典型例子。Linux内核在 2.0.x版本就已经实现了轻量进程，应用程序可以通过一个统一的clone()系统调用接口，用不同的参数指定创建轻量进程还是普通进程，通过参数决定子进程和父进程共享的资源种类和数量，这样就有了轻重之分。在内核中， clone()调用经过参数传递和解释后会调用do_fork()，这个核内函数同时也是fork()、vfork()系统调用的最终实现。

在大多数系统中，LWP与普通进程的区别也在于它只有一个最小的执行上下文和调度程序所需的统计信息，而这也是它之所以被称为轻量级的原因。

因为LWP之间共享它们的大部分资源，所以它在某些应用程序就不适用了；这个时候就要使用多个普通的进程了。例如，为了避免内存泄漏（a process can be replaced by another one）和实现特权分隔（processes can run under other credentials and have other permissions）。

一个应用程序启动后会在内存中创建一个执行副本，这就是进程。Linux 的内核是一个 Monolithic Kernel（宏内核），因此可以看作一个进程。也就是开机的时候，磁盘的内核镜像被导入内存作为一个执行副本，成为内核进程。

进程可以分成用户态进程和内核态进程两类。用户态进程通常是应用程序的副本，内核态进程就是内核本身的进程。如果用户态进程需要申请资源，比如内存，可以通过系统调用向内核申请。

那么用户态进程如果要执行程序，是否也要向内核申请呢？

程序在现代操作系统中并不是以进程为单位在执行，而是以一种轻量级进程（Light Weighted Process），也称作线程（Thread）的形式执行。

一个进程可以拥有多个线程。进程创建的时候，一般会有一个主线程随着进程创建而创建。

如果进程想要创造更多的线程，就需要思考一件事情，这个线程创建在用户态还是内核态。

你可能会问，难道不是用户态的进程创建用户态的线程，内核态的进程创建内核态的线程吗？

其实不是，进程可以通过 API 创建用户态的线程，也可以通过系统调用创建内核态的线程，接下来我们说说用户态的线程和内核态的线程。

用户态和内核态

Kernel 运行在超级权限模式（Supervisor Mode）下，所以拥有很高的权限。按照权限管理的原则，多数应用程序应该运行在最小权限下。因此，很多操作系统，将内存分成了两个区域：

  • 内核空间（Kernal Space），这个空间只有内核程序可以访问；
  • 用户空间（User Space），这部分内存专门给应用程序使用。

用户空间中的代码被限制了只能使用一个局部的内存空间，我们说这些程序在用户态（User Mode） 执行。内核空间中的代码可以访问所有内存，我们称这些程序在内核态（Kernal Mode） 执行。

当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态（或简称为内核态）。此时处理器处于特权级最高的（0级）内核 代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。当进程在执行用户自己的代码时，则称其处于用户运行 态（用户态）。即此时处理器在特权级最低的（3级）用户代码中运行。当正在执行用户程序而突然被中断程序中断时，此时用户程序也可以象征性地称为处于进程的内核态。因为中断处理程序将使用当前进程的内核栈。这与处于内核态的进程的状态有些类似。

内核态与用户态是操作系统的两种运行级别, 跟intel cpu没有必然的联系, intel cpu提供Ring0-Ring3三种级别的运行模式，Ring0级别最高，Ring3最低。

Linux使用了Ring3级别运行用户态，Ring0作为 内核态，没有使用Ring1和Ring2。Ring3状态不能访问Ring0的地址空间，包括代码和数据。Linux进程的4GB地址空间，3G-4G部分大家是共享的，是内核态的地址空间，这里存放在整个内核的代码和所有的内核模块，以及内核所维护的数据。

用户运行一个程序，该程序所创建的进程开始是运行在用户态的，如果要执行文件操作，网络数据发送等操作，必须通过write，send等系统调用，这些系统调用会调用内核中的代码来完成操作，这时，必须切换到Ring0，然后进入3GB-4GB中的内核地址空间去执行这些代码完成操作，完成后，切换回Ring3，回到用户态。这样，用户态的程序就不能 随意操作内核地址空间，具有一定的安全保护作用。至于说保护模式，是说通过内存页表操作等机制，保证进程间的地址空间不会互相冲突，一个进程的操作不会修改另一个进程的地址空间中的数据。

用户态切换到内核态的3种方式:

a. 系统调用

这是用户态进程主动要求切换到内核态的一种方式，用户态进程通过系统调用申请使 用操作系统提供的服务程序完成工作，比如前例中fork()实际上就是执行了一个创建新进程的系统调用。而系统调用的机制其核心还是使用了操作系统为用户 特别开放的一个中断来实现，例如Linux的int 80h中断。

b. 异常

当CPU在执行运行在用户态下的程序时，发生了某些事先不可知的异常，这时会触发由当前运行进程切换到处理此异常的内核相关程序中，也就转到了内核态，比如缺页异常。

c. 外围设备的中断

当外围设备完成用户请求的操作后，会向CPU发出相应的中断信号，这时CPU会 暂停执行下一条即将要执行的指令转而去执行与中断信号对应的处理程序，如果先前执行的指令是用户态下的程序，那么这个转换的过程自然也就发生了由用户态到 内核态的切换。比如硬盘读写操作完成，系统会切换到硬盘读写的中断处理程序中执行后续操作等。

这3种方式是系统在运行时由用户态转到内核态的最主要方式，其中系统调用可以认为是用户进程主动发起的，异常和外围设备中断则是被动的。

用户态线程 & 内核态线程

用户态线程也称作用户级线程（User Level Thread）。操作系统内核并不知道它的存在，它完全是在用户空间中创建。对操作系统来说，用户级线程具有不可见性，也称透明性。用户级线程的一个缺点，这些线程只能占用一个核，所以做不到并行加速，而且由于用户线程的透明性，操作系统是不能主动切换线程的，换句话讲，如果 A，B 是同一个进程的两个线程的话， A 正在运行的时候，线程 B 想要运行的话，只能等待 A 主动放弃 CPU，也就是主动调用 pthread_yield 函数.

用户级线程有很多优势，比如。

  • 管理开销小：创建、销毁不需要系统调用。
  • 切换成本低：用户空间程序可以自己维护，不需要走操作系统调度。

但是这种线程也有很多的缺点。

  • 与内核协作成本高：比如这种线程完全是用户空间程序在管理，当它进行 I/O 的时候，无法利用到内核的优势，需要频繁进行用户态到内核态的切换。
  • 线程间协作成本高：设想两个线程需要通信，通信需要 I/O，I/O 需要系统调用，因此用户态线程需要支付额外的系统调用成本。
  • 无法利用多核优势：比如操作系统调度的仍然是这个线程所属的进程，所以无论每次一个进程有多少用户态的线程，都只能并发执行一个线程，因此一个进程的多个线程无法利用多核的优势。
  • 操作系统无法针对线程调度进行优化：当一个进程的一个用户态线程阻塞（Block）了，操作系统无法及时发现和处理阻塞问题，它不会更换执行其他线程，从而造成资源浪费。

内核态线程也称作内核级线程（Kernel Level Thread）。操作系统内核知道线程的存在，就可以像调度多个进程一样，把这些线程放在好几个 CPU 核心上，就能做到实际上的并行了。这种线程执行在内核态，可以通过系统调用创造一个内核级线程。线程可见，假如线程 A 阻塞了，与他同属一个进程的线程也不会被阻塞。这是内核级线程的绝对优势

内核级线程有很多优势。

  • 可以利用多核 CPU 优势：内核拥有较高权限，因此可以在多个 CPU 核心上执行内核线程。
  • 操作系统级优化：内核中的线程操作 I/O 不需要进行系统调用；一个内核线程阻塞了，可以立即让另一个执行。

当然内核线程也有一些缺点。

  • 创建成本高：创建的时候需要系统调用，也就是切换到内核态。
  • 扩展性差：内核态线程线程表是存放在操作系统固定的表格空间或者堆栈空间里，所以内核级线程的数量是有限的，扩展性比不上用户级线程。
  • 切换成本较高：每次切换线程，就需要「陷入」内核态，而操作系统从用户态到内核态的转变是有开销的，所以说内核级线程切换的代价要比用户级线程大。

映射关系

线程简单理解，就是要执行一段程序。程序不会自发的执行，需要操作系统进行调度。我们思考这样一个问题，如果有一个用户态的进程，它下面有多个线程。如果这个进程想要执行下面的某一个线程，应该如何做呢？

这时，比较常见的一种方式，就是将需要执行的程序，让一个内核线程去执行。毕竟，内核线程是真正的线程。因为它会分配到 CPU 的执行资源。

如果一个进程所有的线程都要自己调度，相当于在进程的主线程中实现分时算法调度每一个线程，也就是所有线程都用操作系统分配给主线程的时间片段执行。这种做法，相当于操作系统调度进程的主线程；进程的主线程进行二级调度，调度自己内部的线程。

这样操作劣势非常明显，比如无法利用多核优势，每个线程调度分配到的时间较少，而且这种线程在阻塞场景下会直接交出整个进程的执行权限。

由此可见，用户态线程创建成本低，问题明显，不可以利用多核。内核态线程，创建成本高，可以利用多核，切换速度慢。因此通常我们会在内核中预先创建一些线程，并反复利用这些线程。这样，用户态线程和内核态线程之间就构成了下面 3 种可能的关系：

多对一（Many to One）

多对一线程模型中，线程的创建、调度、同步的所有细节全部由进程的用户空间线程库来处理。用户态线程的很多操作对内核来说都是透明的，因为不需要内核来接管，这意味不需要内核态和用户态频繁切换。线程的创建、调度、同步处理速度非常快。当然线程的一些其他操作还是要经过内核，如IO读写。这样导致了一个问题：当多线程并发执行时，如果其中一个线程执行IO操作时，内核接管这个操作，如果IO阻塞，用户态的其他线程都会被阻塞，因为这些线程都对应同一个内核调度实体。在多处理器机器上，内核不知道用户态有这些线程，无法把它们调度到其他处理器，也无法通过优先级来调度。这对线程的使用是没有意义的！

一对一（One to One）

一对一模型中，每个用户线程都对应各自的内核调度实体。内核会对每个线程进行调度，可以调度到其他处理器上面。当然由内核来调度的结果就是：线程的每次操作会在用户态和内核态切换。另外，内核为每个线程都映射调度实体，如果系统出现大量线程，会对系统性能有影响。但该模型的实用性还是高于多对一的线程模型。

多对多（Many To Many）

多对多模型中，结合了1：1和M：1的优点，避免了它们的缺点。每个线程可以拥有多个调度实体，也可以多个线程对应一个调度实体。听起来好像非常完美，但线程的调度需要由内核态和用户态一起来实现。可想而知，多个对象操作一个东西时，肯定要一些其他的同步机制。用户态和内核态的分工合作导致实现该模型非常复杂。NPTL曾经也想使用该模型，但它太复杂，要对内核进行大范围改动，所以还是采用了一对一的模型！！！

LinuxThreads

LinuxThreads是linux平台上使用过的一个线程库。它所实现的就是基于内核轻量级进程的"一对一"线程模型，一个线程实体对应一个核心轻量级进程，而线程之间的管理在核外函数库中实现。对于LinuxThreads，它使用(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND)参数来调用clone创建"线程"，表示共享内存、共享文件系统访问计数、共享文件描述符表，以及共享信号处理方式。

管理线程

LinuxThreads最初的设计相信相关进程之间的上下文切换速度很快，因此每个内核线程足以处理很多相关的用户级线程。LinuxThreads非常出名的一个特性就是管理线程（manager thread）。在LinuxThreads中，专门为每一个进程构造了一个管理线程，负责处理线程相关的管理工作。当进程第一次调用pthread_create创建一个线程的时候就会创建并启动管理线程。

在一个进程空间内，管理线程与其他线程之间通过一对"管理管道（manager_pipe[2]）“来通讯，该管道在创建管理线程之前创建，在成功启动了管理线程之后，管理管道的读端和写端分别赋给两个全局变量__pthread_manager_reader和__pthread_manager_request，之后，每个用户线程都通过__pthread_manager_request向管理线程发请求，但管理线程本身并没有直接使用__pthread_manager_reader，管道的读端（manager_pipe[0]）是作为__clone()的参数之一传给管理线程的，管理线程的工作主要就是监听管道读端，并对从中取出的请求作出反应。

管理线程在进行一系列初始化工作后，进入while(1)循环。在循环中，线程以2秒为timeout查询（__poll()）管理管道的读端。在处理请求前，检查其父线程是否已退出，如果已退出就退出整个进程。如果有退出的子线程需要清理，则进行清理。然后才是读取管道中的请求，根据请求类型执行相应操作（switch-case）。

每个LinuxThreads线程都同时具有线程id和进程id，其中进程id就是内核所维护的进程号，而线程id则由LinuxThreads分配和维护。

LinuxThreads的局限性

LinuxThreads的设计通常都可以很好地工作；但是在压力很大的应用程序中，它的性能、可伸缩性和可用性都会存在问题。下面让我们来看一下LinuxThreads设计的一些局限性：

  • 进程id问题：linux内核并不支持真正意义上的线程，LinuxThreads是用与普通进程具有同样内核调度视图的轻量级进程来实现线程支持的。这些轻量级进程拥有独立的进程id，在进程调度、信号处理、IO等方面享有与普通进程一样的能力。在源码阅读者看来，就是linux内核的clone没有实现对CLONE_PID参数的支持。按照POSIX定义，同一进程的所有线程应该共享一个进程id和父进程id，这在目前的"一对一"模型下是无法实现的。
  • 管理线程容易成为瓶颈，这是这种结构的通病；同时，管理线程又负责用户线程的清理工作，因此，尽管管理线程已经屏蔽了大部分的信号，但一旦管理线程死亡，用户线程就不得不手工清理了，而且用户线程并不知道管理线程的状态，之后的线程创建等请求将无人处理。
  • 信号用来实现同步原语，这会影响操作的响应时间。另外，将信号发送到主进程的概念也并不存在。因此，这并不遵守POSIX中处理信号的方法。
  • LinuxThreads中对信号的处理是按照每线程的原则建立的，而不是按照每进程的原则建立的，这是因为每个线程都有一个独立的进程ID。由于信号被发送给了一个专用的线程，因此信号是串行化的——也就是说，信号是透过这个线程再传递给其他线程的。这与POSIX标准对线程进行并行处理的要求形成了鲜明的对比。例如，在LinuxThreads中，通过kill()所发送的信号被传递到一些单独的线程，而不是集中整体进行处理。这意味着如果有线程阻塞了这个信号，那么LinuxThreads就只能对这个线程进行排队，并在线程开放这个信号时在执行处理，而不是像其他没有阻塞信号的线程中一样立即处理这个信号。
  • 由于LinuxThreads中的每个线程都是一个进程，因此用户和组ID的信息可能对单个进程中的所有线程来说都不是通用的。例如，一个多线程的setuid()/setgid()进程对于不同的线程来说可能都是不同的。
  • 由于每个线程都是一个单独的进程，因此/proc目录中会充满众多的进程项，而这实际上应该是线程。
  • 由于每个线程都是一个进程，因此对每个应用程序只能创建有限数目的线程。
  • 由于计算线程本地数据的方法是基于堆栈地址的位置的，因此对于这些数据的访问速度都很慢。另外一个缺点是用户无法可信地指定堆栈的大小，因为用户可能会意外地将堆栈地址映射到本来要为其他目的所使用的区域上了。按需增长（growondemand）的概念（也称为浮动堆栈的概念）是在2.4.10版本的linux内核中实现的。在此之前，LinuxThreads使用的是固定堆栈。
NPTL

NPTL（Native POSIX Thread Library）是linux线程的一个新实现，它克服了LinuxThreads的缺点，同时也符合POSIX的需求。与LinuxThreads相比，它在性能和稳定性方面都提供了重大的改进。与LinuxThreads一样，NPTL也实现了一对一的模型。

NPTL出现的一部分原因是对LinuxThreads进行改进，它设计目标如下：

  • 这个新线程库应该兼容POSIX标准。
  • 这个线程实现应该在具有很多处理器的系统上也能很好地工作。
  • 为一小段任务创建新线程应该具有很低的启动成本。
  • NPTL线程库应该与LinuxThreads是二进制兼容的。
  • 这个新线程库应该可以利用NUMA支持的优点。
NPTL的优点

NPTL总的来说采用了LinuxThreads类似的解决办法，内核看到的依然是一个进程，新线程是通过clone()系统调用产生的。与LinuxThreads相比，NPTL具有很多优点：

  • NPTL没有使用管理线程。管理线程的一些需求，例如向作为进程一部分的所有线程发送终止信号，是并不需要的；因为内核本身就可以实现这些功能。内核还会处理每个线程堆栈所使用的内存的回收工作。它甚至还通过在清除父线程之前进行等待，从而实现对所有线程结束的管理，这样可以避免僵尸进程的问题。
  • 由于NPTL没有使用管理线程，因此其线程模型在NUMA和SMP系统上具有更好的可伸缩性和同步机制。
  • 使用NPTL线程库与新内核实现，就可以避免使用信号来对线程进行同步了。为了这个目的，NPTL引入了一种名为futex的新机制。futex在共享内存区域上进行工作，因此可以在进程之间进行共享，这样就可以提供进程间POSIX同步机制。我们也可以在进程之间共享一个futex。这种行为使得进程间同步成为可能。实际上，NPTL包含了一个PTHREAD_PROCESS_SHARED宏，使得开发人员可以让用户级进程在不同进程的线程之间共享互斥锁。
  • 由于NPTL是POSIX兼容的，因此它对信号的处理是按照每进程的原则进行的；getpid()会为所有的线程返回相同的进程ID。例如，如果发送了SIGSTOP信号，那么整个进程都会停止；使用LinuxThreads，只有接收到这个信号的线程才会停止。这样可以在基于NPTL的应用程序上更好地利用调试器，例如GDB。
  • 由于在NPTL中所有线程都具有一个父进程，因此对父进程汇报的资源使用情况（例如CPU和内存百分比）都是对整个进程进行统计的，而不是对一个线程进行统计的。
  • NPTL线程库所引入的一个实现特性是对ABI（应用程序二进制接口）的支持。这帮助实现了与LinuxThreads的向后兼容性。这个特性是通过使用LD_ASSUME_KERNEL实现的。
futex

futex（Fast Userspace muTexes）意为快速用户区互斥，它是linux提供的一种同步（互斥）机制，特点是对于条件的判断是发生在用户空间的，在竞争不激烈的情况下能有更好的性能表现。futex在2.6.x系列稳定版内核中出现。

futex由一块能够被多个进程共享的内存空间（一个对齐后的整型变量）组成；这个整型变量的值能够通过汇编语言调用CPU提供的原子操作指令来增加或减少，并且一个进程可以等待直到那个值变成正数。Futex 的操作几乎全部在用户空间完成；只有当操作结果不一致从而需要仲裁时，才需要进入操作系统内核空间执行。这种机制允许使用 futex 的锁定原语有非常高的执行效率：由于绝大多数的操作并不需要在多个进程之间进行仲裁，所以绝大多数操作都可以在应用程序空间执行，而不需要使用（相对高代价的）内核系统调用。

线程创建和结束

在一个文件内的多个函数通常都是按照main函数中出现的顺序来执行，但是在分时系统下，我们可以让每个函数都作为一个逻辑流并发执行，最简单的方式就是采用多线程策略。在main函数中调用多线程接口创建线程，每个线程对应特定的函数（操作），这样就可以不按照main函数中各个函数出现的顺序来执行，避免了忙等的情况。线程基本操作的接口如下。

创建线程

int pthread_create(pthread_t *pthread, const pthread_attr_t *attr, void *(*start_routine)(void *), void *agr);

创建一个新线程，pthread和start_routine不可或缺，分别用于标识线程和执行体入口，其他可以填NULL。

pthread：用来返回线程的tid，*pthread值即为tid，类型pthread_t == unsigned long int。

attr：指向线程属性结构体的指针，用于改变所创线程的属性，填NULL使用默认值。

start_routine：线程执行函数的首地址，传入函数指针。

arg：通过地址传递来传递函数参数，这里是无符号类型指针，可以传任意类型变量的地址，在被传入函数中先强制类型转换成所需类型即可。

获得线程ID

pthread_t pthread_self();

调用时，会打印线程ID。

等待线程结束

int pthread_join(pthread_t tid, void** retval);

主线程调用，等待tid表示的子线程退出并回收其资源，类似于进程中wait/waitpid回收僵尸进程，调用pthread_join的线程会被阻塞。

tid：创建线程时通过指针得到tid值。

retval：指向返回值的指针。如果对tid表示的线程的返回值不感兴趣,可以设为NULL

结束线程

pthread_exit(void *retval);

子线程执行，用来结束当前线程并通过retval传递返回值，该返回值可通过pthread_join获得。

retval：同上。

分离线程

int pthread_detach(pthread_t tid);

主线程、子线程均可调用。主线程中pthread_detach(tid)，子线程中pthread_detach(pthread_self())，调用后和主线程分离，子线程结束时自己立即回收资源。

tid：同上。

线程属性值修改

线程属性对象类型为pthread_attr_t，结构体定义如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

typedef struct{
    int etachstate;    // 线程分离的状态
    int schedpolicy;    // 线程调度策略
    struct sched_param schedparam;    // 线程的调度参数
    int inheritsched;    // 线程的继承性
    int scope;    // 线程的作用域
    // 以下为线程栈的设置
    size_t guardsize;    // 线程栈末尾警戒缓冲大小
    int stackaddr_set;    // 线程的栈设置
    void *    stackaddr;    // 线程栈的位置
    size_t stacksize;    // 线程栈大小
}pthread_arrt_t;

相关接口：

对上述结构体中各参数大多有：

pthread_attr_get***()

和

pthread_attr_set***()

系统调用函数来设置和获取。这里不一一罗列。

共享资源

  1. 正文段. 程序的代码

  2. 数据段。程序的全局内存。包括全局变量和静态变量:

    1. 全局变量它是与具体某一函数无关的，所以也与特定线程无关；因此也是共享的

    2. 静态变量 虽然对于局部变量来说，它在代码中是“放”在某一函数中的，但是其存放位置和全局变量一样，存于堆中开辟的.bss和.data段，是共享的

  3. 堆 由于堆是在进程空间中开辟出来的，所以它是理所当然地被共享的；因此new出来的都是共享的，在线程中new出来的也可以被其他线程访问。

  4. 进程打开的文件描述符。 这个是共享的，使用这些公共资源的线程必须同步。

  5. 信号的处理器

  6. 进程的当前目录和进程用户ID与进程组ID。

独有资源

  1. 线程ID

    每个线程都有自己的线程ID，这个ID在本进程中是唯一的。进程用此来标识线程。

  2. 寄存器组的值

    由于线程间是并发运行的，每个线程有自己不同的运行线索，当从一个线程切换到另一个线程上时，必须将原有的线程的寄存器集合的状态保存，以便将来该线程在被重新切换到时能得以恢复。

  3. 线程的栈

    栈是保证线程独立运行所必须的。线程函数可以调用函数，而被调用函数中又是可以层层嵌套的，所以线程必须拥有自己的函数栈，使得函数调用可以正常执行，不受其他线程的影响。

  4. error变量 由于同一个进程中有很多个线程在同时运行，可能某个线程进行系统调用后设置了errno值，而在该线程还没有处理这个错误，另外一个线程就在此时被调度器投入运行，这样错误值就有可能被修改。所以，不同的线程应该拥有自己的错误返回码变量。

  5. 线程的信号屏蔽码

    由于每个线程所感兴趣的信号不同，所以线程的信号屏蔽码应该由线程自己管理。但所有的线程都共享同样的信号处理器。

  6. 调度优先级和策略

    由于线程需要像进程那样能够被调度，那么就必须要有可供调度使用的参数，这个参数就是线程的优先级。

  7. 线程私有数据

参考

https://github.com/linw7/Skill-Tree/blob/master/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F.md#mutex

用户级线程和内核级线程，你分得清吗？