Python 3.14 多解释器如何分配独立任务

Python 3.14 可以用 concurrent.futures.InterpreterPoolExecutor 把任务分配给同一进程中的多个独立解释器。每个 worker 有自己的运行时状态和 GIL，因此适合彼此独立、计算量较大的函数；代价是函数、参数和返回值要跨解释器序列化，不能把一个解释器里的可变对象当成共享内存来用。

先把任务设计成可独立传输的顶层函数

多解释器的第一道边界不是 worker 数量，而是任务接口。下面的函数只接收一批整数，返回一个整数；它不读取主解释器里的可变全局列表，也不把打开的文件句柄传进 worker。这样的函数才容易被复制到独立解释器中执行。

from math import isqrt


def is_prime(number: int) -> bool:
    # 只判断当前数字，避免依赖跨解释器共享的可变状态。
    if number  int:
    # tuple 便于明确表示“这一批输入”，返回值也保持可序列化。
    return sum(is_prime(number) for number in numbers)

这里的关键不是质数算法，而是函数边界：count_primes 可以被单独导入，参数是整数元组，返回值是整数。不要直接提交 lambda、局部函数，或依赖只在主模块里临时创建的对象；跨解释器传输默认要经过 pickle。

用 InterpreterPoolExecutor 创建解释器池

任务准备好后，用法仍然接近熟悉的 Future API。每个批次是一个独立任务，submit 返回一个 Future；max_workers 不宜盲目等于机器逻辑核数，应该给主线程、内存和其他服务留出余量。

from concurrent.futures import InterpreterPoolExecutor, as_completed


def split_batches(values: list[int], size: int) -> list[tuple[int, ...]]:
    # 把大输入切成独立批次，避免一个 Future 搬运全部数据。
    return [tuple(values[index:index + size])
            for index in range(0, len(values), size)]


def run_parallel(values: list[int]) -> int:
    batches = split_batches(values, size=2_000)
    total = 0
    with InterpreterPoolExecutor(max_workers=4) as executor:
        # 顶层函数和批次参数会被序列化到各自的解释器。
        futures = [executor.submit(count_primes, batch) for batch in batches]
        for future in as_completed(futures):
            # result() 会把 worker 的返回值带回主解释器。
            total += future.result()
    return total

这段代码展示的是分配模型，不是“线程共享列表”的写法。解释器之间不会自动共享 sys.modules、模块全局变量或可变对象；如果 worker 需要初始化依赖，可以使用 initializer，但初始化函数和参数同样要经过序列化。

按 Future 收集结果并处理异常

Future 让主解释器可以把成功值和失败任务统一收口。真实项目里不要只在最后调用一次 result()；应该把每个 Future 与输入批次关联，出现异常时记录是哪一批失败。worker 抛出的原始异常如果能被保留，会带有对应的 ExecutionFailed 摘要；初始化失败还可能使解释器池进入不可继续提交的状态。

from concurrent.futures import as_completed


def collect_results(executor, batches):
    # 保存 Future 到输入批次的映射，失败时仍能定位原始数据。
    future_to_batch = {
        executor.submit(count_primes, batch): batch
        for batch in batches
    }
    results = []
    failures = []
    for future in as_completed(future_to_batch):
        batch = future_to_batch[future]
        try:
            results.append((batch, future.result()))
        except Exception as exc:
            # 记录批次和异常，避免主线程静默丢失失败任务。
            failures.append({"batch": batch, "error": repr(exc)})
    return results, failures

若任务函数、参数或返回值无法 pickle，问题会在提交或取回结果时暴露；这和函数内部主动抛出的业务异常不是一回事。把数据缩小成整数、字符串、字典、元组等明确契约，通常比把大型对象硬塞进 worker 更容易排查。

根据数据传输和依赖兼容性做取舍

因此，落地顺序建议是：先用一个可序列化的小任务验证正确性，再测批次大小和 worker 数量，最后检查依赖包是否支持多解释器。Python 3.14 的这个执行器解决的是“独立任务如何绕开单一解释器的 GIL”，并没有替你解决数据建模、资源共享和第三方扩展隔离。

常见问题

InterpreterPoolExecutor 和 ThreadPoolExecutor 最大区别是什么？

两者都使用线程池接口，但前者让每个线程拥有独立解释器和独立 GIL，适合 CPU 密集型 Python 代码；普通线程仍共享同一个解释器运行时。

任务函数可以写成 lambda 吗？

不建议。跨解释器提交会序列化可调用对象，使用模块顶层、可导入的普通函数最稳妥，lambda 和局部函数容易在序列化边界失败。

为什么 worker 里看不到主线程的全局变量？

这是隔离设计的一部分。每个解释器有独立的模块和运行时状态，需要共享的数据应显式放进参数、返回值或专门的跨解释器通信机制。

Python 3.13 能直接使用这个类吗？

标准库中的 InterpreterPoolExecutor 从 Python 3.14 起提供；旧版本应评估 ProcessPoolExecutor 或其他并行方案，不能只改一个 import 就假设语义完全相同。