Linux系統編程之進程概念

注：本文部分圖片來源於網絡，如有侵權，請告知刪除

1. 什么是進程？

在了解進程概念之前，我們需要先知道程序的概念。

程序，是指編譯好的二進制文件，這些文件在磁盤上，並不占用系統資源。

進程，指的是一個程序的執行實例，是操作系統分配系統資源的單位，這里的系統資源有CPU時間，內存等。當程序運行起來，產生一個進程。

也就是說，相比於程序，進程是一個動態的概念。

2. 用什么來描述進程？

進程信息被放在一個叫做進程控制塊的數據結構中，可以理解為進程屬性的集合。教材中稱為PCB（process control block），不同的操作系統下有不同的PCB，Linux 下的進程控制塊是 task_struct。

task_struct是Linux內核的一種數據結構，當一個進程創建時，系統會先將程序加載到內存，同時會將task_struct裝載到內存中，在task_struct中包含着進程的信息。

task_struct的內容主要分為以下幾類：

• 標示符（PID) : 描述本進程的唯一標示符，用來區別其他進程，本質上是一個非負整數。

• 進程狀態: 任務狀態，退出代碼，退出信號等。

• 上下文數據: 進程執行時處理器的寄存器中的數據。

• 程序計數器: 程序中即將被執行的下一條指令的地址。

• 文件描述符表，包含很多指向 file 結構體的指針。

• 優先級: 相對於其他進程的優先級。

• 其他信息。

3. PID、PPID

為了便於管理，操作系統中有父子進程的概念。子進程會繼承父進程的屬性和權限，而父進程也可以系統地管理子進程。

進程的標志符是PID，是進程的唯一標識，而父進程的標志符是PPID。

要查看進程的父子關系，可以用命令ps axj

我們在后台運行一個./test可執行文件，用如下命令查看該進程的父子信息

可以看到，該進程的進程PID為7711，其父進程PPID為29455

要獲取進程id和父進程id，可以使用getpid()和getppid()函數：

獲取當前進程 ID pid_t getpid(void);

獲取當前進程的父進程 ID pid_t getppid(void);

如運行如下代碼后，可以輸出該進程的id和父進程id

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
 	printf("pid: %d\n", getpid());
 	printf("ppid: %d\n", getppid());
 	return 0;
}

輸出結果：

4. fork函數

運行man 2 fork后，可以看到pid_t fork(void);

fork函數是用於創建子進程的一個函數，當父進程調用fork函數后，會創建一個子進程，父子進程代碼共享，數據各自開辟空間。

一般情況下，fork之后通常要進行分流，如代碼1

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int g_val = 0;

int main()
{
    pid_t id = fork();
    if(id < 0){
        perror("fork fail");
        return 1;
    }
    else if(id == 0) {
        //child
        printf("g_val = %d,child_pid = %d , &g_val = %p\n",g_val,getpid(),&g_val);
    }
    else {
        //parent
        printf("g_val = %d,parent_pid = %d , &g_val = %p\n",g_val,getpid(),&g_val);
    }
    return 0;
}

執行結果如下

可以看出，分流之后，父進程執行的是id>0的代碼，而子進程執行的是id == 0 的代碼，也就是說，fork是有兩個返回值的，如果子進程創建成功，fork給父進程返回的是子進程的PID，給子進程返回0。

需要注意的是，子進程執行的是fork之后的代碼。這是為什么？

在父進程創建好子進程后，父子進程代碼共有，父進程會將自己的數據拷貝給子進程，其中就包括了父進程程序計數器的值。程序計數器內存放的是程序中即將被執行的下一條指令的地址，由於父進程已經執行了fork前面的代碼，因此子進程會和父進程一樣，都執行fork之后的代碼。

5. 進程的狀態

當一個進程實體從磁盤加載到內存時，會創建對應的task_stuct，進程有不同的狀態。在Linux中，所有運行在系統里的進程都以task_struct鏈表的形式存在內核里，根據狀態的不同，可以將

task_struct中有關於進程狀態的描述：

static const char * const task_state_array[] = {
"R (running)", /* 0 */
"S (sleeping)", /* 1 */
"D (disk sleep)", /* 2 */
"T (stopped)", /* 4 */
"t (tracing stop)", /* 8 */
"X (dead)", /* 16 */
"Z (zombie)", /* 32 */
};

R狀態：可執行狀態，只有該狀態的進程才可以上處理機運行。同一時刻可以有多個進程同時處於R狀態，除了上處理機的進程外，其余R狀態的進程以鏈表的形式組成隊列，等待上處理機。在操作系統教材中的運行態和就緒態，在Linux中統一為R狀態。

S狀態：可中斷睡眠狀態，進程因為等待某些資源，而沒有上處理機運行，該狀態即S狀態。當得到等待的資源，或者接收到某些異步信號時，進程將會被喚醒。一般情況下用ps命令查看進程狀態，大多數進程都是S狀態。

