程序到进程的运行机制详解-优快云博客

计算机如何执行进程呢？这是计算机运行的核心问题。即使已经编写好程序，但程序是死的。只有活的进程才能产出。我们已经从Linux进程基础中了解了进程。现在我们看一下从程序到进程的漫漫征程。

一段程序

下面是一个简单的C程序，假设该程序已经编译好，生成可执行文件vamei.exe。

#include <stdio.h>

int glob=0;                                             /*global variable*/

void main(void) {
  int main1=5;                                          /*local variable of main()*/
  int main2;                                            /*local variable of main()*/
  main2 = inner(main1);                                 /* call inner() function */
  printf("From Main: glob: %d \n", glob);
  printf("From Main: main2: %d \n", main2);
}

int inner(int inner1) {                                 /*inner1 is an argument, also local to inner()*/
  int inner2=10;                                        /*local variable of inner()*/
  printf("From inner: glob: %d \n", glob);
  return(inner1+inner2);
}

(选取哪一个语言或者具体的语法并不是关键，大部分语言都可以写出类似上面的程序。在看Python教程的读者也可以利用Python的函数结构和print写一个类似的python程序。当然，还可以是C++，Java，Objective-C等等。选用C语言的原因是：它是为UNIX而生的语言。)

main()函数中调用了inner()函数。inner()中调用一次printf()以输出。最后，在main()中进行了两次printf()。

注意变量的作用范围。简单地说，变量可以分为全局变量和局部变量。在所有函数之外声明的变量为全局变量，比如glob，在任何时候都可以使用。在函数内定义的变量为局部变量，只能在该函数的作用域(range)内使用，比如说我们在inner()工作的时候不能使用main()函数中声明的main1变量，而在main()中我们无法使用inner()函数中声明的inner2变量。

不用太过在意这个程序的具体功能。要点是这个程序的运行过程。下图为该程序的运行过程，以及各个变量的作用范围：

运行流程

进程空间

为了进一步了解上面程序的运行，我们还需要知道，进程如何使用内存。当程序文件运行为进程时，进程在内存中获得空间。这个空间是进程自己的小屋子。

每个进程空间按照如下方式分为不同区域:

内存空间

Text区域用来储存指令(instruction)，说明每一步的操作。Global Data用于存放全局变量，栈(Stack)用于存放局部变量，堆(heap)用于存放动态变量 (dynamic variable. 程序利用malloc系统调用，直接从内存中为dynamic variable开辟空间)。Text和Global data在进程一开始的时候就确定了，并在整个进程中保持固定大小。

栈(Stack)以帧(stack frame)为单位。当程序调用函数的时候，比如main()函数中调用inner()函数，stack会向下增长一帧。帧中存储该函数的参数和局部变量，以及该函数的返回地址(return address)。此时，计算机将控制权从main()转移到inner()，inner()函数处于激活(active)状态。位于栈最下方的帧，和全局变量一起，构成了当前的环境(context)。激活函数可以从环境中调用需要的变量。典型的编程语言都只允许你使用位于stack最下方的帧，而不允许你调用其它的帧 (这也符合stack结构“先进后出”的特征。但也有一些语言允许你调用栈的其它部分，相当于允许你在运行inner()函数的时候调用main()中声明的局部变量，比如Pascal)。当函数又进一步调用另一个函数的时候，一个新的帧会继续增加到栈的下方，控制权转移到新的函数中。当激活函数返回的时候，会从栈中弹出(pop，读取并从栈中删除)该帧，并根据帧中记录的返回地址，将控制权交给返回地址所指向的指令(比如从inner()函数中返回，继续执行main()中赋值给main2的操作)。

下图是栈在运行过程中的变化。箭头表示栈的增长方向。每个方块代表一帧。开始的时候我们有一个为main()服务的帧，随着调用inner()，我们为inner()增加一个帧。在inner()返回时，我们再次只有main()的帧，直到最后main()返回，其返回地址为空，所以进程结束。

