Python 3.14 并发三叉戟深度拆解：无 GIL 自由线程正式转正、子解释器与尾调用解释器，CPython 三十年枷锁的终章

写在前面：一个困扰 Python 三十年的老问题

如果你写过 Python 的多线程代码，大概率被同一件事恶心过：明明开了 8 个线程跑一段纯计算，htop 里却只有一个核在满负荷,其余 7 个核在旁边看戏。你没写错代码，是 GIL（Global Interpreter Lock，全局解释器锁）在替你"限速"。

这个设计从 1992 年 CPython 诞生起就存在，中间无数人想干掉它，无数次失败。Larry Hastings 那个著名的 "Gilectomy"（GIL 切除术）项目折腾了好几年，最后单线程性能倒退了近一倍，无疾而终。GIL 成了 Python 社区里"人人喊打、人人无解"的经典难题。

2025 年 10 月 7 日发布的 Python 3.14，是这件事真正的转折点。它一口气端出了三种并发方案，我称之为"并发三叉戟"：

1. 自由线程（Free-threading）：PEP 703 落地、PEP 779 宣布"正式支持"（从实验特性转正）。GIL 可以被真正关掉，多线程终于能吃满多核。
2. 子解释器（Sub-interpreters）：PEP 734 把多解释器搬进标准库 concurrent.interpreters，每个解释器一把独立 GIL（PEP 684），提供介于线程和进程之间的隔离模型。
3. 尾调用解释器（Tail-call interpreter）：一种全新的解释器主循环实现，用编译器的尾调用能力重写字节码分发，让"没关 GIL 的普通 Python"也白捡一点性能。

这篇文章不打算做成 changelog 的翻译。我想从第一性原理出发，把 GIL 到底锁了什么、自由线程在 CPython 内核里动了哪些刀、三条路线各自适合什么场景、以及迁移时会踩哪些坑，一次性讲透。全文偏工程实战，代码能跑、结论能落地。

一、先讲清楚：GIL 到底锁的是什么

要理解自由线程有多难，得先理解 GIL 为什么存在。很多人以为 GIL 是"Python 之父故意留的枷锁"，其实它是引用计数内存管理的一个副产品。

1.1 一切从引用计数说起

CPython 用引用计数做内存管理。每个对象头里有个 ob_refcnt 字段，记录当前有多少个引用指向它。引用 +1、解引用 -1，归零就立刻释放：

// CPython 对象头的简化结构
typedef struct _object {
    Py_ssize_t ob_refcnt;   // 引用计数
    PyTypeObject *ob_type;  // 类型指针
} PyObject;

// Py_INCREF / Py_DECREF 的核心逻辑（简化）
#define Py_INCREF(op)  ((op)->ob_refcnt++)
#define Py_DECREF(op)  do {                 \
    if (--(op)->ob_refcnt == 0)             \
        _Py_Dealloc((PyObject *)(op));      \
} while (0)

问题来了：ob_refcnt++ 和 --ob_refcnt 不是原子操作。它在机器层面是"读—改—写"三步。如果两个线程同时对同一个对象做 INCREF/DECREF，就会发生经典的竞态：

线程 A 读到 refcnt = 2
线程 B 读到 refcnt = 2
线程 A 写回 refcnt = 3
线程 B 写回 refcnt = 3   // 本该是 4！丢了一次计数

计数少算一次，对象会被提前释放，之后任何访问都是 use-after-free，直接段错误。这是内存安全级别的 bug，比数据错乱严重得多。

1.2 GIL：用一把大锁换省心

CPython 的解决办法简单粗暴：给整个解释器加一把全局锁。任何线程想执行字节码，必须先拿到 GIL。这样一来，同一时刻只有一个线程在跑 Python 代码，引用计数天然串行化，ob_refcnt++ 不用加原子指令也绝对安全。

代价也很明显：