D狀態：深度睡眠狀態，該狀態下不接受一些異步信號。該狀態存在的原因是操作系統的某一些操作要求是原子操作，中間不可以接受其他異步信號的干擾，只要對應資源不得到滿足，就一直處於D狀態。例如， kill -9 也殺不死D狀態的進程。而實際中，我們用ps命令幾乎是無法捕捉到D狀態的進程，因為原子操作往往比較短暫。

T狀態：可以通過發送 SIGSTOP 信號給進程來停止（T）進程。這個被暫停的進程可 以通過發送 SIGCONT 信號讓進程繼續運行。

X狀態：死亡狀態，該狀態是返回狀態，在任務列表中看不到。

Z狀態：僵屍狀態，該狀態是一個特殊的狀態。當進程退出時，如果父進程沒有讀取到子進程退出的返回代碼，就會產生僵屍進程。僵屍進程會一直以Z狀態留在進程表中，等待父進程讀取其退出狀態。即便是退出狀態的進程，本身也需要用PCB進行維護，也就是說，如果父進程不讀取子進程的退出信息，子進程的PCB會一直在內存中，從而造成了內存泄漏。

除了僵屍進程，系統中還可能存在另外一種進程——孤兒進程。當父進程先退出時，子進程就成了孤兒進程，此時孤兒進程會被1號init進程領養，其PPID變為1。

6. 進程地址空間

我們將第4節講解fork函數時的代碼稍作修改

#include <stdio.h>                             
#include <sys/types.h>    
#include <unistd.h>    
    
int g_val = 0;    
    
int main()    
{    
    pid_t id = fork();    
    if(id < 0){    
        perror("fork fail");    
        return 1;    
    }    
    else if(id == 0) {    
        //child   
        g_val = 10000;
        printf("g_val = %d,child_pid = %d , &g_val = %p\n",g_val,getpid(),&g_val);    
    }    
    else {
        //parent
        sleep(3);//這段代碼讓父進程休眠3s，保證子進程的代碼先執行，讓子進程修改g_val
        printf("g_val = %d,parent_pid = %d , &g_val = %p\n",g_val,getpid(),&g_val);    
    }    
    return 0;    
}

執行結果如下

我們驚奇地發現，父進程和子進程的&g_val是一樣的，但是g_val居然不一樣！

我們知道，相同的物理內存單元中不可能存儲不同的兩個數，也就是說，這里的地址並不是實際的物理地址，而是虛擬地址。那么，操作系統是如何管理進程的地址空間呢？

6.1 mm_struct

對於操作系統而言，管理的方式是先用數據結構進行描述，再將數據結構進行組織。我們知道當一個進程創建時，會創建對應的PCB，在Linux中，task_struct中有一個結構體——struct mm_struct，這個結構體就是用來描述該進程虛擬地址的結構體。

mm_struct源碼如下

struct mm_struct {

    //指向線性區對象的鏈表頭
    struct vm_area_struct * mmap;       /* list of VMAs */
    //指向線性區對象的紅黑樹
    struct rb_root mm_rb;
    //指向最近找到的虛擬區間
    struct vm_area_struct * mmap_cache; /* last find_vma result */

    //用來在進程地址空間中搜索有效的進程地址空間的函數
    unsigned long (*get_unmapped_area) (struct file *filp,
                unsigned long addr, unsigned long len,
                unsigned long pgoff, unsigned long flags);

       unsigned long (*get_unmapped_exec_area) (struct file *filp,
                unsigned long addr, unsigned long len,
                unsigned long pgoff, unsigned long flags);

    //釋放線性區時調用的方法，          
    void (*unmap_area) (struct mm_struct *mm, unsigned long addr);

    //標識第一個分配文件內存映射的線性地址
    unsigned long mmap_base;        /* base of mmap area */


    unsigned long task_size;        /* size of task vm space */
    /*
     * RHEL6 special for bug 790921: this same variable can mean
     * two different things. If sysctl_unmap_area_factor is zero,
     * this means the largest hole below free_area_cache. If the
     * sysctl is set to a positive value, this variable is used
     * to count how much memory has been munmapped from this process
     * since the last time free_area_cache was reset back to mmap_base.
     * This is ugly, but necessary to preserve kABI.
     */
    unsigned long cached_hole_size;

    //內核進程搜索進程地址空間中線性地址的空間空間
    unsigned long free_area_cache;      /* first hole of size cached_hole_size or larger */

    //指向頁表的目錄
    pgd_t * pgd;

    //共享進程時的個數
    atomic_t mm_users;          /* How many users with user space? */

    //內存描述符的主使用計數器，采用引用計數的原理，當為0時代表無用戶再次使用
    atomic_t mm_count;          /* How many references to "struct mm_struct" (users count as 1) */

    //線性區的個數
    int map_count;              /* number of VMAs */

    struct rw_semaphore mmap_sem;

    //保護任務頁表和引用計數的鎖
    spinlock_t page_table_lock;     /* Protects page tables and some counters */