stack变化

在进程运行的过程中，通过调用和返回函数，控制权不断在函数间转移。进程可以在调用函数的时候，原函数的帧中保存有在我们离开时的状态，并为新的函数开辟所需的帧空间。在调用函数返回时，该函数的帧所占据的空间随着帧的弹出而清空。进程再次回到原函数的帧中保存的状态，并根据返回地址所指向的指令继续执行。上面过程不断继续，栈不断增长或减小，直到main()返回的时候，栈完全清空，进程结束。

当程序中使用malloc的时候，堆(heap)会向上增长，其增长的部分就成为malloc从内存中分配的空间。malloc开辟的空间会一直存在，直到我们用free系统调用来释放，或者进程结束。一个经典的错误是内存泄漏(memory leakage), 就是指我们没有释放不再使用的堆空间，导致堆不断增长，而内存可用空间不断减少。

栈和堆的大小则会随着进程的运行增大或者变小。当栈和堆增长到两者相遇时候，也就是内存空间图中的蓝色区域(unused area)完全消失的时候，再无可用内存。进程会出现栈溢出(stack overflow)的错误，导致进程终止。在现代计算机中，内核一般会为进程分配足够多的蓝色区域，如果清理及时，栈溢出很容易避免。即便如此，内存负荷过大，依然可能出现栈溢出的情况。我们就需要增加物理内存了。

Stack overflow可以说是最出名的计算机错误了，所以才有IT网站(stackoverflow.com)以此为名。

在高级语言中，这些内存管理的细节对于用户来说不透明。在编程的时候，我们只需要记住上一节中的变量作用域就可以了。但在想要写出复杂的程序或者debug的时候，我们就需要相关的知识了。

进程附加信息

除了上面的信息之外，每个进程还要包括一些进程附加信息，包括PID，PPID，PGID(参考Linux进程基础以及Linux进程关系)等，用来说明进程的身份、进程关系以及其它统计信息。这些信息并不保存在进程的内存空间中。内核会为每个进程在内核自己的空间中分配一个变量(task_struct结构体)以保存上述信息。内核可以通过查看自己空间中的各个进程的附加信息就能知道进程的概况，而不用进入到进程自身的空间 (就好像我们可以通过门牌就可以知道房间的主人是谁一样，而不用打开房门)。每个进程的附加信息中有位置专门用于保存接收到的信号(正如我们在Linux信号基础中所说的“信箱”)。

fork & exec

现在，我们可以更加深入地了解fork和exec(参考Linux进程基础)的机制了。当一个程序调用fork的时候，实际上就是将上面的内存空间，包括text, global data, heap和stack，又复制出来一个，构成一个新的进程，并在内核中为改进程创建新的附加信息 (比如新的PID，而PPID为原进程的PID)。此后，两个进程分别地继续运行下去。新的进程和原有进程有相同的运行状态(相同的变量值，相同的instructions...)。我们只能通过进程的附加信息来区分两者。

程序调用exec的时候，进程清空自身内存空间的text, global data, heap和stack，并根据新的程序文件重建text, global data, heap和stack (此时heap和stack大小都为0)，并开始运行。

(现代操作系统为了更有效率，改进了管理fork和exec的具体机制，但从逻辑上来说并没有差别。具体机制请参看Linux内核相关书籍)

这一篇写了整合了许多东西，所以有些长。这篇文章主要是概念性的，许多细节会根据语言和平台乃至于编译器的不同而有所变化，但大体上，以上的概念适用于所有的计算机进程(无论是Windows还是UNIX)。更加深入的内容，包括线程(thread)、进程间通信(IPC)等，都依赖于这里介绍的内容。

典型的UNIX系统都支持一个进程创建多个线程(thread)。在Linux进程基础中提到，Linux以进程为单位组织操作，Linux中的线程也都基于进程。尽管实现方式有异于其它的UNIX系统，但Linux的多线程在逻辑和使用上与真正的多线程并没有差别。

多线程

