Python InterpreterPoolExecutor 怎么隔离不同任务的全局状态

InterpreterPoolExecutor 能隔离不同工作解释器的全局状态，但不会为每个任务自动创建一次性解释器。要隔离不同任务，最稳妥的做法是：把输入显式放进参数，在任务函数内部新建可变状态，并通过返回值带回结果；不要把模块级可变对象当成每任务临时区。

同一 worker 会使用自己的解释器执行多个任务。不同 worker 的模块对象彼此隔离，但同一个 worker 中后续任务仍可能看到它先前留下的模块全局状态。

官方文档：https://docs.python.org/3.14/library/concurrent.futures.html#interpreterpoolexecutor

我第一次按线程池的使用习惯理解这个执行器时，最容易产生的误会就是“解释器隔离”等于“任务隔离”。实际上，它更像是一个带独立 Python 运行时的 worker 池：隔离边界很强，但 worker 仍然会复用。

先看清隔离单位：worker，而不是 submit

InterpreterPoolExecutor 在 Python 3.14 加入标准库。它继承 ThreadPoolExecutor 的池接口，每个工作线程拥有自己的解释器；每个解释器有独立运行时状态、独立模块对象和自己的 GIL，因此纯 Python 代码可以在多个 CPU 核上并行。

这种隔离意味着：一个解释器里导入的模块不会自动出现在另一个解释器里；即使两个解释器都导入同一模块，它们得到的也是不同模块对象。sys、builtins 和 __main__ 同样各自独立，可变 Python 对象也不能直接被多个解释器同时使用。

但“每个 worker 一个解释器”不等于“每个任务一个解释器”。执行器会把任务调度给池中的可用 worker，因此模块级变量的生命周期通常跟随该 worker，而不是跟随一次 submit()。任务不应假设全局变量在开始时总是初始值。

我的默认选择：参数进入，局部状态计算，返回值离开

如果目标是让任务互不污染，我会优先把任务写成接近纯函数的形式。输入必须可序列化，任务内部新建字典、列表或业务对象，处理结束后只返回必要结果。官方文档说明，执行器会用 pickle 序列化 callable、参数和返回值，所以顶层函数与普通可序列化数据最省心。

from concurrent.futures import InterpreterPoolExecutor


def transform(job: tuple[str, int]) -> dict[str, int | str]:
    name, start = job
    local_state = {"count": start}  # 每次调用都创建自己的可变状态
    local_state["count"] += 1
    return {"name": name, "count": local_state["count"]}  # 只返回可序列化结果


def main() -> None:
    jobs = [("alpha", 0), ("beta", 100), ("gamma", 1000)]

    with InterpreterPoolExecutor(max_workers=3) as executor:
        results = list(executor.map(transform, jobs))  # 池关闭前收集全部任务结果

    print(results)  # 主解释器统一处理输出，工作器不修改共享全局变量


if __name__ == "__main__":
    main()  # 保持入口明确，方便未来切换其他执行器

这个写法的好处不是代码短，而是状态生命周期一眼就能看懂：local_state 只属于一次函数调用，任务之间没有隐式依赖。对我来说，这比尝试在任务前后清空若干全局缓存可靠得多。

initializer 适合每 worker 配置，不适合每任务重置

initializer 会在每个工作解释器创建时运行一次，initargs 也会被序列化后传入。它适合加载只读配置、创建每 worker 客户端或预热昂贵资源，但不代表每个任务执行前都会再次调用。

from concurrent.futures import InterpreterPoolExecutor
import json

_worker_config: dict[str, int] | None = None


def init_worker(config_json: str) -> None:
    global _worker_config
    _worker_config = json.loads(config_json)  # 每个工作解释器建立自己的配置副本


def calculate(value: int) -> int:
    if _worker_config is None:
        raise RuntimeError("worker 未初始化")  # 初始化异常应尽早暴露

    factor = _worker_config["factor"]
    return value * factor  # 读取每 worker 配置，不在任务里修改它


def main() -> None:
    config_json = json.dumps({"factor": 3})

    with InterpreterPoolExecutor(
        max_workers=2,
        initializer=init_worker,
        initargs=(config_json,),
    ) as executor:
        results = list(executor.map(calculate, [2, 4, 6]))  # 多个任务可复用同一工作器配置

    print(results)


if __name__ == "__main__":
    main()  # 初始化器用于工作器生命周期，而不是任务生命周期

如果把可变缓存放在模块全局中，它只会与其他解释器隔离，不会与同一解释器里的后续任务隔离。这样的缓存可以有意设计成“每 worker 缓存”，但必须接受命中不确定、任务分配不可控，以及缓存需要显式失效等代价。

三种执行器的状态边界怎么比较

这里有一个常被忽略的取舍：InterpreterPoolExecutor 隔离了 Python 运行时对象，不会自动隔离文件、数据库、套接字或外部服务。多个任务仍可能同时修改同一文件或同一数据库记录，外部状态必须用事务、幂等键、文件锁或显式消息协议协调。

真的要求每个任务都是全新环境怎么办

如果任务涉及不可信插件、无法清理的第三方库状态，或业务明确要求“一次任务后彻底丢弃运行时”，那么 InterpreterPoolExecutor 不是最直接的选择。它没有等价于 ProcessPoolExecutor(max_tasks_per_child=1) 的公开参数。

此时可以评估 ProcessPoolExecutor 的 worker 回收。把 max_tasks_per_child 设为 1，每个工作进程完成一个任务后退出，由池补充新进程。代价是启动、导入和内存开销明显增加，而且函数、参数与结果仍需可序列化，__main__ 也必须可导入。

不适用情况与明显代价

• 大量闭包、lambda 或不可序列化对象：提交边界会变得难维护，应先改成顶层函数和明确数据结构。
• 依赖尚未支持多解释器的扩展模块：需要逐项核实兼容性，不能只因为模块能导入就认定安全。
• 任务频繁交换大型可变对象：序列化和复制成本可能抵消并行收益，进程池也有类似代价。
• 必须共享实时可变内存：解释器隔离本身会让这种设计更复杂，应考虑显式通道、外部存储或重新划分任务。

决策表

我的结论是：把 InterpreterPoolExecutor 当成“解释器隔离的 worker 池”，而不是“一次性沙箱池”。大多数任务只要遵守显式输入、局部状态、显式输出，就能获得清晰隔离；只有状态无法可靠清理时，才值得支付每任务回收进程的成本。

相关问题

不同解释器能直接共享 list 或 dict 吗？不能把同一个可变对象直接交给多个解释器同时使用；应复制、序列化或使用专门的解释器通信工具。

同一个模块在两个 worker 中是同一个对象吗？不是。每个解释器有自己的模块对象和模块全局状态。

把全局变量改成线程局部变量有用吗？这不能表达每任务生命周期；任务仍可能复用同一个工作线程与解释器。任务局部状态应放在 callable 的局部变量中。