Python 3.14 free-threaded 模式怎么测：线程并发收益、锁竞争与回退边界

Python 3.14 提供的 free-threaded 构建很值得测试，但不要用“跑一次总耗时”直接下结论。这个特性从 Python 3.13 开始就提供了关闭 GIL 的构建选项，实际收益要看线程是不是在处理 CPU 密集工作、任务之间是否频繁争抢共享状态，以及导入的扩展模块会不会让 GIL 重新启用。可靠的做法是先固定任务量，再分别测试普通构建、free-threaded 构建和带锁、无共享状态两种实现，最后记录解释器实际运行状态。

free-threaded 不是“所有线程代码自动变快”：先确认解释器没有重新启用 GIL，再用相同任务量比较并发收益和锁竞争成本。

先确认测到的确实是 free-threaded 构建

官方文档建议用 sysconfig.get_config_var("Py_GIL_DISABLED") 判断构建是否支持 free-threading，再用 sys._is_gil_enabled() 判断当前进程中的 GIL 是否开启。两者分别回答“这个解释器能不能关闭”和“这一次运行有没有真的关闭”。

import sys
import sysconfig

print(sys.version)
print("build_supports_free_threading =", sysconfig.get_config_var("Py_GIL_DISABLED") == 1)
print("gil_enabled =", sys._is_gil_enabled() if hasattr(sys, "_is_gil_enabled") else "not available")

普通 Python 3.14 构建不应被误写成 free-threaded。free-threaded 构建可以在运行时通过 PYTHON_GIL 或 -X gil 重新打开 GIL，因此基准日志里要把命令行、环境变量和版本完整保存。

基准任务要先排除输入差异

第一轮不要拿网络请求、随机数据或不稳定的磁盘操作当主指标。用纯 Python 的整数运算制造固定 CPU 工作量，每个 worker 只接收自己的专属区间，避免因为共享队列的等待把线程执行时间和调度时间混在一起。

from concurrent.futures import ThreadPoolExecutor
from time import perf_counter

def work(start: int, stop: int) -> int:
    total = 0
    for value in range(start, stop):
        total += (value * value) % 1000003
    return total

def run(workers: int, total: int = 12_000_000) -> float:
    step = total // workers
    ranges = [(i * step, (i + 1) * step if i 

先预热一次，再重复至少五轮并记录中位数和离散程度。不要只比较最快的一次，线程调度、CPU 降频和后台任务都会让单次结果偏乐观。

把普通构建和 free-threaded 构建放在同一张表

测试矩阵至少包含 1、2、4 个线程，并在普通构建与 free-threaded 构建中使用相同的任务总量。结果不要预先填预设的加速数字，直接用实际机器跑出来的中位数计算。下面这张表是标准记录格式：

如果 free-threaded 的四线程结果没有明显改善，不代表功能失效。任务可能太短、线程数超过物理核心，或者 Python 代码在共享对象上频繁停顿。此时应该继续拆分测试，不要直接下结论说“线程没用”。

共享状态会把并行收益换成锁竞争

下面的计数器示例很适合展示这类风险：多个线程不断更新同一个可变对象时，即使容器操作有内部保护，读取、计算、写回组成的复合动作仍然需要业务层同步。更稳妥的基准是让 worker 返回局部结果，主线程最后汇总；这种写法既能减少锁竞争，也让测量结果更接近可扩展的批处理代码表现。

# 推荐：worker 只返回局部结果，最后集中合并
def local_work(start: int, stop: int) -> int:
    return sum((value * value) % 1000003 for value in range(start, stop))

# 需要共享状态时，明确保护复合更新
from threading import Lock
counter = 0
counter_lock = Lock()

def add_one() -> None:
    global counter
    with counter_lock:
        counter += 1

建议把“局部结果汇总”和“共享计数器加锁”作为两个独立用例。前者观察可扩展的工作负载，后者观察锁的成本与正确性；把它们混在一起，无法判断变慢究竟来自 GIL、锁还是任务本身过小。

第三方扩展可能改变最终结果

free-threaded 构建并不保证所有依赖都保持无 GIL 状态。官方文档说明，尚未准备好的扩展模块可能在导入时重新启用 GIL，并给出警告。遇到这种情况，基准日志应记录导入顺序、警告内容和 sys._is_gil_enabled() 的最终值；否则你看到的可能只是普通 GIL 构建的结果。

如果项目包含 C 扩展，还要确认它有对应的 free-threaded wheel 或重新构建产物。扩展作者需要关注 Py_GIL_DISABLED、内部全局状态、借用引用和直接访问结构字段等边界，应用开发者则应把“不支持的依赖”列入回退清单。

用三组断言判断是否值得采用

• 可重复：相同输入、线程数和机器状态下，重复运行的中位数差异在可接受范围内。
• 确实并行：free-threaded 构建没有在运行途中重新开启 GIL，且多线程结果相对单线程有可解释变化。
• 业务正确：共享状态、异常传播和资源释放在不同线程数下都通过断言校验。

最终测试记录至少保留解释器版本、构建标识、GIL 状态、CPU 核数、线程数、任务总量、重复次数、中位耗时和依赖版本。这些信息同时留存，之后换机器或换依赖版本时才有复测的参照依据。

常见问题

free-threaded 构建能替代 multiprocessing 吗？

不能直接替代原有多进程方案。它适合共享内存、线程模型已经成立且依赖支持良好的场景；进程模型的隔离、启动和数据传输成本仍然是另一组需要权衡的取舍项。

容器操作有内部保护就不用加锁了吗？

不能这样推断。单次容器操作与“读取—计算—写回”这类复合动作不同，业务状态仍需要明确的同步或者改成局部结果汇总的写法。

为什么要测一线程？

一线程测试是同一构建的基线。没有它，就无法区分构建本身的单线程开销和多线程扩展收益。

总结

Python 3.14 free-threaded 模式的价值要靠可重复的基准测试证明。先确认实际 GIL 状态，再用固定任务量对比不同线程数表现；把无共享状态、显式加锁和第三方扩展回退场景分开测试，最后用中位数和正确性断言共同验收。这样得到的结论才足以指导真实场景下的运行时选型。