为什么系统 PID 是 4，而不是 PID 1？

Question

我的 Google-fu 让我失望了！

在 Linux 上，PID 最低的进程的 PID 为init1，因为它是内核加载后第一个启动的进程，并负责启动所有其他进程。

pi@raspberry:~ $ ps -ef --sort=pid | head -n 5
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Jan22 ?        00:02:20 /sbin/init
root         2     0  0 Jan22 ?        00:00:00 [kthreadd]
root         3     2  0 Jan22 ?        00:05:54 [ksoftirqd/0]
root         5     2  0 Jan22 ?        00:00:00 [kworker/0:0H]

在 Windows 上，PID 最低的进程的 PID 为System4。

PS C:\Users\msbob> Get-Process | Sort-Object Id | Select -First 5

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
      0       0        0         24     0               0 Idle
    755       0      144        844     4               4 System
     32       1      556       1268     4             388 smss
    521      82   139796     124204   390     6.07    424 iexplore
    661      12     2268       4728    49             604 csrss

---

为什么SystemWindows上的PID是4，而不是 PID 1？

Answer 1

您会注意到所有 PID 都可以被 4 整除。因此，4 是 0 之后可用的第一个 PID（这是空闲进程）。

由于这是真的，请参阅Raymond Chen 的这篇 MSDN 帖子：

作为代码重用的副作用，进程和线程 ID 是 4 的倍数。分配内核句柄的相同代码也用于分配进程和线程 ID。由于内核句柄是 4 的倍数，因此进程和线程 ID 也是如此。

但请注意，进程 ID 实际上并不是这些进程可用的句柄值。这些数字只是由相同的算法生成的。

由于内核句柄总是可以被 4 整除的原因...... Raymond Chen再次来救援！

底部两位的可用性隐藏在 ntdef.h 头文件中：

// Low order two bits of a handle are ignored by the system and available 
// for use by application code as tag bits.  The remaining
// and used to store a serial number and table index.    
#define OBJ_HANDLE_TAGBITS  0x00000003L

（对于那些不熟悉二进制数的人：带有两个低位零的正二进制整数总是可以被 4 整除，就像以“00”结尾的十进制数总是可以被 100 整除一样。）

所以......一个异想天开的答案是第一个PID真的是“1”。只是任务管理器等人不知道在内部形式中它左移了两位。:)