    //mm_struct結構，第一個成員就是初始化的mm_struct結構，
    struct list_head mmlist;        /* List of maybe swapped mm's.  These are globally strung
                         * together off init_mm.mmlist, and are protected
                         * by mmlist_lock
                         */

    /* Special counters, in some configurations protected by the
     * page_table_lock, in other configurations by being atomic.
     */

    mm_counter_t _file_rss;
    mm_counter_t _anon_rss;
    mm_counter_t _swap_usage;

    //進程擁有的最大頁表數目
    unsigned long hiwater_rss;  /* High-watermark of RSS usage */、
    //進程線性區的最大頁表數目
    unsigned long hiwater_vm;   /* High-water virtual memory usage */

    //進程地址空間的大小，鎖住無法換頁的個數，共享文件內存映射的頁數，可執行內存映射中的頁數
    unsigned long total_vm, locked_vm, shared_vm, exec_vm;
    //用戶態堆棧的頁數，
    unsigned long stack_vm, reserved_vm, def_flags, nr_ptes;
    //維護代碼段和數據段
    unsigned long start_code, end_code, start_data, end_data;
    //維護堆和棧
    unsigned long start_brk, brk, start_stack;
    //維護命令行參數，命令行參數的起始地址和最后地址，以及環境變量的起始地址和最后地址
    unsigned long arg_start, arg_end, env_start, env_end;

    unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */

    struct linux_binfmt *binfmt;

    cpumask_t cpu_vm_mask;

    /* Architecture-specific MM context */
    mm_context_t context;

    /* Swap token stuff */
    /*
     * Last value of global fault stamp as seen by this process.
     * In other words, this value gives an indication of how long
     * it has been since this task got the token.
     * Look at mm/thrash.c
     */
    unsigned int faultstamp;
    unsigned int token_priority;
    unsigned int last_interval;

    //線性區的默認訪問標志
    unsigned long flags; /* Must use atomic bitops to access the bits */

    struct core_state *core_state; /* coredumping support */
#ifdef CONFIG_AIO
    spinlock_t      ioctx_lock;
    struct hlist_head   ioctx_list;
#endif
#ifdef CONFIG_MM_OWNER
    /*
     * "owner" points to a task that is regarded as the canonical
     * user/owner of this mm. All of the following must be true in
     * order for it to be changed:
     *
     * current == mm->owner
     * current->mm != mm
     * new_owner->mm == mm
     * new_owner->alloc_lock is held
     */
    struct task_struct *owner;
#endif

#ifdef CONFIG_PROC_FS
    /* store ref to file /proc/<pid>/exe symlink points to */
    struct file *exe_file;
    unsigned long num_exe_file_vmas;
#endif
#ifdef CONFIG_MMU_NOTIFIER
    struct mmu_notifier_mm *mmu_notifier_mm;
#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
    pgtable_t pmd_huge_pte; /* protected by page_table_lock */
#endif
    /* reserved for Red Hat */
#ifdef __GENKSYMS__
    unsigned long rh_reserved[2];
#else
    /* How many tasks sharing this mm are OOM_DISABLE */
    union {
        unsigned long rh_reserved_aux;
        atomic_t oom_disable_count;
    };

    /* base of lib map area (ASCII armour) */
    unsigned long shlib_base;
#endif
};

因此，進程地址空間實際上就是結構體mm_struct所描述的虛擬空間，每個進程都有自己的虛擬地址空間。每個進程的虛擬地址如下圖所示。

在Linux中，采用分頁存儲的方式對內存進行管理。既然我們平時所看到的地址不是實際的物理地址，那就需要操作系統將虛擬地址映射為物理地址。操作系統是借助頁表來實現虛擬地址和物理地址的映射的，頁表的本質也是一個數據結構，最主要的兩項就是進程的虛擬地址和實際物理地址的映射關系。

6.2 寫時拷貝

在我們的代碼中，當fork創建子進程時，會將父進程的mm_struct也拷貝給子進程，一開始，內存中只有一份g_val，當子進程修改g_val時，由於父子進程的數據是各自私有的，進程之間的執行應該具有獨立性，因此子進程修改g_val不應該影響到父進程。此時就會發生寫時拷貝，即子進程在內存中開辟一塊新的空間，將修改后的值填入該空間，並且修改子進程頁表中虛擬地址映射的實際物理地址。

因此，我們看到了上述相同虛擬地址中存儲的數值不同的場景。

6.3 為什么要有進程地址空間？

這是因為引入了進程地址空間后，可以保證每個進程所用的空間獨立而連續3。一個進程的越界操作並不會影響另一個進程，這樣就實現了內存的保護。同時，每個進程地址空間是遠大於實際內存空間的，這樣也可以通過虛擬的方式實現內存的擴充。當一個進程退出后，我們只需要清除掉該進程的mm_struct和頁表就可，有利於內存的分配回收。