• CPU 密集型多线程完全无法利用多核。8 核机器上 8 个计算线程，实际吞吐≈单核，还要额外付出线程切换和抢锁的开销，经常比单线程还慢。
• I/O 密集型能受益，因为线程在等 socket/文件时会主动释放 GIL，别的线程可以补位。这也是为什么"Python 多线程只适合 I/O"这句话流传甚广。

于是长期以来 Python 的并行只有一条正路：multiprocessing 多进程。但进程有它自己的税——内存翻倍、启动慢、进程间通信要序列化。

1.3 为什么去 GIL 这么难

历史上多次尝试失败，核心矛盾就一句话：你把大锁拆成无数把小锁，单线程性能会崩。

Gilectomy 用原子操作替换所有引用计数，结果每次 INCREF 都变成一条 lock xadd 原子指令。Python 程序里引用计数操作的密度高得吓人（几乎每行代码都在增减引用），把它们全换成原子指令，单线程直接慢了 ~40%。没人愿意为了多核用两倍的单核代价，项目就这么黄了。

真正破局的是 Sam Gross（Meta 工程师）的 PEP 703。他没有用"无脑原子化"这种蛮力，而是组合了一整套精巧的技术，把去 GIL 的单线程开销从 40% 压到了个位数。这才让 CPython 核心团队点头。

二、自由线程内核解剖：PEP 703 动了哪几把刀

PEP 703 的目标：关掉 GIL 的同时，把单线程开销控制在可接受范围。它靠的不是一招鲜，而是五套组合拳。理解这些，你才能真正判断自己的代码在自由线程下会快还是会慢。

2.1 不可变对象（Immortal Objects，PEP 683）

有些对象生命周期贯穿整个进程：None、True、False、小整数、type 对象、interned 字符串……对它们做引用计数纯属浪费，还会造成"热点争抢"——所有线程都在改 None 的 refcnt，缓存行来回弹跳（false sharing 的极端版），多核越多越慢。

解决方案是把这些对象"永生化"：给 ob_refcnt 设一个特殊哨兵值（高位置 1），INCREF/DECREF 看到这个值就直接跳过，永不修改、永不释放。

// 判断是否为不可变对象（简化）
static inline int _Py_IsImmortal(PyObject *op) {
    return (op->ob_refcnt & _Py_IMMORTAL_FLAG) != 0;
}

在 3.14 的自由线程构建里，官方文档明确：immortalization 目前限定在代码常量（数字/字符串/由常量组成的元组字面量）和 sys.intern() 显式驻留的字符串。这一点很重要——它意味着大量在模块顶层定义的常量不会成为多核瓶颈。

2.2 偏向引用计数（Biased Reference Counting）

这是最核心的一招。观察发现：绝大多数对象的引用计数操作，都来自创建它的那个线程。一个局部变量、一个临时对象，往往从生到死都待在同一个线程里。

于是把引用计数拆成两个字段：

• 本地计数（local refcount）：只有"拥有者线程"能改，用普通非原子操作，快。
• 共享计数（shared refcount）：其他线程要改引用，走这个字段，用原子操作。

只有跨线程访问对象时，才付出原子操作的代价。而现实中跨线程共享的对象是少数，所以整体开销大幅下降。对象真正释放时，把 local 和 shared 合并判断是否归零。

              ┌─────────────────────────────┐
   拥有者线程 │  local_refcount (非原子, 快) │
              ├─────────────────────────────┤
   其他线程   │  shared_refcount (原子, 慢)  │
              └─────────────────────────────┘
   实际存活 = local + shared 综合判断

这套设计来自学术界的 Biased Reference Counting 论文，Sam Gross 把它工程化落进了 CPython。它是"单线程不退化太多"的关键。

2.3 延迟引用计数（Deferred Reference Counting）

有一类对象被解释器高频访问：顶层函数、模块、类对象。它们在解释器主循环里被反复压栈弹栈，如果每次都改引用计数，即使是偏向计数也扛不住热度。

延迟引用计数的思路是：对这类对象，解释器内部的临时引用不立即计入，而是打个标记，等到垃圾回收（GC）扫描时再统一核对真实存活情况。这样把最烫手的那部分计数操作从热路径上彻底挪走。

