Python免费线程模式评估CPU并发

我第一次评估 Python 免费线程模式，是因为一个图像预处理队列在多核机器上仍然只吃满一个核心。把 ThreadPoolExecutor 的线程数从 1 调到 8，并没有得到想象中的线性收益；真正需要先确认的是：当前解释器是否为 free-threaded 构建、运行时 GIL 是否真的关闭，以及依赖的扩展模块会不会把 GIL 重新打开。

官方资料：https://docs.python.org/3.14/whatsnew/3.14.html

Python 3.14 的免费线程模式已经成为受支持但仍可选的构建方式。它适合用基准测试评估 CPU 密集型线程任务，但不能把“线程数增加后耗时下降”简单归因于代码更快：构建、扩展模块、共享状态和单线程开销都要一起记录。

先把评估目标限定在 CPU 密集型线程

默认构建中，GIL 会限制多个线程同时执行 Python 字节码，因此线程更适合 I/O 等待。免费线程构建允许多个线程在可用 CPU 核心上并行执行 Python 代码，但这不是把所有 Python 程序自动加速。Python 官方文档也提醒，未准备好的 C 扩展可能在导入时重新启用 GIL。

这次我把目标限定为同一台机器、同一批输入、同一份 CPU 密集型纯 Python 函数。基准只回答“这段任务在这个解释器和这个线程数下是否有收益”，不回答“整个服务换成免费线程后一定更快”。

环境准备：先确认 GIL 到底是什么状态

不要只看 Python 主版本号。免费线程构建需要在构建时关闭 GIL；运行时还可以通过 PYTHON_GIL 或 -X gil 重新启用它。下面的检查脚本把构建能力和当前状态分开打印，方便把结果放进基准记录。

import sys
import sysconfig

# 读取构建能力：1 表示解释器支持 free-threading 构建。
gil_disabled = sysconfig.get_config_var("Py_GIL_DISABLED")

# 读取运行时状态：免费线程构建也可能被 -X gil 或 PYTHON_GIL 打开 GIL。
is_gil_enabled = getattr(sys, "_is_gil_enabled", None)
runtime_gil = is_gil_enabled() if is_gil_enabled else None

print("version:", sys.version)
print("free_threaded_build:", gil_disabled == 1)
print("gil_enabled:", runtime_gil)

如果 free_threaded_build 是 False，这次只能得到默认构建的对照数据；如果构建支持但 gil_enabled 为 True，则要先检查启动参数和环境变量。编译 CPython 时可使用 --disable-gil，官方 macOS 和 Windows 安装包也提供可选的免费线程二进制。

用相同工作量比较三条执行路径

我习惯把单线程、默认线程池和免费线程线程池都保留，因为只有这样才能看出并行收益是否抵消了线程调度成本。不要每条路径使用不同的数据量，也不要把第一次导入依赖的时间混进结果。

from concurrent.futures import ThreadPoolExecutor
from time import perf_counter

def cpu_task(seed: int) -> int:
    # 固定迭代次数，制造可比较的纯 Python CPU 工作量。
    value = seed
    for index in range(1, 180_000):
        value = (value * 33 + index) % 1_000_003
    return value

def measure(workers: int, jobs: int) -> tuple[float, int]:
    started = perf_counter()
    if workers == 1:
        # 单线程基线避免线程池调度影响。
        values = [cpu_task(seed) for seed in range(jobs)]
    else:
        # 相同输入交给线程池，观察构建和运行时 GIL 的实际影响。
        with ThreadPoolExecutor(max_workers=workers) as pool:
            values = list(pool.map(cpu_task, range(jobs)))
    elapsed = perf_counter() - started
    return elapsed, sum(values)

jobs = 8
for workers in (1, 2, 4, 8):
    seconds, checksum = measure(workers, jobs)
    # 校验和用于确认不同线程数处理的是同一批结果。
    print(f"workers={workers} seconds={seconds:.3f} checksum={checksum}")

结果比较时看中位数而不是单次最小值。先预热一次，再重复 5 次；记录 CPU 型号、物理核心数、Python 构建信息、线程数、任务数量和校验和。免费线程模式有额外开销，轻量任务可能比默认构建更慢，不能只看峰值吞吐。

生产接入前要检查扩展模块和共享状态

纯 Python 基准有收益，不代表业务依赖链已经准备好。导入不支持免费线程的 C API 扩展时，GIL 可能被自动重新启用；因此我会把依赖分成三类：明确支持免费线程、导入后重新启用 GIL、尚未确认。第三类不能直接进入生产灰度。

另外，内置 dict、list 和 set 当前有一定内部保护，但这不是业务级同步契约。共享队列、缓存更新、计数器和复合读改写仍应使用 threading.Lock 等同步原语。尤其不要让多个线程同时消费同一个迭代器，也不要从其他线程读取正在执行帧的 f_locals。

from threading import Lock

total = 0
total_lock = Lock()

def add_amount(amount: int) -> None:
    global total
    # 复合更新必须由业务锁保护，不能依赖解释器内部实现细节。
    with total_lock:
        total += amount

把结果写成可审计的发布检查

我不会用一次跑分直接切换解释器，而是把结果拆成“可迁移”和“暂缓”两种结论。满足以下条件才值得做小流量灰度：构建能力和运行时状态确认一致；线程数增加后中位耗时稳定下降；关键扩展没有偷偷重新启用 GIL；共享状态有明确锁或消息传递边界；内存增长和单线程回退开销在预算内。

记录时至少保留三组数据：默认构建的基线、免费线程构建且 GIL 开启的对照、免费线程构建且 GIL 关闭的目标结果。这样即使后续某个依赖让 GIL 重新打开，也能快速判断性能回退来自哪里。

几个容易混淆的问题

免费线程模式是不是把普通线程自动变快了？

不是。它改变的是解释器允许线程并行执行 Python 代码的条件；任务本身、依赖模块和共享状态仍可能成为瓶颈。

为什么免费线程构建的单线程结果反而变慢？

免费线程构建需要额外的并发安全开销，官方文档也提示单线程性能会有一定损失。是否值得迁移，要用业务负载的并行收益覆盖这部分成本。

线程数越多越好吗？

不是。线程数超过可用核心后，调度和缓存竞争会吞掉收益。基准至少覆盖 1、2、4 和接近机器核心数的线程数。

什么时候继续用 multiprocessing？

当依赖链无法确认免费线程兼容、共享状态难以收敛，或者进程隔离本身就是需求时，进程池仍然是更稳妥的选择。

我的结论是：Python 免费线程模式值得评估，但评估对象应该是“解释器构建 + 依赖链 + 具体 CPU 任务”的组合。先把环境状态和基准结果记录清楚，再决定是否灰度，通常比直接把线程数改成 8 更接近真实收益。