Python multiprocessing spawn 传递初始化配置的方案

在 spawn 启动方式下，子进程会启动一个新的 Python 解释器，父进程后来修改的可变全局变量不会自动变成子进程的可靠配置。更稳妥的做法是：把小型、可序列化的配置放进 Pool 的 initargs，由 initializer 在每个 worker 启动时复制到该进程自己的模块变量中。

官方地址：https://docs.python.org/3/library/multiprocessing.html

这个方案适合超时秒数、服务地址、批处理开关等稳定配置；不适合直接传打开的文件、锁、socket 或连接池。任务本身的输入仍然应该通过 map、starmap 或任务函数参数传递。

先区分任务参数和进程初始化参数

任务参数描述“这一条任务要处理什么”，例如文件名或记录编号；初始化参数描述“这个 worker 启动后长期使用什么配置”。把两者混在一起，会让每次任务都重复传一份配置，也更容易误用父进程全局变量。

• initargs：进程池创建 worker 时传一次，适合稳定配置。
• map 输入：每条任务分别传递，适合业务数据。
• worker 内部创建的对象：适合只能在子进程内建立的连接、客户端或缓存。

用 initializer 和 initargs 建立 worker 配置

下面的示例让每个 worker 拿到一份自己的配置副本。代码只使用字典、字符串和整数，便于被 spawn 序列化；任务只接收业务编号，不重复携带配置。

import multiprocessing as mp

# 每个子进程各自维护这一份配置，不与父进程共享可变对象。
WORKER_CONFIG = {}


def init_worker(config):
    # 初始化函数只在 worker 启动时调用一次，并复制小型配置。
    global WORKER_CONFIG
    WORKER_CONFIG = dict(config)


def process_item(item_id):
    # 任务参数只描述当前数据，稳定配置从本进程的副本读取。
    timeout = WORKER_CONFIG["timeout"]
    endpoint = WORKER_CONFIG["endpoint"]
    return f"{item_id}|{endpoint}|timeout={timeout}"


if __name__ == "__main__":
    # spawn 会重新导入主模块，进程池必须放在入口保护内。
    ctx = mp.get_context("spawn")
    config = {"endpoint": "https://api.example.test", "timeout": 3}

    # initargs 必须是参数元组，所以单个字典也要写成 (config,)。
    with ctx.Pool(
        processes=2,
        initializer=init_worker,
        initargs=(config,),
    ) as pool:
        result = pool.map(process_item, ["A-01", "A-02"])
        print(result)

关键点是 initializer=init_worker 与 initargs=(config,) 成对出现。initializer 不是每条任务执行前的钩子，而是每个 worker 建立时的初始化函数；因此连接、客户端等资源如果需要创建，应在这个函数内部根据配置建立，而不是把已打开的对象从父进程传过去。

配置对象怎么设计，哪些值可以安全传给 spawn

配置应尽量是边界清晰的值对象：字符串、数字、布尔值、列表、元组和由这些值组成的字典通常更适合序列化。打开的文件句柄、线程锁、socket、数据库连接和带内部状态的客户端，不应作为 initargs 直接传入；把连接信息传过去，再由 init_worker 在子进程内创建资源。

另外，顶层定义的函数更容易被新解释器导入。不要把 worker 函数或初始化函数写成只存在于局部作用域的闭包，也不要在模块顶层创建进程池。主入口保护解决的是“子进程导入主模块时又执行一遍创建逻辑”，它与配置是否可序列化是两个独立条件。

初始化失败、全局变量和资源生命周期

初始化函数失败时，问题属于 worker 启动阶段，不要把它当成某一条业务任务失败来重试。建议在初始化函数中只做必要的配置复制和资源建立，并让异常包含配置名称或资源类型，便于区分“传参失败”和“业务处理失败”。

如果配置需要更新，通常应创建新的进程池并传入新配置，而不是在父进程里修改字典后期待现有 worker 自动看到变化。若资源必须关闭，可以让 worker 使用上下文管理器或在任务完成后执行明确的清理逻辑；不要依赖父进程关闭一个子进程内的连接。

常见问题

为什么把配置写成全局变量后，spawn 子进程读到的还是旧值？

因为 spawn 会启动新的解释器，子进程重新导入模块；它看到的是导入时得到的模块状态，不是父进程之后修改的那份可变对象。把配置显式放入 initargs，或者作为任务参数传递，边界会更清楚。

单个配置字典为什么要写成 initargs=(config,)？

initargs 表示传给初始化函数的参数元组。少了逗号，(config) 仍然只是一个字典，不是单元素元组，初始化函数接收参数时就会出现结构不匹配。

小结：用 get_context("spawn") 固定启动方式，用 initializer + initargs 传递小型可序列化配置，用任务参数传递每条业务数据，并把池的创建放进 __main__ 入口保护中。这样既能避免依赖父进程全局变量，也能把不可跨进程传递的资源留在 worker 内部创建。