我们先来看一下什么是多线程。在Linux从程序到进程中，我们看到了一个程序在内存中的表示。这个程序的整个运行过程中，只有一个控制权的存在。当函数被调用的时候，该函数获得控制权，成为激活(active)函数，然后运行该函数中的指令。与此同时，其它的函数处于离场状态，并不运行。如下图所示:

Linux从程序到进程

我们看到，各个方块之间由箭头连接。各个函数就像是连在一根线上一样，计算机像一条流水线一样执行各个函数中定义的操作。这样的一个程序叫做单线程程序。

多线程就是允许一个进程内存在多个控制权，以便让多个函数同时处于激活状态，从而让多个函数的操作同时运行。即使是单CPU的计算机，也可以通过不停地在不同线程的指令间切换，从而造成多线程同时运行的效果。如下图所示，就是一个多线程的流程:

main()到func3()再到main()构成一个线程，此外func1()和func2()构成另外两个线程。操作系统一般都有一些系统调用来让你将一个函数运行成为一个新的线程。

回忆我们在Linux从程序到进程中提到的栈的功能和用途。一个栈，只有最下方的帧可被读写。相应的，也只有该帧对应的那个函数被激活，处于工作状态。为了实现多线程，我们必须绕开栈的限制。为此，创建一个新的线程时，我们为这个线程建一个新的栈。每个栈对应一个线程。当某个栈执行到全部弹出时，对应线程完成任务，并收工。所以，多线程的进程在内存中有多个栈。多个栈之间以一定的空白区域隔开，以备栈的增长。每个线程可调用自己栈最下方的帧中的参数和变量，并与其它线程共享内存中的Text，heap和global data区域。对应上面的例子，我们的进程空间中需要有3个栈。

(要注意的是，对于多线程来说，由于同一个进程空间中存在多个栈，任何一个空白区域被填满都会导致stack overflow的问题。)

并发

多线程相当于一个并发(concunrrency)系统。并发系统一般同时执行多个任务。如果多个任务可以共享资源，特别是同时写入某个变量的时候，就需要解决同步的问题。比如说，我们有一个多线程火车售票系统，用全局变量i存储剩余的票数。多个线程不断地卖票(i = i - 1)，直到剩余票数为0。所以每个都需要执行如下操作:

/*mu is a global mutex*/

while (1) {                        /*infinite loop*/
    if (i != 0) i = i -1
    else {
      printf("no more tickets");
      exit();
    }
}

如果只有一个线程执行上面的程序的时候(相当于一个窗口售票)，则没有问题。但如果多个线程都执行上面的程序(相当于多个窗口售票), 我们就会出现问题。我们会看到，其根本原因在于同时发生的各个线程都可以对i读取和写入。

我们这里的if结构会给CPU两个指令, 一个是判断是否有剩余的票(i != 0), 一个是卖票 (i = i -1)。某个线程会先判断是否有票(比如说此时i为1)，但两个指令之间存在一个时间窗口，其它线程可能在此时间窗口内执行卖票操作(i = i -1)，导致该线程卖票的条件不再成立。但该线程由于已经执行过了判断指令，所以无从知道i发生了变化，所以继续执行卖票指令，以至于卖出不存在的票 (i成为负数)。对于一个真实的售票系统来说，这将成为一个严重的错误 (售出了过多的票，火车爆满)。

在并发情况下，指令执行的先后顺序由内核决定。同一个线程内部，指令按照先后顺序执行，但不同线程之间的指令很难说清除哪一个会先执行。如果运行的结果依赖于不同线程执行的先后的话，那么就会造成竞争条件(race condition)，在这样的状况下，计算机的结果很难预知。我们应该尽量避免竞争条件的形成。最常见的解决竞争条件的方法是将原先分离的两个指令构成不可分隔的一个原子操作(atomic operation)，而其它任务不能插入到原子操作中。

多线程同步

