Linux内核：进程基础之进程ID与管理

Linux系统中的每一个进程都有一个唯一的标示——PID（Process ID），也叫进程ID。给每一进程设置一个标示的主要作用便是方便Linux系统管理数量庞大的进程，例如进程间的通信、判断子父进程、通过进程ID找到进程的task_struct等等，都需要使用到我们的进程ID。我们已经知道每一个进程都会有一个唯一的task_struct结构体来关联该进程相关的数据和结构体。Linux 内核所有涉及到进程和程序的所有算法都是围绕该数据结构建立的，是内核中最重要的数据结构之一。所以毫不例外，我们的PID也应该会在task_struct结构体中会有关联，但它到底是怎么和进程的PID关联起来的呢？同时由于PID命名空间的存在，以及线程组、进程组、会话组等等组织的存在，进程ID又是如何进行区分和表示的呢？下面我将一一对这些疑问进行解答。

命名空间

在Linux系统中，之所以要引入命名空间，其根本目的是可以通过命名空间，从系统层面对进程进行管理。例如我们上面提到的进程ID，由于所有的进程都是通过PID进行标示的，那么在系统中肯定会对这些PID进行统一全局的管理。对于一些有着相同属性的进程，我们可以将其划分到同一个容器中，但这并不意味着每一个进程只能属于一个命名空间。解释这个问题，我们可以从进程的task_struct结构体关联其命名空间开始讲起。在task_struct结构体中包含有一个nsproxy结构体体的指针，其指向了自己进程所属于的nsproxy结构体。

struct task_struct {
          .....
      struct nsproxy *nsproxy;
          .....
}

那么这个nsproxy指针就是指向其所在的nsproxy结构体。那我们现在来看一看nsproxy结构体。

struct nsproxy {
	atomic_t count; // 关联该结构体的task_struct数量
	struct uts_namespace *uts_ns; //uts命名空间
	struct ipc_namespace *ipc_ns; //ipc命名空间
	struct mnt_namespace *mnt_ns; //mnt命名空间
	struct pid_namespace *pid_ns; //pid命名空间
	struct net 	     *net_ns; //网络相关的命名空间的数量
}

从上面的nsproxy结构体中我们可以看到，其里面包含各种命名空间的指针，而由于task_struct结构体指向的是nsproxy，所以毫无疑问，该task_struct是属于nsproxy里面指向的各种类型的命名空间。在Linux的官方文档中，我们还看到了这样一句话：The nsproxy is shared by tasks which share all namespaces. As soon as a single namespace is cloned or unshared, the nsproxy is copied. 说明只要有一个task_struct结构体的命名空间与现有的nsproxy不一样或者是有新的namespace生成，那么整个nsproxy结构体都将会被重新拷贝一份。这样我们就可以看到如下的一个关系框图。

由上图可以看到，只要有进程的用户命名空间与其他的nsproxy结构体不同，那么就会重新生成一个nsproxy结构体。从这个图我们也看出了，同一个进程，并不只属于一种类型的命名空间。

PID命名空间

因为这里我是讲进程的ID管理，所以下面我们着重关注PID命名空间。命名空间的出现，增加了PID管理的复杂性，但是却能极大提高管理的效率。PID命名空间是按照层次组织的，当我们在新复制一个进程时，都会设置是否新建一个命名空间的标志位。新建的命名空间中的所有PID对父命名空间都是可见的，但是子命名空间却无法看到父命名空间。为什么会这样呢，原来在建立新的命名空间的时候，新命名空间的所有PID都会在父命名空间建立一个它的映射，有了这个映射，父命名空间就可以看到子命名空间的PID啦。父子命名空间的层次结构图如下：

由于有了这种父子命名空间的出现，所以也就有了PID命名空间的所属层级了，由上图可知处在最高位的是level 0，然后下面的命名空间level会逐级增加。同时由于这种层级的出现，也便有了全局ID和局部ID之分。

      1.  全局ID：处于层级顶层的ID，也就是level为0的命名空间中的ID，全局ID具有唯一性。

      2.  局部ID：只属于一个命名空间，其局部ID也只有在该命名空间里面有效。

全局