Python 3.15 免费线程模式进入生产评估：依赖兼容、压测指标与退出条件

团队把 Python 服务从“单线程够用”推到多核压测时，最容易误判的是：启动了 free-threaded 构建，就等于所有线程都能并行。Python 3.15 的文档仍把这条路线放在评估语境里，真正决定结果的却是 C 扩展、锁边界、单线程基线和内存账单。适合的做法是先在隔离环境建立对照组，再决定是否进入灰度。

Python 3.15 这次变化，解决的是哪一层瓶颈

免费线程模式（free-threaded build）沿着 PEP 703 的方向，把解释器的全局锁从默认执行路径中移开，让多个 Python 线程有机会同时使用多个 CPU 核心。它首先改变的是运行时构建和对象访问的并发条件，不是给现有代码自动加速的开关。

官方文档明确提醒：第三方扩展可能尚未支持 free threading，导入后会让 GIL 重新启用。于是一个看起来并行的服务，可能在入口阶段就回到了串行执行。评估的第一步不是改线程池大小，而是确认运行的到底是哪一种解释器。

先把两种运行时做成可重复的对照组

不要在同一台机器上只启动一个服务、看一次平均耗时就下结论。至少准备默认 GIL 构建和 free-threaded 构建，两者使用同一份依赖锁文件、同一批输入和同一套工作线程数。

import sys
import sysconfig

print(sys.version)
print("build_supports_free_threading:",
      sysconfig.get_config_var("Py_GIL_DISABLED") == 1)
print("gil_enabled_now:", sys._is_gil_enabled())

第一行用于留存构建身份；第二个值回答“这个解释器是否支持该能力”；第三个值回答“当前进程是否真的关闭了 GIL”。如果扩展导入后第三个值变成 True，先记录触发导入的模块，再决定是否替换依赖，别用更高并发掩盖回退。

依赖兼容检查要落到 C 扩展和共享状态

纯 Python 代码并不代表没有竞态。全局缓存、延迟初始化对象、复用迭代器和没有保护的统计容器，都要按多个线程同时读写来审视。C 扩展则要单独检查初始化标志、对象分配域以及曾经依赖 GIL 保护的全局状态。

可以把依赖清单分成三组：确认支持 free threading 的扩展、导入时会回退的扩展、尚未验证的扩展。第三组不能直接进入线上；至少要在隔离环境跑导入测试和并发回归，并把“GIL 是否重新启用”写进启动检查。

压测别只报吞吐，四个指标要一起看

对 CPU 密集型任务，先固定输入规模，再分别跑 1、2、4、8 个工作线程。把默认构建的单线程结果作为基准，比较 free-threaded 构建在相同线程数下的吞吐提升、P95/P99 延迟、进程 RSS 和锁等待时间。

什么时候值得继续，什么时候应该退出

如果任务主要等待网络或磁盘，免费线程模式未必能带来明显收益；如果任务是 CPU 密集型、依赖链支持良好，并且 P99 与 RSS 都在预算内，才有继续灰度的理由。这里的“通过”应当是一个可复现的组合结果，而不是一次漂亮的平均值。

退出条件也要提前写好：关键扩展触发 GIL 回退、共享状态出现数据竞争、单线程性能明显下降、P99 超过预算，或者内存增长无法解释。保留默认构建的镜像和锁文件，回滚时切换运行时即可，不要在故障现场临时删依赖。

常见问题

免费线程模式是不是完全没有 GIL？

不是。构建可以支持关闭 GIL，但某些扩展导入后会让它重新启用；必须在目标进程中检查状态。

为什么多线程吞吐没有明显上涨？

可能是任务本身受 I/O、锁或单线程 Python 开销限制，也可能是依赖让 GIL 回退。先看运行时状态和锁等待，再调线程数。

生产环境能否直接切换 Python 3.15？

不建议直接切换。先用隔离镜像完成依赖矩阵、数据竞争回归、资源压测和回滚演练，确认这些结果都在预算内后再做小流量灰度。

把评估结论写成一张发布清单

最终记录应包括解释器构建信息、依赖版本、GIL 状态、线程数、输入规模、吞吐、P99、RSS、锁等待和回滚镜像。这样团队讨论的就不是“新版本听起来更快”，而是某个具体服务在明确约束下是否值得承担这次运行时变化。