我用多线程给一个 CPU 密集的计算加速,结果非但没快,反而更慢了:Python 的 GIL 给我上的那一课

这事让我对 Python 的多线程,产生了一次彻底的"信仰崩塌"。我有一个计算密集的任务——对一大批数据做复杂的数值计算,单线程跑要好几秒。我寻思:我的机器有 8 个核呢,用多线程并行起来,起码能快好几倍吧?于是我兴冲冲地把任务拆成 8 份,开了 8 个线程并行计算。满心期待地一跑——结果,我整个人都傻了:用了 8 个线程的"并行"版本,不但没有变快,反而比单线程还慢了一点!

这完全违背了我对"多线程 = 并行 = 更快"的认知。8 个核、8 个线程,怎么会比 1 个线程还慢?我一度怀疑是我代码写错了、是线程没真正起来。可反复检查,8 个线程确实都在跑、CPU 监控也显示有活动。直到我深入研究了 Python 的底层,才被一个我"听说过、却从没真正放在心上"的东西,结结实实地教育了一顿——GIL(Global Interpreter Lock,全局解释器锁)。原来,CPython(我们最常用的 Python 解释器)里,有这么一把"全局大锁":在任何时刻,都只允许一个线程,执行 Python 的字节码。这意味着,我那 8 个线程,根本不能真正地"并行"执行计算——它们只能轮流地、一个接一个地抢这把锁、执行一小段、再交出去。我以为的"8 个线程一起算",实际上是"8 个线程排队、轮流算";而轮流切换本身,还有额外的开销——于是,它非但没快,反而因为切换开销,比单线程还慢了。

故障现场:8 个线程,比 1 个还慢

我把出问题的代码,简化一下。你会看到那个"反直觉"的结果:

import threading, time

# 一个 CPU 密集的计算任务(纯计算, 吃 CPU)
def cpu_heavy_task(n):
    total = 0
    for i in range(n):
        total += i * i      # 纯 CPU 计算
    return total

N = 50_000_000

# 版本1: 单线程, 跑 4 次
start = time.time()
for _ in range(4):
    cpu_heavy_task(N)
print(f"单线程: {time.time() - start:.2f} 秒")   # 比如: 4.0 秒

