我来帮你理清RHEL7里PID分配的这些问题，结合内核逻辑和实际运维经验来说明：

一、RHEL7的PID分配机制，以及重启后是否会复用PID #

• RHEL7基于Linux内核，PID采用循环顺序分配的逻辑：
  • 内核会维护一个pidmap数组，用来跟踪所有已被占用的PID；同时还有个last_pid变量，记录下一个要尝试分配的PID值。
  • 当新进程创建时，内核从last_pid开始往后找第一个未被占用的PID分配给它；如果遍历到PID上限（默认是32768，你可以通过cat /proc/sys/kernel/pid_max查看，也能修改这个值），就会从最小的可用PID（一般是1，systemd的固定PID）重新开始循环查找空闲PID。
• 重启后PID肯定会被复用：系统重启时所有用户态进程都会被销毁，内核的pidmap和last_pid都会被重置。新系统启动后，进程会重新从起始点分配PID，之前用过的PID没有任何“锁定”机制，完全可能被再次分配给新进程。

二、重启后进程拿到相同PID的概率分析 #

这个概率得结合实际场景来看，不能一概而论：

1. 实际运维中的高概率情况 #

就像你举的守护进程A的例子：

• RHEL7用systemd管理服务，服务的启动顺序由unit文件的依赖关系、启动优先级决定。如果重启前后系统的服务配置、依赖关系完全没变，那守护进程A的启动时机和顺序几乎和之前一模一样。
• 因为PID是顺序分配的，前面启动的进程数量和种类都不变的话，守护进程A大概率会拿到和之前相同的PID（比如例子里的544）。这种情况下，概率接近100%——这也是为什么很多运维同学会发现，稳定环境里的系统服务PID每次重启都不变。

2. 理论上的极端低概率 #

如果完全忽略启动顺序的确定性（比如系统启动时进程启动顺序完全随机，这在实际中几乎不可能发生），假设PID是从1到pid_max里随机挑一个空闲值，那拿到某个特定PID的概率大概是1/(pid_max - 1)（排除固定占用的PID1）。默认pid_max是32768，所以这个概率约为1/32767，非常低。

总结 #

实际生产环境中，只要系统配置、服务启动顺序没变化，像守护进程这类有固定启动时机的进程，重启后拿到相同PID的概率极高；只有当系统新增/删除服务、启动顺序改变，或者有临时进程干扰时，PID才会发生变化。

内容的提问来源于stack exchange，提问作者boardrider