为何Python的multiprocessing.Process.start()无法保证进程启动？

问题复现代码 #

from multiprocessing import Process


def worker():
    print("Worker running")


if __name__ == "__main__":
    p = Process(target=worker)
    p.start()
    input("1...")
    input("2...")
    p.join()

运行环境：Python 3.13、Windows x64

实际输出 #

1...
2...
Worker running

Process finished with exit code 0

疑问 #

从输出可见，子进程实际是在第二次输入后才初始化并开始运行，而原本认为start()会阻塞并保证子进程完全初始化：

1. 这是Python multiprocessing的正常行为吗？
2. 改用Threading时此问题很少出现，线程通常会在input("1...")语句前运行，为什么会有这种差异？
3. 若Process.start()无法保证进程完全启动，应如何编写代码确保父进程继续执行前子进程已实际运行？

1. 这是multiprocessing的正常行为吗？ #

是的，这完全正常。Process.start()的作用是向操作系统提交创建子进程的请求，但它不会等待子进程完成初始化并开始执行代码——调用start()后父进程会立刻继续往下走。

在Windows系统上，Python 3.8+版本的multiprocessing默认采用spawn启动方式：父进程会启动一个全新的Python解释器进程，重新导入当前模块，再执行目标函数。这个过程涉及操作系统创建进程、加载Python解释器、初始化运行环境等步骤，本身需要一定时间，而父进程不会等待这些步骤完成，会直接执行后续的input语句。

而线程（threading）是在同一个进程空间内运行，创建和初始化的开销极小，所以线程的目标函数通常会很快开始执行，看起来像是在input前就运行了。

2. 如何确保父进程继续执行前子进程已启动？ #

需要通过进程间同步机制来实现，常用的有两种方式：

方式一：使用multiprocessing.Event

通过事件对象让子进程启动后通知父进程，父进程等待事件触发后再继续执行：

from multiprocessing import Process, Event


def worker(start_event):
    # 子进程启动后触发事件
    start_event.set()
    print("Worker running")


if __name__ == "__main__":
    start_event = Event()
    p = Process(target=worker, args=(start_event,))
    p.start()
    # 等待子进程触发事件，确认已启动
    start_event.wait()
    input("1...")
    input("2...")
    p.join()

此时输出会变为：

Worker running
1...
2...

Process finished with exit code 0

方式二：使用multiprocessing.Pipe

通过管道传递启动完成的信号：

from multiprocessing import Process, Pipe


def worker(conn):
    # 向父进程发送启动完成信号
    conn.send("started")
    conn.close()
    print("Worker running")


if __name__ == "__main__":
    parent_conn, child_conn = Pipe()
    p = Process(target=worker, args=(child_conn,))
    p.start()
    # 等待子进程的信号
    parent_conn.recv()
    parent_conn.close()
    input("1...")
    input("2...")
    p.join()

这种方式同样能确保父进程在子进程启动后才执行后续代码。

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