# 版本2: 4 个线程"并行"跑
start = time.time()
threads = [threading.Thread(target=cpu_heavy_task, args=(N,)) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
print(f"4 线程: {time.time() - start:.2f} 秒")    # 比如: 4.3 秒 (居然更慢!)

# 我期望: 4 线程并行 → 快 4 倍 → 1 秒左右
# 实际: 4 线程 4.3 秒, 比单线程 4 秒还慢!
# 原因: GIL 让 4 个线程不能真正并行执行 Python 字节码,
#       只能轮流抢 GIL、一个个执行, 还多了线程切换的开销!

看着 4 个线程比单线程还慢,我才算直观地"体感"到了 GIL 的威力。问题的核心是:CPython 解释器里有一把"全局解释器锁(GIL)"——它规定,在同一时刻,无论你开了多少个线程,都只能有一个线程,真正地在执行 Python 字节码。这意味着,我那 4 个(或 8 个)线程,虽然都"启动"了、看起来在"并行",但它们在执行计算时,必须排队去抢那把唯一的 GIL——抢到的那个线程,执行一小会儿(执行一定数量的字节码或一小段时间),就得释放锁、让其他线程来抢。所以,我那 4 个线程,实际上根本没有真正并行地利用 4 个 CPU 核心去计算——它们是在一个核心上、轮流地、串行地执行的(在 CPU 密集任务上)!我所谓的"并行加速",是一场彻头彻尾的幻觉。更糟的是,这种"轮流抢锁、来回切换"本身,是有额外开销的(线程上下文切换、锁的争抢)——于是,我那个多线程版本,不仅没有得到任何并行的好处(因为 GIL 不让它并行),反而背上了线程切换的额外开销,最终比老老实实的单线程,还慢了一点点。这,就是我那场"越并行越慢"的荒诞结果的根源。

第一件事:搞懂 GIL 是什么、为什么有它

定位到 GIL,我必须搞懂它到底是什么、CPython 为什么要设计这么个"反并行"的东西。查了资料,我把它想透了:GIL,是 CPython 解释器里的一把"全局互斥锁"。它的作用,是确保任何时刻,只有一个线程在执行 Python 字节码。它的存在,主要是为了简化 CPython 的内存管理(尤其是引用计数)的实现,并保证其线程安全。它是一个有历史原因的、有利有弊的设计取舍。

GIL(全局解释器锁)是什么、为什么有它:

GIL: CPython 解释器的一把"全局锁", 保证同一时刻只有一个线程执行 Python 字节码。

为什么 CPython 要有 GIL?
  - CPython 用"引用计数"管理内存(每个对象记录被引用次数, 归零就回收)。
  - 如果多线程同时改一个对象的引用计数, 会有线程安全问题(计数错乱 → 内存 bug)。
  - 最简单的解法: 用一把"全局锁"(GIL), 让同一时刻只有一个线程跑 ——
    这样引用计数就不会被并发修改, 实现简单、单线程性能也好。
  - 代价: 牺牲了"多线程并行执行 Python 代码"的能力。

GIL 的关键影响:
  - CPU 密集任务: 多线程【不能并行加速】(本文的坑)! 因为线程抢不到并行执行的机会。
  - IO 密集任务: 多线程【能加速】! 因为线程在等 IO(网络/磁盘)时, 会【释放 GIL】,
    让其他线程去执行 → IO 等待的时间被"重叠"利用了。

记住一句话:
  - GIL 锁的是"执行 Python 字节码"(CPU 计算)。
  - 线程在做"IO 等待""调用释放了GIL的C扩展"时, 会让出 GIL。
  → 所以: CPU 密集 → 多线程没用; IO 密集 → 多线程有用。

原理终于清晰了。GIL,是 CPython 解释器里的一把"全局互斥锁",它保证同一时刻只有一个线程在执行 Python 字节码。它的存在,有其历史和实现上的原因:CPython 用"引用计数"来管理内存,而如果多个线程同时修改同一个对象的引用计数,会引发线程安全问题;用一把"全局大锁"(GIL),让同一时刻只有一个线程运行,是最简单的、能保证引用计数线程安全的方案——它实现简单、且让单线程的性能很好,代价,则是牺牲了"多线程并行执行 Python 代码"的能力。而 GIL 最关键的影响,在于它对"CPU 密集"和"IO 密集"两类任务,有着截然不同的效果:对 CPU 密集任务(纯计算),多线程不能并行加速(我的坑!)——因为计算时线程一直占着 GIL、其他线程抢不到执行机会。但对 IO 密集任务(网络请求、读写文件),多线程能加速!——因为一个线程在"等待 IO"(等网络包、等磁盘)时,它会主动释放 GIL,让其他线程趁机去执行;这样,多个线程的"IO 等待时间",就被巧妙地"重叠"利用了起来。记住这个关键区分:GIL 锁的是"执行 Python 字节码(CPU 计算)";而线程在"等 IO"或"调用了主动释放 GIL 的 C 扩展"时,会让出 GIL。所以,结论就是那句话——CPU 密集任务,多线程没用(GIL 挡着);IO 密集任务,多线程有用(等 IO 时让出 GIL)。我那个任务,恰恰是纯 CPU 密集的计算,所以多线程对它,毫无帮助、反受其累。

第二件事:正解——CPU 密集用"多进程",IO 密集才用"多线程"

搞懂了根因——"GIL 让多线程无法并行执行 CPU 计算"——正解就清晰了:对 CPU 密集的任务,要用"多进程(multiprocessing)"来实现真正的并行——因为每个进程,有自己独立的 Python 解释器、自己独立的 GIL,所以多个进程,可以真正地、并行地,跑在多个 CPU 核心上;而多线程,则适合 IO 密集的任务。

# 正解1: CPU 密集任务, 用"多进程"实现真正的并行
from multiprocessing import Pool
import time

def cpu_heavy_task(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

if __name__ == "__main__":
    N = 50_000_000
    start = time.time()
    with Pool(4) as pool:                       # 开 4 个进程
        pool.map(cpu_heavy_task, [N, N, N, N])  # 4 个任务, 真正并行!
    print(f"4 进程: {time.time() - start:.2f} 秒")  # 比如: 1.1 秒, 快了约 4 倍!
    # → 每个进程有自己独立的解释器和 GIL, 互不干扰, 真正跑在 4 个核上!

# 为什么多进程能并行? 因为:
#   - 每个进程是独立的, 有自己的 Python 解释器、自己的 GIL
#   - 4 个进程, 就有 4 把 GIL, 互不影响 → 真正利用 4 个 CPU 核并行!
#   - 代价: 进程比线程"重"(内存独立、创建慢)、进程间通信(IPC)有开销

# 正解2: IO 密集任务, 用"多线程"(或 asyncio)就够了
import threading, requests
def download(url):
    requests.get(url)   # 网络 IO, 等待时会释放 GIL!
urls = [...] * 100
# 多线程下载: 一个线程在等网络时, 释放 GIL, 其他线程趁机发请求 → 大大加速!
threads = [threading.Thread(target=download, args=(u,)) for u in urls]
# (IO 密集, 用 asyncio 协程通常更高效、更省资源)

这套正解的核心,是根据任务的类型(CPU 密集 还是 IO 密集),选择正确的并发方式。对 CPU 密集任务,用"多进程":多进程之所以能突破 GIL、实现真正的并行,是因为每个进程,都是一个独立的 Python 程序,有它自己独立的解释器、自己独立的 GIL——4 个进程,就有 4 把互不相干的 GIL,所以它们可以真正地、并行地,跑在 4 个 CPU 核心上,把计算速度提上去(我那个任务,用 4 进程后,从 4 秒降到了 1 秒多,真正快了约 4 倍!)。当然,多进程也有代价:进程比线程"重"(内存独立、创建慢),且进程间通信(IPC)有开销——所以它适合"计算量大、值得为并行付出这点开销"的 CPU 密集场景。对 IO 密集任务,用"多线程"(或更高效的 asyncio 协程)就够了:因为 IO 密集任务的瓶颈在"等待"(等网络、等磁盘),而线程在等待 IO 时会释放 GIL,让多个线程的等待时间重叠起来,从而加速。一句话总结这个正解:CPU 密集(算得多)→ 多进程(绕开 GIL、真并行);IO 密集(等得多)→ 多线程/asyncio(等 IO 时让出 GIL)。选对了并发方式,才能真正地加速。

下面这张图,展示了根据任务类型选择并发方式的逻辑:

这张图的核心判断:先分清任务是 CPU 密集(瓶颈在计算)还是 IO 密集(瓶颈在等待)。CPU 密集用多线程会被 GIL 挡住、没用甚至更慢,要改用多进程才能真正并行;IO 密集用多线程/asyncio,等 IO 时释放 GIL、等待重叠,就能加速。两条路的根本分野,在于你有没有先分清任务类型、再选对并发方式。

第三件事:GIL 相关的几个认知误区

填平了这个坑,我把 GIL 相关的几个容易混淆的认知误区,也一并澄清了一遍:

# GIL 相关的认知误区, 一一澄清:

# 误区1: "有 GIL, 所以 Python 多线程完全没用" —— 错!
#   GIL 只让"CPU 密集"的多线程没用; "IO 密集"的多线程非常有用!
#   (爬虫、网络请求、读写文件 等 IO 任务, 多线程能大幅加速)

# 误区2: "有 GIL, 所以 Python 多线程是线程安全的" —— 错! 危险的误解!
#   GIL 只保证"一条字节码"的执行不被打断, 但你的"一个操作"可能是多条字节码!
counter = 0
def inc():
    global counter
    counter += 1   # 这【不是】原子操作! 它是"读-改-写"3步, 可能被打断 → 数据竞争!
#   → 多线程修改共享数据, 仍然要加锁(Lock), GIL 不保证你的逻辑线程安全!

# 误区3: "多进程一定比多线程好" —— 错!
#   多进程能并行(适合CPU密集), 但更"重"(内存、创建、通信开销大)。
#   IO 密集任务, 多线程/asyncio 比多进程更轻、更高效。

# 误区4: "所有 Python 都有 GIL" —— 不完全对!
#   GIL 是 "CPython"(最常用的实现)的特性。
#   - Jython/IronPython 没有 GIL
#   - 一些 C 扩展(如 NumPy 的计算)会"释放 GIL", 让计算真正并行
#   - Python 3.13+ 开始有"实验性的无 GIL 模式(free-threading)"!

# 误区5: "GIL 是 Python 语言的缺陷" —— 也不全是
#   它是 CPython "实现"的取舍, 换来了简单的内存管理和好的单线程性能。

这一澄清,让我对 GIL 有了更准确、不偏激的认识。误区1(多线程完全没用):大错——GIL 只让 CPU 密集的多线程没用,IO 密集的多线程(爬虫、网络、文件读写)非常有用。误区2(多线程是线程安全的):这是一个危险的误解!GIL 只保证"单条字节码"的执行不被打断,但你的"一个逻辑操作"(比如 counter += 1)往往是多条字节码(读、改、写),完全可能在中间被打断、引发数据竞争——所以,多线程修改共享数据,仍然必须加锁,GIL 绝不保证你的业务逻辑是线程安全的。误区3(多进程一定更好):不对,多进程更"重",IO 密集任务用多线程/asyncio 更轻更高效。误区4(所有 Python 都有 GIL):不完全对——GIL 是 CPython 的特性,有些 C 扩展(如 NumPy)会释放 GIL 让计算并行,而 Python 3.13+ 已经开始有实验性的"无 GIL 模式"了。误区5(GIL 是缺陷):也不全是,它是 CPython 实现的一个取舍,换来了简单的内存管理和优秀的单线程性能。这些澄清共同说明:GIL 不是一个简单的'好'或'坏',而是一个有着复杂影响、且容易被误解的设计——准确地理解它'锁什么、不锁什么、对什么任务有影响',才能用对 Python 的并发,而不是被一堆似是而非的'误区'带偏。

第四件事:Python 并发的"全家桶"——线程、进程、协程怎么选

这次踩坑,逼着我把 Python 的几种并发方式,系统地、对比着学了一遍。我发现,Python 其实给了我们一套"并发全家桶"——多线程、多进程、协程(asyncio),它们各有适用场景,选对了才能真正加速:

Python 并发"全家桶", 三种方式怎么选:

# 1. 多线程 (threading) —— 适合"IO 密集 + 任务数不太多"
#    - 原理: 多个线程, 等 IO 时让出 GIL, 重叠等待时间
#    - 适合: 网络请求、文件读写、数据库操作(IO 密集)
#    - 不适合: CPU 密集(GIL 挡着)
#    - 特点: 共享内存(方便但要小心线程安全), 比进程轻

# 2. 多进程 (multiprocessing) —— 适合"CPU 密集"
#    - 原理: 每个进程独立 GIL, 真正并行跑多核
#    - 适合: 大量计算、数据处理、图像/视频处理(CPU 密集)
#    - 不适合: 海量小任务(进程开销大)
#    - 特点: 内存独立(安全但通信有开销), 比线程重

# 3. 协程 (asyncio) —— 适合"IO 密集 + 海量并发"
#    - 原理: 单线程内, 用事件循环+await, 在 IO 等待时切换任务
#    - 适合: 高并发网络服务、海量网络请求(IO 密集, 几千上万并发)
#    - 不适合: CPU 密集(单线程, 算起来就卡住了)
#    - 特点: 最轻量(一个线程能跑成千上万协程), 但要用 async/await 写

# 选择口诀:
#   CPU 密集 → 多进程
#   IO 密集 + 任务不多 → 多线程
#   IO 密集 + 海量并发 → asyncio 协程
#   (还有: CPU+IO 混合 → 可组合使用, 如进程池里跑异步)

这套"全家桶"的梳理,让我对 Python 并发,有了一个完整、可决策的认识。Python 给了我们三种主要的并发方式,它们不是互相替代,而是各有最适合的"主场":多线程(threading)适合"IO 密集 + 任务数不太多"——靠"等 IO 时让出 GIL"来重叠等待,共享内存方便但要小心线程安全。多进程(multiprocessing)适合"CPU 密集"——靠"每个进程独立 GIL"来真正并行跑多核,是计算密集任务的唯一正解,但进程较重、通信有开销。协程(asyncio)适合"IO 密集 + 海量并发"——在单线程内用事件循环和 await,在 IO 等待时切换任务,最轻量(一个线程能跑成千上万个协程),是高并发网络服务的利器,但要用 async/await 的方式写、且同样不适合 CPU 密集。记住这个选择口诀:CPU 密集 → 多进程;IO 密集 + 任务不多 → 多线程;IO 密集 + 海量并发 → asyncio 协程。我那次的坑,正是因为我对这套'全家桶'毫无概念,稀里糊涂地给一个 CPU 密集任务,选了最不该选的多线程。理解了每种并发方式的'主场',你才能为每个具体任务,选对那个能真正加速它的工具。把这三种并发方式的对比整理成一张表:

第五件事:性能优化,先"对症"再"下药"

这次踩坑,在方法论层面也给了我一个深刻的教训——它让我明白,性能优化,绝不能"凭感觉",而要先"诊断"清楚瓶颈在哪,再"对症下药":

性能优化的正确姿势: 先诊断瓶颈, 再对症下药

# 错误姿势(我犯的): 凭感觉, 想当然
#   "慢? 那就多线程并行一下嘛!" → 没搞清瓶颈是啥, 就乱用药 → 越搞越慢

# 正确姿势:
# 第1步: 先"诊断"—— 这个任务, 瓶颈到底在哪?
#   - 用 profiler(如 cProfile)分析, 时间花在哪了?
#   - 是 CPU 密集(一直在算)? 还是 IO 密集(一直在等)?
#   - 是算法慢? 还是单纯量大?
import cProfile
cProfile.run('my_slow_function()')   # 看清时间都花在哪了

# 第2步: 根据诊断, "对症下药"
#   - CPU 密集 → 优化算法 / 多进程并行 / 用 NumPy 等
#   - IO 密集 → 多线程/asyncio / 减少 IO 次数 / 加缓存
#   - 算法慢 → 换更优的算法/数据结构(往往比并行更有效!)
#   - 数据库慢 → 加索引 / 优化查询(而非盲目并发)

# 第3步: 优化后, "再测量"—— 验证真的快了吗? 别想当然!

核心: 性能优化, 是"科学"不是"玄学"——
  先测量、诊断出真正的瓶颈, 再针对性地优化, 最后再测量验证。
  "不诊断就用药", 是性能优化最常见、也最浪费的错误。

这个方法论层面的反思,是这次踩坑给我的另一份宝贵收获。我这次栽跟头,在方法论上犯的错,是"不诊断,就下药"——我看到任务"慢",就想当然地认为"多线程并行一下就能快",完全没有先去搞清楚"这个任务慢的根源到底是什么、它是 CPU 密集还是 IO 密集"。结果,我给一个'GIL 让多线程毫无用处'的 CPU 密集任务,开错了'多线程'这剂药,自然是越搞越糟。而正确的性能优化姿势,是一个严谨的、像看病一样的"科学"流程:第一步,先"诊断"——用 profiler(如 cProfile)去测量,把时间到底花在哪了、瓶颈到底是 CPU 还是 IO、是算法慢还是数据量大,诊断清楚。第二步,根据诊断,"对症下药"——CPU 密集就优化算法或上多进程,IO 密集就用多线程/asyncio 或减少 IO,算法慢就换更优算法(这往往比并行更有效!)。第三步,优化后"再测量",验证是否真的快了。这个"测量→诊断→对症→再测量"的科学流程,核心是把性能优化,从'凭感觉的玄学',变成'靠数据的科学'。我那次的失败,根子上就是跳过了'诊断'这一步,凭着'多线程能加速'的想当然就乱开药——而'不诊断就用药',恰恰是性能优化里最常见、也最浪费的错误。把"凭感觉优化"和"科学优化"两种姿势对比成一张表:

一张"Python 任务慢了该用哪种并发"的决策图

把这次踩坑沉淀成一张图。每当你想用并发给一个 Python 任务加速时,照着它走:

这张图把性能优化串成了科学流程:先诊断瓶颈→算法慢先优化算法→CPU 密集用多进程→IO 密集任务不多用多线程、海量并发用 asyncio→最后再测量验证。把"先诊断、再对症、后验证"变成性能优化的本能,那个"盲目多线程反而更慢"的坑就再也碰不到你。

我立下的几条 Python 并发规矩

这次"多线程越并行越慢"的事故后,我给自己立了几条规矩:

1. 先分清 CPU 密集还是 IO 密集:用并发前,先搞清楚任务瓶颈是计算(CPU)还是等待(IO),这决定了选哪种并发。
2. CPU 密集用多进程:纯计算任务要并行加速,用 multiprocessing(每个进程独立 GIL),绝不用多线程。
3. IO 密集用多线程/asyncio:网络/文件/数据库等 IO 任务,任务不多用多线程,海量并发用 asyncio。
4. 记住 GIL 锁什么:GIL 锁的是 Python 字节码执行(CPU),IO 等待时会释放——理解这点才能选对并发。
5. 多线程共享数据要加锁:GIL 不保证你的逻辑线程安全,多线程改共享数据仍要加 Lock。
6. 先诊断再优化:性能问题先用 profiler 诊断瓶颈,对症下药,绝不凭感觉乱用并发。
7. 优化后再测量:优化完一定再测量验证真的快了,别想当然。

这几条里,第一条"先分清 CPU 还是 IO 密集"是选对并发的根基。而贯穿所有规矩的那条主线,是对"想当然"的警惕,以及对"理解底层机制"的重视。我这次栽跟头,根子上是两个"想当然"的叠加:一是想当然地以为"多线程一定等于并行加速",而没去了解 Python 的 GIL 这个底层机制;二是想当然地以为"任务慢就该并行",而没去诊断瓶颈到底在哪。这两个'想当然',都源于同一个根源——我对 Python 并发背后的底层机制(GIL、CPU vs IO),理解得不够透,于是只能凭着'多线程=并行=更快'这种来自其它语言、却不适用于 Python 的'通用直觉'去蛮干。而当我真正理解了 GIL 的机制后,'CPU 密集为什么不能用多线程''该用多进程'这些,就都成了由机制自然推导出的、理所当然的结论。这再次印证了那个反复出现的道理:很多'想当然'的坑,根子上都是'对底层机制理解不足';而真正理解了机制,你就能从'凭通用直觉蛮干',升级到'按机制规律精准施策'。

写在最后:别让"通用的直觉",盖过"具体的机制"

这次被 Python GIL 教育的经历,给我一个挺深刻的启示:我们脑子里,常常装着一些'通用的、跨场景的直觉'——这些直觉,在很多情况下是对的、是有用的;可一旦遇到某个'有其特殊机制'的具体场景,这些'通用的直觉',就可能不再适用,甚至完全相反。而如果我们只凭着'通用的直觉'去判断,却忽略了'具体场景的特殊机制',就会在那个机制特殊的地方,栽个大跟头。"多线程 = 并行 = 更快"——这是一个相当'通用'的、在 C++、Java 等很多语言里都成立的直觉;可它,恰恰在 Python(CPython)这个'有 GIL 这个特殊机制'的具体场景里,不成立(对 CPU 密集任务)。我之所以踩坑,正是因为我把那个'通用的直觉',不假思索地套用到了 Python 上,却没去了解 Python 那个会颠覆这个直觉的、特殊的 GIL 机制。

想通这一点,我对'通用直觉'和'具体机制'之间的关系,有了更辩证的认识。'通用的直觉/经验',是宝贵的——它让我们能快速地、在大多数情况下做出正确的判断,不必每次都从头研究。可它也有它的'边界'——它是从'大多数情况'里总结出来的,所以,它在那些'少数的、有特殊机制的'情况里,就可能失效。而一个成熟的判断者,既会善用'通用直觉'带来的高效,又会保持一份警惕:在每一个具体场景里,都多问一句——'这个场景,有没有什么特殊的机制,会让我的通用直觉失效?'他不会盲目地、教条地,把通用直觉套用到一切场景;而会在通用直觉,和具体场景的特殊机制之间,做一个审慎的核对。'尊重通用经验,但更敬畏具体机制'——这是一种避免'经验主义'翻车的、重要的清醒。

所以,如果你也想少踩一些'想当然'的坑,我想把这次踩坑最想说的话送给你:用你脑中那些'通用的直觉和经验'时,请多一份'它在这个具体场景下,还成立吗'的警惕;别让'通用的直觉',盖过了'具体场景的特殊机制'。当你把一个在 A 语言/A 场景里学到的经验,搬到 B 语言/B 场景时,先想一想:B 有没有什么特殊的机制(像 Python 的 GIL),会让这个经验失效?当你凭着一个'惯常的做法'去解决一个新问题时,先核对一下:这个新问题,有没有什么特殊之处,让惯常做法不再适用?因为通用的经验虽好,但它有边界;而很多看似匪夷所思的坑,恰恰就发生在'我们用通用的直觉,去硬套一个有特殊机制的具体场景'的边界之处。尊重通用经验的高效,又敬畏具体机制的特殊——在两者之间保持清醒的核对,正是一个判断者走向成熟、少犯'经验主义错误'的关键。那个让我'越并行越慢'的 GIL,最终教给我的,正是这份对'通用直觉'与'具体机制'之边界的体悟——它让我懂得,再通用、再可靠的经验,也不能不分场景地盲目套用;真正可靠的判断,永远建立在'既借用通用经验、又核对具体机制'的、那份审慎之上。

—— 别看了 · 2026