对于多线程程序来说，同步(synchronization)是指在一定的时间内只允许某一个线程访问某个资源。而在此时间内，不允许其它的线程访问该资源。我们可以通过互斥锁(mutex)，条件变量(condition variable)和读写锁(reader-writer lock)来同步资源。

1) 互斥锁

互斥锁是一个特殊的变量，它有锁上(lock)和打开(unlock)两个状态。互斥锁一般被设置成全局变量。打开的互斥锁可以由某个线程获得。一旦获得，这个互斥锁会锁上，此后只有该线程有权打开。其它想要获得互斥锁的线程，会等待直到互斥锁再次打开的时候。我们可以将互斥锁想像成为一个只能容纳一个人的洗手间，当某个人进入洗手间的时候，可以从里面将洗手间锁上。其它人只能在互斥锁外面等待那个人出来，才能进去。在外面等候的人并没有排队，谁先看到洗手间空了，就可以首先冲进去。

上面的问题很容易使用互斥锁的问题解决，每个线程的程序可以改为:

/*mu is a global mutex*/

while (1) {                /*infinite loop*/
  mutex_lock(mu);           /*aquire mutex and lock it, if cannot, wait until mutex is unblocked*/
  if (i != 0) i = i - 1;
  else {
    printf("no more tickets");
    exit();
  }
  mutex_unlock(mu);         /*release mutex, make it unblocked*/
}

第一个执行mutex_lock()的线程会先获得mu。其它想要获得mu的线程必须等待，直到第一个线程执行到mutex_unlock()释放mu，才可以获得mu，并继续执行线程。所以线程在mutex_lock()和mutex_unlock()之间的操作时，不会被其它线程影响，就构成了一个原子操作。

需要注意的时候，如果存在某个线程依然使用原先的程序 (即不尝试获得mu，而直接修改i)，互斥锁不能阻止该程序修改i，互斥锁就失去了保护资源的意义。所以，互斥锁机制需要程序员自己来写出完善的程序来实现互斥锁的功能。我们下面讲的其它机制也是如此。

2) 条件变量

条件变量是另一种常用的变量。它也常常被保存为全局变量，并和互斥锁合作。

假设这样一个状况: 有100个工人，每人负责装修一个房间。当有10个房间装修完成的时候，老板就通知相应的十个工人一起去喝啤酒。

我们如何实现呢？老板让工人在装修好房间之后，去检查已经装修好的房间数。但多线程条件下，会有竞争条件的危险。也就是说，其他工人有可能会在该工人装修好房子和检查之间完成工作。采用下面方式解决：

/*mu: global mutex, cond: global codition variable, num: global int*/
mutex_lock(mu)

num = num + 1;                      /*worker build the room*/

if (num <= 10) {                     /*worker is within the first 10 to finish*/
    cond_wait(mu, cond);            /*wait*/
    printf("drink beer");
}
else if (num = 11) {                /*workder is the 11th to finish*/
  cond_broadcast(mu, cond);         /*inform the other 9 to wake up*/
}

mutex_unlock(mu);

上面使用了条件变量。条件变量除了要和互斥锁配合之外，还需要和另一个全局变量配合(这里的num, 也就是装修好的房间数)。这个全局变量用来构成各个条件。

具体思路如下。我们让工人在装修好房间(num = num + 1)之后，去检查已经装修好的房间数( num < 10 )。由于mu被锁上，所以不会有其他工人在此期间装修房间(改变num的值)。如果该工人是前十个完成的人，那么我们就调用cond_wait()函数。
cond_wait()做两件事情，一个是释放mu，从而让别的工人可以建房。另一个是等待，直到cond的通知。这样的话，符合条件的线程就开始等待。

当有通知(第十个房间已经修建好)到达的时候，condwait()会再次锁上mu。线程的恢复运行，执行下一句prinft("drink beer") (喝啤酒！)。从这里开始，直到mutex_unlock()，就构成了另一个互斥锁结构。