2.4 逐对象锁 + 内建容器的内部锁

关掉 GIL 后，list.append()、dict[k]=v 这类"会改内部结构"的操作不再有大锁保护。CPython 给可变内建容器加了细粒度的内部锁：每个 dict、list、set 自己带一把轻量锁，修改时锁自己，不影响别的对象。

官方文档的原话值得逐字记住：内建类型用内部锁来防止并发修改导致的解释器崩溃，行为"类似 GIL"——但 Python 从未承诺过对内建类型并发修改的具体语义。换句话说：内部锁保证的是"不崩溃、不损坏内存"，不保证你的业务逻辑是原子的。这个区别我们在第四节会详细展开，是踩坑重灾区。

2.5 QSBR + mimalloc：让无锁读取安全回收内存

为了让读操作尽量不加锁（比如 dict 的并发读），CPython 引入了 QSBR（Quiescent State Based Reclamation，基于静止状态的回收）。核心思想：当一个 dict 扩容、旧的底层数组要释放时，可能还有别的线程正拿着旧指针在读。直接 free 会崩。QSBR 会延迟释放，等到所有线程都经过一个"静止点"（确认没人再引用旧内存）后，才真正回收。

代价是：内存释放会有延迟，峰值内存占用比 GIL 版更高。

同时，pymalloc 分配器被 mimalloc（微软的高性能分配器）替代。mimalloc 天生对多线程友好，还支持 GC 在没有 GIL 的情况下遍历堆、从内部指针定位对象。这是自由线程构建能正常做垃圾回收的底层支撑。

2.6 成绩单：单线程开销从 40% 降到个位数

这套组合拳的效果，官方给了权威数字：在 pyperformance 基准测试套件上，3.14 自由线程构建的单线程开销，从 macOS aarch64 的约 1%，到 x86-64 Linux 的约 8%。

对比一下 Gilectomy 时代的 40%，这是数量级的进步。也正是这个数字，让 PEP 779 敢于宣布"自由线程正式支持"——它不再是玩具，而是可以认真评估上生产的选项。

三、实战：装它、认它、跑它、测它

理论讲完，上手。自由线程是一个独立的构建变体，不是运行时开关，你需要专门的解释器。

3.1 拿到一个自由线程解释器

从源码编译（最能理解本质）：

# 关键是 --disable-gil 这个 configure 选项
./configure --disable-gil --enable-optimizations
make -j$(nproc)
# 产物是带 t 后缀的解释器：python3.14t
./python -VV
# 输出会包含 "free-threading build" 字样

用 uv 一键装（日常最省事）：

# 3.14t 就是自由线程变体
uv python install 3.14t
uv run --python 3.14t python -VV

官方的 macOS / Windows 安装包也提供了自由线程选项的勾选框，Linux 各发行版可以参考社区维护的 py-free-threading 安装指南。

3.2 三种姿势确认 GIL 真的关了

装完别急着高兴，一定要验证 GIL 确实处于关闭状态——因为它可能被某个 C 扩展偷偷重新打开（后面细说）。

import sys
import sysconfig

# 姿势 1：看构建是否支持自由线程（推荐用于构建判断）
supported = sysconfig.get_config_var("Py_GIL_DISABLED")
print("构建支持自由线程:", supported == 1)

# 姿势 2：看运行时 GIL 是否真的被禁用
# 注意：即使是自由线程构建，GIL 也可能在运行时被重新启用
print("GIL 当前已禁用:", not sys._is_gil_enabled())

# 姿势 3：命令行速查
# python3.14t -VV   ->  含 "free-threading build"

运行时还可以用环境变量 / 命令行强制控制 GIL：

# 强制开启 GIL（即使是自由线程构建）
PYTHON_GIL=1 python3.14t app.py
# 或
python3.14t -X gil=1 app.py

# 强制关闭（默认行为，用于抵抗某扩展自动开启 GIL）
PYTHON_GIL=0 python3.14t app.py

