Python multiprocessing forkserver 何时比 spawn 合适

如果你的程序运行在支持 Unix 文件描述符传递的 POSIX 系统上，任务函数和参数都能被 pickle，且你希望避开直接 fork 多线程进程的风险，同时减少每个子进程从零启动解释器的成本，那么 forkserver 通常比 spawn 更合适。Windows、macOS 或需要兼容冻结可执行文件时，优先考虑 spawn；跨平台库则应把上下文交给调用方。

先看结论：forkserver 与 spawn 解决的问题不同

spawn 的模型很简单：父进程请求一个全新的解释器，子进程只接收运行目标所需的对象。它不会把父进程里不必要的文件描述符和句柄带过去，所以更容易获得干净的进程边界。代价是导入模块、构造运行环境和序列化参数都会重复发生。

forkserver 则在程序选择该方法时先启动一个服务器。之后创建 worker 的请求交给服务器，由服务器 fork 出子进程。服务器通常是单线程的，既避开了直接 fork 一个可能已经启动多线程库的父进程，又保留了一部分 fork 的启动效率。它不是“无须序列化”的 fork 变体：任务函数、参数以及需要跨进程传递的对象仍然要满足 pickle 约束。

用 get_context 明确配置，不依赖机器默认值

生产代码不要把“本机默认启动方法”当作业务契约。先查询当前解释器支持的方式，再为这一组进程获取独立上下文。这样可以避免库代码偷偷改变宿主应用的全局设置，也能让测试显式覆盖两种启动方式。

import multiprocessing as mp

def worker(value):
    # 任务函数放在模块顶层，保证 spawn 和 forkserver 都能定位它。
    return value * value

if __name__ == "__main__":
    # 先查看平台支持的启动方式，不把默认值写死在业务判断里。
    print(mp.get_all_start_methods())
    ctx = mp.get_context("forkserver")
    with ctx.Pool(processes=2) as pool:
        # map 的参数必须可 pickle，返回值按输入顺序收集。
        values = pool.map(worker, [2, 3, 4])
    print(values)

如果目标机器不支持 forkserver，get_context 会抛出 ValueError，这比悄悄退回另一种语义更安全。应用可以在明确的部署策略里选择备用上下文，但库不要自行强制全局 set_start_method()。

用可序列化任务验证 forkserver 的适用性

真正的判断点不在“能否启动一个进程”，而在真实任务能否稳定地通过进程边界。把入口放在 if __name__ == "__main__" 中；不要把 lambda、REPL 临时函数、局部函数或打开的连接对象直接作为目标和参数。共享锁、队列等对象也应由同一个上下文创建，不能把 fork 上下文的锁交给 forkserver 或 spawn 的子进程。

import multiprocessing as mp

def inspect_task(number, queue):
    # 子进程只接收普通数字和同一上下文创建的队列。
    queue.put((mp.current_process().name, number + 1))

if __name__ == "__main__":
    # 选择上下文后，Queue、Process 都从它创建，避免跨上下文传对象。
    ctx = mp.get_context("forkserver")
    result_queue = ctx.Queue()
    process = ctx.Process(target=inspect_task, args=(7, result_queue))
    process.start()
    process.join()
    # join 只等待结束，仍要检查 exitcode 判断任务是否成功。
    if process.exitcode != 0:
        raise RuntimeError(f"worker exitcode={process.exitcode}")
    print(result_queue.get())
    result_queue.close()
    result_queue.join_thread()

从启动成本、隔离性和部署环境做取舍

选择时可以按三问落地：第一，部署是否只覆盖 POSIX？如果答案是否定的，spawn 往往更省维护成本。第二，父进程是否已经加载了会启动线程的库？如果是，直接 fork 的风险更高，forkserver 值得优先评估。第三，任务是否会大量创建短生命周期 worker？如果会，forkserver 可能比反复启动全新解释器更划算，但应通过基准测试确认，而不是凭感觉切换。

Python 3.14 文档说明，POSIX 默认方法已改为 forkserver，Windows 和 macOS 默认仍是 spawn。这不代表应用可以删除显式配置：容器基础镜像、Python 小版本和部署方式都可能改变实际环境。把启动方法、平台和基准结果写进测试与部署说明，升级时才容易发现行为变化。

常见问题：默认方法、混用上下文和冻结程序

为什么不用 fork，直接复制父进程状态不是更快吗？

直接 fork 会继承更多父进程资源，而多线程状态与系统库的组合可能不安全。速度优势不能替代进程安全，除非你明确掌握运行环境和库的 fork 约束。

forkserver 和 spawn 可以在同一个项目里混用吗？

可以通过不同的 get_context() 创建不同对象，但锁、队列等上下文相关对象不能随意交叉传递。除非确有隔离需求，否则一个进程池统一一种上下文更容易维护。

为什么在命令行交互环境里示例经常失败？

spawn 和 forkserver 需要从可导入模块中定位目标函数；REPL 或临时定义的 __main__ 往往不满足这个条件。把代码保存为模块并保护入口，结果更接近生产运行。

冻结程序一定要用 spawn 吗？

不能简单下结论。Python 官方文档提示，POSIX 上的 spawn 和 forkserver 通常不能用于 PyInstaller、cx_Freeze 等冻结可执行文件，应根据打包方式和目标平台单独验证。

实际项目的默认策略可以是：跨平台先选 spawn，POSIX 上有大量进程创建且希望降低多线程 fork 风险时评估 forkserver，最后用同一批真实任务比较启动时间、吞吐和异常恢复，而不是只比较一个最小 demo。