那么，前面十个调用cond_wait()的线程如何得到的通知呢？我们注意到elif if，即修建好第11个房间的人，负责调用cond_broadcast()。这个函数会给所有调用cond_wait()的线程放送通知，以便让那些线程恢复运行。

条件变量特别适用于多个线程等待某个条件的发生。如果不使用条件变量，那么每个线程就需要不断尝试获得互斥锁并检查条件是否发生，这样大大浪费了系统的资源。

3) 读写锁

读写锁与互斥锁非常相似。r、RW lock有三种状态: 共享读取锁(shared-read), 互斥写入锁(exclusive-write lock), 打开(unlock)。后两种状态与之前的互斥锁两种状态完全相同。

一个unlock的RW lock可以被某个线程获取R锁或者W锁。

如果被一个线程获得R锁，RW lock可以被其它线程继续获得R锁，而不必等待该线程释放R锁。但是，如果此时有其它线程想要获得W锁，它必须等到所有持有共享读取锁的线程释放掉各自的R锁。

如果一个锁被一个线程获得W锁，那么其它线程，无论是想要获取R锁还是W锁，都必须等待该线程释放W锁。

这样，多个线程就可以同时读取共享资源。而具有危险性的写入操作则得到了互斥锁的保护。

我们需要同步并发系统，这为程序员编程带来了难度。但是多线程系统可以很好的解决许多IO瓶颈的问题。比如我们监听网络端口。如果我们只有一个线程，那么我们必须监听，接收请求，处理，回复，再监听。如果我们使用多线程系统，则可以让多个线程监听。当我们的某个线程进行处理的时候，我们还可以有其他的线程继续监听，这样，就大大提高了系统的利用率。在数据越来越大，服务器读写操作越来越多的今天，这具有相当的意义。多线程还可以更有效地利用多CPU的环境。

(就像做饭一样，不断切换去处理不同的菜。)

本文中的程序采用伪C的写法。不同的语言有不同的函数名(比如mutex_lock)。这里关注的是逻辑上的概念，而不是具体的实现和语言规范。

Linux的用户在登录(login)之后，就带有一个用户身份(user ID, UID)和一个组身份(group ID, GID)。在Linux文件管理背景知识中，我们又看到，每个文件又有九位的权限说明，用来指明该文件允许哪些用户执行哪些操作(读、写或者执行)。

一般来说，Linux的用户信息保存在/etc/passwd中，组信息保存在/etc/group中，文件的每一行代表一个用户/组。早期的Linux将密码以名码的形式保存在/etc/passwd中，而现在则多以暗码(也就是加密之后的形式)的形式保存在/etc/shadow中。将密码存储在/etc/shadow中提高了密码的安全性，因为/etc/passwd允许所有人查看，而/etc/shadow只允许root用户查看。

进程权限

但是，在Linux中，用户的指令是在进程的范围内进行的。当我们向对某个文件进行操作的时候，我们需要在进程中运行一个程序，在进程中对文件打开，并进行读、写或者执行的操作。因此，我们需要将用户的权限传递给进程，以便进程真正去执行操作。例如我们有一个文件a.txt, 文件中为一个字符串:

Hello world!

我以用户Vamei的身份登录，并在shell中运行如下命令：

$cat a.txt

整个运行过程以及文件读取如下:

我们可以看到，整个过程中我们会有两个进程，一个是shell本身(2256)，一个是shell复制自身，再运行/bin/cat (9913)。图中的fork, exec, PID可参看Linux进程基础。第二个进程总共对文件系统进行了两次操作，一次是执行(x)文件/bin/cat，另外一次是读取(r)文件a.txt。使用$ls -l 查看这两个文件的权限:

$ls -l /bin/cat

-rwxr-xr-x 1 root root 46764 Apr 1 2012 /bin/cat

$ls -l a.txt

-rw-rw-r-- 1 Vamei Vamei 14 Oct 7 09:14 a.txt

从上面可以看到(参考Linux文件管理背景知识)，/bin/cat让所有用户都享有执行的权利，而Vamei作为a.txt的拥有者，对a.txt享有读取的权利。