3.3 一个能看出差距的 CPU 密集示例

下面这段代码算一批数字的"素数计数"，纯 CPU。分别在 GIL 版和自由线程版上跑，感受差距。

import time
import sys
from concurrent.futures import ThreadPoolExecutor

def count_primes(limit: int) -> int:
    """纯 CPU 计算：统计 [2, limit) 内的素数个数。"""
    count = 0
    for n in range(2, limit):
        is_prime = True
        i = 2
        while i * i <= n:
            if n % i == 0:
                is_prime = False
                break
            i += 1
        if is_prime:
            count += 1
    return count

def run(workers: int, tasks: list[int]) -> float:
    start = time.perf_counter()
    with ThreadPoolExecutor(max_workers=workers) as ex:
        results = list(ex.map(count_primes, tasks))
    elapsed = time.perf_counter() - start
    print(f"workers={workers} 结果={sum(results)} 耗时={elapsed:.2f}s")
    return elapsed

if __name__ == "__main__":
    print("GIL enabled:", sys._is_gil_enabled())
    tasks = [200_000] * 8   # 8 份等量 CPU 工作
    t1 = run(1, tasks)
    t8 = run(8, tasks)
    print(f"加速比: {t1 / t8:.2f}x")

在传统 GIL 构建上，workers=8 基本不会比 workers=1 快，甚至因为线程切换开销略慢，加速比接近 1.0x。

在自由线程构建（python3.14t，8 核机器）上，8 线程能拿到接近 5~7x 的加速比（受内存带宽、缓存和上面提到的单线程开销影响，达不到理论 8x，但已经是质变）。这段代码在两种解释器上一字不用改——这正是自由线程最爽的地方：threading 和 concurrent.futures 的既有代码直接受益。

3.4 一张对照表帮你建立预期

一句话决策：如果你的瓶颈是"多线程跑不满多核的 CPU 计算"，自由线程是为你准备的；如果你是单线程脚本或纯 I/O 服务，先别急着切，收益有限甚至略亏。

四、线程安全的新世界：内部锁 ≠ 你的逻辑是原子的

这是从 GIL 时代迁过来最容易翻车的地方，必须单独拎出来讲。

过去在 GIL 保护下，很多"看起来非原子"的操作其实是原子的，因为字节码之间不会被真正并行打断。大量老代码"碰巧"是线程安全的。自由线程一开，这层隐形保护没了。

4.1 内部锁保证"不崩"，不保证"对"

回顾第 2.4 节：dict/list/set 的内部锁只保证单个操作不损坏内存结构。但组合操作依然会竞态。经典例子：

# 危险：check-then-act 不是原子的
counter = {}

def bump(key):
    if key in counter:          # 线程 A、B 可能同时判断为 False
        counter[key] += 1
    else:
        counter[key] = 1        # 于是都走到这里，丢失更新

在自由线程下，两个线程可能同时通过 if key in counter 检查，最终计数少加。内部锁救不了你——它只保护 counter[key] += 1 这一步不把 dict 结构搞坏，不保护"先查后改"这个逻辑整体。

正确做法是自己上锁：

import threading

counter = {}
lock = threading.Lock()

def bump(key):
    with lock:
        counter[key] = counter.get(key, 0) + 1

官方文档也明确建议：优先使用 threading.Lock 等同步原语，而不是依赖内建类型的内部锁。别把实现细节当契约。

4.2 两个必须记住的"不安全"边界

官方点名的两个已知限制：

1. 迭代器不是线程安全的：多个线程并发访问同一个迭代器对象，可能出现元素重复或丢失。别把一个 generator 丢给多个线程一起 next()。

# 危险：多线程共享同一个迭代器
shared_it = iter(big_list)
# 多个线程各自 next(shared_it) -> 可能重复/漏取
# 正确做法：给每个线程切分独立的数据片，或用队列分发

2. frame.f_locals 跨线程访问会崩：如果某个 frame 正在别的线程里执行，你去读它的 f_locals 可能直接让解释器挂掉。写调试器、profiler、监控探针的同学尤其注意。

