为何首次发送SIGSTOP后进程停驻延迟无界，再次发送则立即生效？

• 第一次发送SIGSTOP时，进程不会瞬间进入完全停止状态：
  Linux内核收到SIGSTOP信号后，会尝试将进程从运行态切换到TASK_STOPPED状态，但如果进程当时正处于内核态的临界执行环节（比如在执行某个系统调用的内核逻辑、持有内核锁），内核不能强行打断它，必须等它退出这个临界区才能完成挂起。这段等待期间，进程的CPU占用会被正常统计，导致你看到STOPPED状态的进程还在占CPU。

• 第二次发送SIGSTOP时的变化：
  当进程已经完成内核临界区的执行、真正进入停止态后，再次发送SIGSTOP，内核会直接忽略这个信号（因为SIGSTOP的目标是停止运行中的进程，对已停止的进程无额外操作）。此时你看到CPU占用清零，本质是第一次挂起的收尾工作已经完成，进程彻底进入无活动的停止状态，加上系统CPU统计周期的更新，最终显示为0。

另外需要注意，top、ps这类工具的CPU使用率是按固定周期采样统计的，第一次发送信号后的统计周期里，进程可能刚好残留了未更新的CPU时间记录，第二次操作后进入下一个统计周期，数据就同步成真实的0占用了。

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