让我们进入更多的细节 (The devil is in the details)。在进行这两次操作的时候，尽管用户Vamei拥有相应的权限，但我们发现，真正做工作的是进程9913。我们要让这个进程得到相应的权限。实际上，每个进程会维护有如下6个ID：

真实身份: real UID, real GID

有效身份: effective UID, effective GID

存储身份：saved UID, saved GID

其中，真实身份是我们登录使用的身份，有效身份是当该进程真正去操作文件时所检查的身份，存储身份较为特殊，我们等一下再深入。当进程fork的时候，真实身份和有效身份都会复制给子进程。大部分情况下，真实身份和有效身份都相同。当Linux完成开机启动之后，init进程会执行一个login的子进程。我们将用户名和密码传递给login子进程。login在查询了/etc/passwd和/etc/shadow，并确定了其合法性之后，运行(利用exec)一个shell进程，shell进程真实身份被设置成为该用户的身份。由于此后fork此shell进程的子进程都会继承真实身份，所以该真实身份会持续下去，直到我们登出并以其他身份再次登录(当我们使用su成为root的时候，实际上就是以root身份再次登录，此后真实身份成为root)。

最小权限原则

每个进程为什么不简单地只维护真实身份，却选择费尽麻烦地去维护有效身份和存储身份呢？这牵涉到Linux的“最小特权”(least priviledge)的原则。Linux通常希望进程只拥有足够完成其工作的特权，而不希望赋予更多的特权给它。从设计上来说，最简单的是赋予每个进程以super user的特权，这样进程就可以想做什么做什么。然而，这对于系统来说是一个巨大的安全漏洞，特别是在多用户环境下，如果每个用户都享有无限制的特权，就很容易破坏其他用户的文件或者系统本身。“最小特权”就是收缩进程所享有的特权，以防进程滥用特权。

然而，进程的不同阶段可能需要不同的特权。比如一个进程最开始的有效身份是真实身份，但运行到中间的时候，需要以其他的用户身份读入某些配置文件，然后再进行其他的操作。为了防止其他的用户身份被滥用，我们需要在操作之前，让进程的有效身份变更回来成为真实身份。这样，进程需要在两个身份之间变化。

存储身份就是真实身份之外的另一个身份。当我们将一个程序文件执行成为进程的时候，该程序文件的拥有者(owner)和拥有组(owner group)可以被，存储成为进程的存储身份。在随后进程的运行过程中，进程就将可以选择将真实身份或者存储身份复制到有效身份，以拥有真实身份或者存储身份的权限。并不是所有的程序文件在执行的过程都设置存储身份的。需要这么做的程序文件会在其九位(bit)权限的执行位的x改为s。这时，这一位(bit)叫做set UID bit或者set GID bit。

$ls -l /usr/bin/uuidd
-rwsr-sr-x 1 libuuid libuuid 17976 Mar 30 2012 /usr/sbin/uuidd

当我以root(UID), root(GID)的真实身份运行这个程序的时候，由于拥有者(owner)有s位的设定，所以saved UID被设置成为libuuid，saved GID被设置成为libuuid。这样，uuidd的进程就可以在两个身份之间切换。

我们通常使用chmod来修改set-UID bit和set-GID bit:

$chmod 4700 file

我们看到，这里的chmod后面不再只是三位的数字。最前面一位用于处理set-UID bit/set-GID bit，它可以被设置成为4/2/1以及或者上面数字的和。4表示为set UID bit, 2表示为set GID bit，1表示为sticky bit (暂时不介绍)。必须要先有x位的基础上，才能设置s位。

作为一个Linux用户来说，我们并不需要特别关心上面的机制。但是，当我们去编写一个Linux应用程序的时候，就要注意在程序中实现以上切换(有必要的前提下)，以便让我们的程序符合"最小权限"的原则，不给系统留下可能的安全隐患。

原文地址：http://www.cnblogs.com/vamei/archive/2012/10/09/2715388.html