4.3 迁移心法

• 别假设"我的老多线程代码碰巧是对的"，用竞态检测思路重新审视所有"读—改—写"和"检查—执行"模式。
• 共享可变状态一律显式加锁，或者改用 queue.Queue、不可变数据 + 消息传递的风格。
• 高并发计数用 threading.Lock 或把聚合下推到每线程本地、最后合并（map-reduce 风格），减少锁争抢。

五、第二条路：子解释器（PEP 734 / PEP 684）

自由线程不是唯一答案。3.14 把多解释器正式搬进标准库，模块名 concurrent.interpreters。它的哲学和自由线程完全相反：不是"共享内存 + 加锁"，而是"隔离内存 + 消息传递"。

5.1 每个解释器一把独立 GIL

PEP 684 让每个子解释器拥有自己独立的 GIL。也就是说，你可以在一个进程里开 N 个子解释器，每个跑在不同线程上，各自持有各自的锁——于是它们能真正并行，而单个解释器内部仍然是熟悉的、有 GIL 保护的世界。

这带来一个很妙的权衡：

• 你不需要重写代码去处理自由线程的竞态；每个子解释器内部还是"老规矩"。
• 你又能吃到多核，因为解释器之间是并行的。
• 代价是隔离：对象默认不能跨解释器共享，通信要走专门通道。

5.2 上手示例

from concurrent import interpreters

# 创建一个全新的子解释器（独立的模块、独立的 GIL）
interp = interpreters.create()

# 在子解释器里执行代码
interp.exec("""
import math
result = sum(math.isqrt(i) for i in range(1_000_000))
print("子解释器算完:", result)
""")

# 3.14 还支持直接 call 一个函数
def heavy(n):
    return sum(i * i for i in range(n))

# 注意：函数与参数需可被跨解释器传递
value = interp.call(heavy, 1_000_000)
print("call 返回:", value)

interp.close()

用队列在解释器之间传数据（生产者-消费者）：

from concurrent import interpreters
import threading

queue = interpreters.create_queue()

def worker():
    interp = interpreters.create()
    interp.prepare_main(q=queue)   # 把队列注入子解释器的 main 模块
    interp.exec("""
while True:
    item = q.get()
    if item is None:
        break
    print("处理:", item * item)
""")
    interp.close()

t = threading.Thread(target=worker)
t.start()

for i in range(5):
    queue.put(i)
queue.put(None)   # 结束信号
t.join()

说明：concurrent.interpreters 是 3.14 新入标准库的模块，API 仍在打磨期，跨解释器只能传递可共享/可复制的数据（如基础类型、bytes、通过队列复制的对象），复杂对象需要序列化。写代码时以官方文档为准。

5.3 三种并发模型横向对比

选型直觉：追求极致共享性能、能驾驭锁 → 自由线程；想要并行又不想重写并发逻辑、能接受隔离 → 子解释器；要强隔离和最简心智、不在乎内存和启动成本 → 老实用多进程。

六、第三条路：尾调用解释器（Tail-call Interpreter）

前两条路都要求你改变并发方式。第三条路不用你动一行代码——它是解释器主循环的底层重写，让普通 Python（哪怕开着 GIL）也快一点。

6.1 从 computed goto 到 musttail

CPython 的字节码解释器本质是个巨大的循环 + switch，逐条分发指令。老实现用 "computed goto"（标签地址跳转）来加速分发。3.14 引入了一种新形态：把每个操作码写成一个独立的小函数，指令之间通过**尾调用（tail call）**互相跳转。

关键在于编译器的 [[clang::musttail]] 属性（配合 preserve_none 调用约定）：它保证这些尾调用被编译成真正的跳转指令，不压新栈帧、不返回，效果等价于 goto，但能让编译器对每个 opcode 函数单独做更好的寄存器分配和优化。这需要 Clang 19+ 之类较新的编译器支持，因此它是可选构建。

传统：一个巨型函数     新式：每个 opcode 一个小函数
┌──────────────┐      ┌────────┐  musttail   ┌────────┐
│ big switch    │  →   │ LOAD   │───────────▶│ ADD    │──▶ ...
│  case LOAD    │      └────────┘             └────────┘
│  case ADD ... │      编译器可对每个函数单独极致优化
└──────────────┘

6.2 别被"15% 提速"忽悠了

这一点必须实话实说。尾调用解释器刚出来时，有报告称能提速 10~15%，社区一度沸腾。后来查明：那个夸张数字很大程度上是因为对比基准（老编译器构建）本身踩了一个 LLVM 的性能 bug，导致基线偏慢，衬得新方案特别快。

修正后的真实收益要保守得多，多数 benchmark 上大约 1%~5%。这仍然是白捡的性能，值得要，但请把预期放平——它不是银弹，只是"编译器技术进步顺手带来的免费小红利"。

6.3 顺带一提：实验性 JIT

3.14 还为 Windows / macOS 提供了实验性 JIT 编译器的二进制发行版（copy-and-patch 技术），默认不开启。它和尾调用解释器是两件事，目前仍在孵化，生产环境别指望，但方向很明确：CPython 正在系统性地补上"运行时性能"这一课。

七、迁移与踩坑清单：C 扩展、生态现状、峰值内存

再好的特性，落地才算数。这一节是给准备真上生产的人的检查清单。

7.1 C 扩展：自由线程的最大拦路虎

这是目前唯一真正卡脖子的地方。带 C 扩展的第三方包（numpy、pandas、pydantic-core、各种数据库驱动……）如果没有显式声明"我支持自由线程"，那么当它被 import 进来时，CPython 会自动重新启用 GIL，并打印一条警告。

也就是说：你可能装了 python3.14t，sys._is_gil_enabled() 却返回 True——因为某个依赖偷偷把 GIL 又打开了。这就是第 3.2 节强调"一定要验证运行时状态"的原因。

C 扩展要支持自由线程，作者需要：

• 用 Py_mod_gil 槽位声明 Py_MOD_GIL_NOT_USED，告诉解释器"我不需要 GIL"。
• 审计自己所有的全局可变状态，改成线程安全。
• 编译出带 t 的 ABI 标签的 wheel（如 cp314t）。

好消息是主流科学计算库进展很快。你可以在这两个社区追踪站实时查看生态兼容进度：

• py-free-threading.github.io/tracking/（重点包支持状态）
• hugovk.github.io/free-threaded-wheels/（PyPI 上自由线程 wheel 的覆盖率）

上生产前的铁律：把你的依赖树在 python3.14t 下跑一遍，逐个确认没有触发 "GIL re-enabled" 警告。

7.2 峰值内存会上涨，做好容量规划

自由线程构建的内存占用天然更高，来源有几处（官方"已知限制"列了很清楚）：

• 所有 interned 字符串都是不可变对象，永不释放。
• 非 GC 对象的对象头更大（要多存偏向计数相关字段）。
• QSBR 会延迟释放内存，静止点到来前旧内存留着。
• mimalloc 的内存归还策略与 pymalloc 不同。
• 偏向/延迟引用计数会让对象存活更久：跨线程引用、延迟计数都可能推迟对象的死亡时刻。

如果你的服务本来内存就紧，切自由线程前务必压测峰值，别在生产上 OOM。

7.3 纯 Python 代码的迁移动作

• 重新审计所有共享可变状态（见第四节），该加锁加锁。
• 不要跨线程共享迭代器 / generator。
• 调试与 profiling 工具注意 frame.f_locals 的跨线程限制。
• CI 里加一条：在 python3.14t 下跑全量测试，并用线程压力测试暴露隐藏竞态。

八、三条路线到底怎么选：一棵决策树

把前面所有内容浓缩成可执行的判断：

你的瓶颈是什么？
│
├─ I/O 密集（网络/磁盘/DB 等待为主）
│   └─ 传统多线程 / asyncio 就够了，别折腾自由线程，收益有限
│
├─ CPU 密集，且需要频繁共享大块数据
│   └─ 自由线程（python3.14t）
│       前提：依赖的 C 扩展都支持自由线程 + 你能驾驭锁
│
├─ CPU 密集，但不想重写并发逻辑 / 想要故障隔离
│   └─ 子解释器（concurrent.interpreters）
│       每个解释器内部还是熟悉的单 GIL 世界
│
├─ 需要最强隔离、最简心智，内存和启动成本不敏感
│   └─ 老实用 multiprocessing
│
└─ 只想让现有单线程程序快一点、又不想改任何代码
    └─ 用尾调用解释器构建 / 关注实验性 JIT（顺手的免费收益）

一个务实的提醒：这三条路不是互斥的。你完全可以在一个大型系统里，用子解释器做粗粒度并行隔离，在每个解释器内部用 asyncio 处理 I/O，同时把最热的数值计算下沉到支持自由线程的 C 扩展里。工具是拿来组合的，不是拿来站队的。

九、性能优化落地建议

如果你决定用自由线程，这几条经验能帮你少走弯路：

1. 先测再切。用你真实的负载在 python3.14t 上跑一遍，别信 benchmark 的一面之词。有些内存带宽受限的负载，多核加速远达不到理论值。

2. 减少跨线程对象共享。偏向引用计数的红利只在"对象大多留在本线程"时成立。频繁跨线程传递对象会让共享计数走原子路径，吞吐反而下降。设计上尽量让每个线程处理独立的数据分片。

3. 警惕伪共享（false sharing）。多个线程频繁写相邻内存（比如共享数组的相邻元素），会导致缓存行来回失效。给每个线程独立的累加器、最后归并，往往比共享一个计数器快得多。

4. 锁要细、要短。持锁时间越短越好；能用无锁的每线程本地聚合就别上全局锁。

5. 关注内存峰值。见第 7.2 节，把峰值内存纳入容量规划。

6. CI 常态化跑自由线程。竞态 bug 是概率性的，只有在持续、高并发的压力测试下才容易暴露。把它变成流水线的一部分，而不是上线后再抓瞎。

十、总结与展望：Python 并发叙事的重写

Python 3.14 不是又一次常规的年度更新。它在并发这条主线上，做了一件三十年没做成的事：把 GIL 从"不可动摇的前提"变成了"可以关掉的选项"。

回顾一下这条脉络：

• 自由线程（PEP 703 → PEP 779 转正）靠不可变对象、偏向引用计数、延迟引用计数、逐对象锁、QSBR + mimalloc 这套组合拳，把去 GIL 的单线程代价从 40% 压到个位数，让"多线程吃满多核"从梦话变成现实。
• 子解释器（PEP 734 / PEP 684）提供了介于线程与进程之间的隔离并行模型，让不想直面竞态的人也能吃到多核。
• 尾调用解释器和实验性 JIT 则代表 CPython 在"运行时性能"上的系统性补课。

当然，路还没走完。C 扩展生态的自由线程化是未来一到两年最大的工程量；峰值内存、单线程微退化这些代价也真实存在。自由线程"转正"不等于"默认开启"，它还会和传统构建长期共存，让社区有时间迁移。

但方向已经不可逆了。作为写了很多年 Python 的人，我的判断是：未来两三年，"Python 到底能不能并行"会从一个哲学争论，变成一个纯粹的工程选型问题——你不再纠结"能不能",而是从三条成熟的路里挑一条最合适的。这本身就是 Python 成熟度的一次大跃迁。

如果你手头有被 GIL 卡住的 CPU 密集任务，现在正是把 python3.14t 拉下来、拿真实负载测一把的好时候。三十年的枷锁，终于有了钥匙——只是记得，开锁之后，线程安全这门功课得自己补上。

本文基于 Python 3.14 官方文档（What's New、Free-threading HOWTO）及 PEP 703 / 779 / 734 / 684 / 683 等公开资料，结合工程实践整理。具体 API 与性能数据请以你所用版本的官方文档和你自己的压测结果为准。