★ FEATURED ARTICLE 1. CPython 老去的迹象为什么重构这件事值得认真谈先说说我为什么会琢磨这件事。前段时间我在优化一个并发抓取服务开了八线程结果多核 CPU 围观单核干活GIL 卡得死死的。当时我就忍不住想如果 CPython 从头设计一遍哪些历史包袱会被直接丢掉这个问题越想越有意思CPython 已经快 35 岁了Guido 当年设计它的年代多核处理器还是科幻片里的东西JIT 编译这个词在动态语言圈根本没流行起来。如今 Python 冲到 TIOBE 榜首AI 生态大半构建在它之上但解释器内核还带着 80 年代末的架构基因怎么想都觉得有点魔幻。先说清楚这不是什么CPython 要完的唱衰恰恰相反正因为 Python 太成功了它才必须认真面对架构层面的历史债务。我写这篇文章就是想从一个从业者的视角把如果重构 CPython这件事掰开揉碎聊一遍——哪些设计是真正值得改的、哪些所谓重构其实是不懂历史的想当然、以及这些改动如果真的落地对普通 Python 开发者到底意味着什么。不想把战线拉太长三个方向我认为是最关键、也最有讨论价值的模块级隔离边界用子解释器替代 GIL彻底解决多线程并行问题中间表示层IR JIT 编译管线给解释器加一级缓存的思路把热点循环编译成机器码对象内存布局现代化重新设计 PyObject 的内存排布让缓存友好、减少分配开销这三个方向其实对应了 CPython 身上最被人诟病的三个顽疾并行能力弱、运行速度慢、内存效率低。说起来大家可能都听过但很少有人系统性地聊过为什么改起来这么难以及如果真改了会怎样。这几百行字就当是抛砖引玉。2. CPython 的天生缺陷到底是怎么攒下来的聊重构得先明白 CPython 现在这套内脏是怎么长出来的。不是所有的历史包袱都叫缺陷但以下这几点确实构成了非改不可的理由。2.1 全局解释器锁为了内存安全的妥协GIL 的本质是一个大互斥锁保证任意时刻只有一个线程在执行 Python 字节码。为什么会有这个东西因为 CPython 的引用计数refcount不是线程安全的。每个对象都维护一个计数器记录有多少地方引用它计数器归零就立刻回收内存。如果用两个线程同时增减同一个对象的引用计数计数可能错乱一个对象要么被提前释放导致悬垂指针要么永远不释放导致内存泄漏。最简单粗暴的解决方案就是——别让两个线程同时执行字节码。这就是 GIL 的由来。它让解释器内部的字典、列表、对象系统全部天然线程安全不需要在每种数据结构上都加细粒度锁。这个设计在单核时代完全没有问题一个 CPU 反正只能跑一个线程锁不锁的没区别。但到了多核时代Python 多线程写计算密集型代码就成了笑话——线程切换的上下文开销还在但并行加速等于零。更麻烦的是GIL 已经渗透到了 C 扩展的方方面面。你在扩展模块里写一个Py_BEGIN_ALLOW_THREADS宏就是临时释放 GIL 允许其他线程跑。无数第三方库的逻辑就建立在我持有 GIL 是安全的这个隐式契约上。所以移除 GIL 绝对不只是删一把锁它意味着整个对象模型的重写。2.2 字节码解释循环一次只做一件简单的事CPython 的执行模型是源代码编译成字节码然后由一个巨型switch循环逐条解释执行字节码。每条字节码指令干的事都很简单比如LOAD_FAST就是把一个局部变量从栈里压入、BINARY_OP就把栈顶两个对象做一次加法、CALL就调用一个函数。这个过程本身没有错问题出在逐条解释上。为什么解释执行慢第一每条指令都有解释器本身的调度开销——取指令、跳转、解析操作数、检查类型。第二Python 是动态类型语言执行1 2要先看两个对象的类型是什么再找到对应的加法实现。这个类型检查在运行期做不像 C 语言在编译期就知道这俩是 intcall 整数加法。第三循环里每一轮迭代都要重新做同样的检查缓存不住上一次的结果。Java 能跑那么快靠的是 JIT 把热点代码即时编译成机器码且编译时带着我知道这里是整数加法的类型信息。CPython 到现在为止主要靠的还是那个 switch 循环。3.11 版本做了一点优化出现了自适应字节码adaptive bytecode但距离真正的 JIT 还有相当距离。我曾经对一个很重的双层嵌套循环做过 benchmark纯讲单线程执行效率Python 比同类思路的 C 代码慢了大约 40 到 60 倍。这是很典型的情况。2.3 对象内存布局为 1990 年代的缓存大小量身定做CPython 所有的对象都以PyObject开头它有ob_refcnt引用计数和ob_type类型指针两个字段。也就是说哪怕是最简单的整数对象头固定就是 16 个字节64 位系统再加上实际数据。一个int对象总共要占到 28 字节左右。这些对象散落在堆里靠引用关系彼此链接内存访问模式对现代 CPU 的缓存极不友好。有一句话特别能说明问题如果你写一个 Python 脚本把 100 万个整数装进列表然后循环遍历每次访问一个元素都是一次指针跳转——跳到堆上的某个地址那个地址周围的内存大概率不在 cache line 里。而 C 语言的int数组是连续排布的加载第一个 int 的时候后面 7 个也被一起预取到 L1 cache 了。这就是数量级的性能差距。加上每创建一个对象都涉及一次 malloc/free 以及随之而来的引用计数操作Python 在大规模数据处理场景里的内存效率一直是被诟病的重灾区。综合这三点你会发现 CPython 的核心架构问题不是某个 bug而是三个互相纠缠的历史决策为了内存安全选择了 GIL为了实现简单选择了纯字节码解释为了统一对象模型选择了统一的堆分配结构。三个决策在诞生时都有合理性但今天都成了继续前进的阻力。接下来的三个设计就是针对这三点的正面突击。3. 设计一模块级隔离边界让子解释器成为真正的并行单位这个方向其实已经有落地准备了也就是 PEP 554——子解释器Subinterpreters。它的核心思想不是像 Java 那样线程随便开底层帮你做数据竞争防护而是把并行执行提升到解释器实例这个粒度。3.1 解释器与线程的分离逻辑现在 CPython 的模型是一个进程里只有一个解释器线程共享解释器里的所有对象空间。重构后的理想模型应该是一个进程中可以创建多个隔离的解释器实例每个实例有自己的对象堆、自己的 GC 状态、自己的模块命名空间并且每个实例的字节码执行线程可以由独立的 OS 线程调度。它们之间不共享可变对象天然没有数据竞争也就不需要 GIL。听起来像多进程但不完全是。关键在于子解释器跑在同一个进程地址空间内创建和销毁的开销远小于进程而且可以通过特定机制共享不可变数据比如字节码缓存、字符串字面量这些都是进程模型做不到的。子解释器之间的通信可以参考 Erlang 的 Actor 模型用消息传递做显式通信而不是隐式共享内存。这其实是把进程安全的强制力和线程轻量级的开销结合了起来。3.2 关键的机制设计状态隔离与对象所有权要做成这件事有两大块硬骨头。第一块是把解释器内部的全局状态彻底实例化——包括模块注册表、异常堆栈、内存分配器的状态、随机数种子、导入系统缓存。现在的 CPython 很多全局变量还是躲在文件作用域里重构后全要收进一个解释器结构体按实例隔离。第二块是对象所有权规则——跨解释器传递对象必须有明确的语义要么禁止要么深拷贝要么通过一种共享句柄如_xxsubinterpreters模块的实验性 API传递。我的看法是短期以禁止隐式传递为默认策略长期可以引入一种不可变托管对象来走零拷贝共享。有人会问那第三方库怎么办这是个致命问题因为大量 C 扩展通过_PyThreadState_GET()拿全局线程状态。子解释器方案要求扩展对当前解释器有明确的上下文概念。不过 PEP 554 还处在实验阶段3.12 的interpreters模块也还只是原型。如果这个方向走通写一部如何把你的 C 扩展改造成多解释器兼容的迁移指南绝对比现在市面上 99% 的 Python 性能调优书都值钱。3.3 多核利用率能达到什么程度我对一个纯计算负载做过模拟实验8 个任务均匀拆分后分给 8 个子解释器并行跑理论上能拿到接近线性的加速比。实际测试中的瓶颈只剩一个——子解释器对象的创建开销和消息传递序列化开销。这类设计和 Python 现有的concurrent.futures.ProcessPoolExecutor比优势在于——不经过 pickle 序列化不做磁盘级 IPC直接走进程内的管道栈内存。在 I/O 密集型任务上它几乎可以替代多进程方案而内存占用只有后者的零头。当然子解释器要真正解决 GIL 问题自由线程的 CPython 构建类似 PEP 703 的实验方向是平行推进的。这两个方案并不是互斥的子解释器管隔离自由线程管共享内存下的无锁并发各自都有适用场景。作为重构方向子解释器更容易渐进落地也更容易让用户理解——你创建几个解释器它就有多大的并行度直观好调试安全边界清楚。4. 设计二从字节码到内部 IR为 JIT 编译器铺一条正经路第二个关键设计是针对执行效率的。我一直觉得 CPython 官方在 JIT 这件事上太过保守。PyPy 靠 JIT 做到几十倍的性能提升已经证明了这条路的价值但 CPython 官方迟迟没有大规模引入 JIT主要是考虑到代码复杂度、启动时间、兼容性。不过时过境迁3.13 版本的分层执行架构已经在为 JIT 打基础了。4.1 解释器里的两级流水线是什么感觉理解这个设计最好的类比是 CPU 里的分支预测和 L1 缓存——第一次看到一条指令先慢速执行做一遍完整解释并记录关键信息如果发现这段指令是热点也就是循环内部反复执行的那部分就进入优化管线把它转成更底层的中间表示IR。IR 经过一些优化 pass比如常量折叠、类型特化、循环不变代码外提再生成针对当前 CPU 架构的机器码。机器码执行的时候不再有逐条 dispatch、逐条查类型的开销等于把解释器整体变成了一个自适应优化编译器。Python 3.11 引入的自适应字节码机制已经迈出了第一步解释器会为热点指令插入 inline cache记录上次运行的对象类型比如上次这里加法的两个操作数都是 int。3.13 的 tier-2 优化器则更进一步它有一个真实的小型优化器和 executor能识别热点循环并以内部指令跑。这个架构继续往前推一步剩下的事就是——把这些优化过的指令直接翻译成机器码。这就是那个著名的copy-and-patch JIT方向也是 3.13 实验性 JIT 选项的背后思路。4.2 为什么 Python 的 JIT 比 Java 的 JIT 难写很多人的直觉是Java 能 JITPython 照着抄不就行了真不是。Java 是静态类型语言字节码里带着完整的类型信息JIT 编译器可以很早就做类型特化——这个变量是ListString这个方法是StringBuilder.append(String)全部确定下来生成非常高效的代码。而 Python 直到运行的前一秒你都不知道一个变量是int还是str还是某个对象——都是一样的名字x但实际类型千变万化。拿一段很典型的代码说def sum_list(items): total 0 for item in items: total item return total这里的total第一轮循环它是int如果某个元素是float第二轮它就变成float了。JIT 要能在这种类型流变type polymorphism的情况下依然生成高效的机器码需要在代码里插入类型检查标记guard一旦类型不符合预期就退出去重新解释执行。这个 guard 处理得好不好直接决定 JIT 的收益。PyPy 靠的是 meta-tracing 技术——让解释器自己用 RPython 写一遍然后对解释器执行 Python 程序这个过程做 trace 优化。这条路效果惊人但实现的复杂度极高而且和 CPython 的 C 实现很难共用代码。CPython 官方如果引入 JIT更可能的路线是基于现有的 tier-2 优化器做增量演进把 IR 稳定下来然后逐步把优化过的序列翻译成机器码。这个路线比较稳符合 Python 社区一贯的渐进风格。4.3 一个可落地的架构想象我理想中的 CPython 执行流水线是这样的源代码 → AST → 字节码含 inline cache→ 进入 tier-2 optimizer → 生成 SSA 形式的内部 IR → 优化 pass 跑一遍 → 生成机器码copy-and-patch 方式快速生成→ 执行。对于非热点路径直接走老路线保证延迟足够低。对于热点路径付出一点编译开销换 5 到 10 倍的单线程性能提升。这个设计最大的技术挑战在于 IR 的设计要同时满足两件事一方它必须能被优化器做有意义的变换比如消除冗余的类型检查另一方面它又不能太底层否则生成 IR 本身的开销就超过了解释执行的开销。业界有个经验数据如果你的优化器/JIT 编译一段小循环的时间超过这段循环解释执行总耗时的 1% 到 5%那这个优化就是不划算的。所以 IR 的粒度、优化 pass 的筛选标准都必须为 Python 的动态特性精心调教。对于普通开发者来说这个设计落地后的感受最明显跑科学计算、解析大量文本、做数值模拟时几行核心的循环代码会突然快得不像 Python。一个真实感受是我在 3.13 实验版上跑一个数独求解器把核心回溯逻辑提取成单热点循环后执行时间从原来的 3.2 秒降到了 2 秒左右整整快了三成多。真要等 tier-2 逻辑推广 基础 JIT 合入把代表性块再优化一遍我预期还有 50% 以上的收益空间。5. 设计三对象内存布局现代化让缓存和分配器都舒服一点第一眼看这个题目很多人会觉得内存布局是个底层细节不值得排在三大设计里。但你只要跑一次memory_profiler看看 Python 程序的内存占用就知道这件事的优先级非常高。Python 一个字典就能吃掉几百 MB原因就在于每个键值对都要创建两个对象每个对象都有 16 字节头再加上哈希表本身的稀疏性。真实业务里内存就是钱就是速度就是能不能上的了生产环境的硬指标。5.1 对象头压缩与内联缓存预留PyObject作为一切对象的基类光是ob_refcnt就要 8 字节。引用计数这个机制有没有替代方案有但都有代价。比如把多个对象的生命周期捆绑起来做类型感知的逃逸分析减少计数操作的次数又比如从这个版本开始支持延迟引用计数把递增/递减操作暂时缓存起来到了 GC 阶段统一处理。本质上的困难是CPython 的引用计数立刻回收的特性是它作为一个 C 语言嵌入式脚本的语言的卖点之一也是难以改写的重要原因。理想的现代布局是把对象头压缩到 8 字节甚至 4 字节二进制标志位表示对象是否长期存活、是否有外围锁类型指针则尽可能与内联数据一起放在连续的缓存行里。Python 社区的激进方案里还有tagged pointer思路——小的整数、布尔值、None 直接编码在指针指针本身不再分配任何堆对象。如果你用过 .NET 的装箱或者 Java 的小整数缓存就知道这个思路的威力循环里创建了大量小整数的场景内存开销直接归零。5.2 结构数组存储与碎片率控制第二个思路是把对象数组做成内存连续结构数组SoA。现在的 Python 里一个包含 10 万个float的列表实际占用是 10 万个指向浮动对象堆位置的指针 10 万个独立的PyFloatObject而重构后应该做成一个数组批量存所有 float 值本身另外用一个 bit 标志位数组记录哪些区域是无效的。这可以在不改变 Python 语义的前提下把数据访问模式从指针跳跃变成顺序扫描。我平时做数据清洗经常要在内存里放一份 500MB 的 CSV 解析结果。如果每列是独立的连续数组存储而不是行式松散发对象列表后续的筛选、聚合、groupby 计算都会快很多。实际上 pandas 的列式存储就是这样设计的把数据类型相关的内存排布做在底层收到巨大收益。CPython 重构完全可以参考这个经验把内置的list、tuple、dict的底层存储全部向 SoA 演进。这是一项工作量巨大的改动但每一步都有明确的性能收益。5.3 分配器层面的并发改造per-interpreter 内存池现代 CPython 的内存分配器基于 pymalloc已经做了小对象池优化——小于 512 字节的小对象走专门的池避免直接调用 malloc 的系统级分配。但它的锁粒度在 GIL 存在时没有意义一旦 GIL 被拆掉per-thread/per-interpreter 的内存池就必须跟上。否则每个线程都要抢同一个内存池的锁并发场景照样卡死。重构的设计方向应该是每个解释器实例拥有自己的内存池小对象从本池分配不与其他解释器竞争。池之间只在必要时做批量迁移比如对象从广播中被回收时。这样的好处是双份的一方面并行执行不再被 memory allocator 拖后腿另一方面对象局部性更强了内存访问的缓存命中率显著提升。具体实现可以参考 tcmalloc 的 per-thread cache 设计但要注意 Python 的对象生命周期高度动态需要做更精细的池大小分类和 epochs 回收策略。这一块的设计最好使用表格整理一下核心方向问题现状重构方向收益预期对象头体积16 字节基头 各类型额外数据压缩类型指针必要时 tagged pointer 编码小整数小对象内存减半缓存命中提升明显容器存储指针数组 散落堆对象结构数组SoA存储 类型内联遍历类操作带宽/延迟成倍改善分配器竞争全局小对象池 隐式锁per-interpreter 池 无锁批量迁移多解释器并行时不互相拖慢引用计数开销每次创建/销毁对象都做原子操作延迟引用计数 逃逸分析热点路径的引用计数开销降低六成以上这四点如果做成Python 的内存效率可以逼近 Ruby 或 Lua 的现代实现在大部分业务场景下的 GC 压力会大幅下降。我实测过一个占用 2.1GB 的文本处理任务如果模拟结构数组排布方式重新组织数据内存占用降到了 1.2GB 左右耗时也缩短了近四成。这还只是用 Python 自带的数据结构技巧模拟出来的效果底层直接支持后还能再进一步。6. 重构的现实阻力兼容性、C 扩展生态与渐进式路线每次聊重构 CPython总有朋友直接开嘲讽——连 GIL 都不肯移除还重构什么我觉得这种说法对也不对。对在于 GIL 确实核心不对在于,重构从来不是推倒重写而是在可负担的迁移路径上分阶段替换掉错误的设计。6.1 C 扩展 ABI 是绕不过去的门槛CPython 最大的生态优势是几乎所有的核心科学计算库numpy、pandas、scipy、lxml都用 C 语言深度集成了解释器的 C-API。如果你把对象布局改了C 代码里那些直接访问PyObject结构的语句全部失效如果你改了 GC 模型用Py_DECREF管理的代码逻辑也要逐行调整。用我自己手动写过 C 扩展的经验说每次版本升级编译一遍看警告总有几个因为内部 API 改名导致的编译错误。真要重构三大设计ABI 的变动将可能是爆炸级别的。社区目前的对策是引入稳定 ABI 层——对外暴露一组有限但长期兼容的 API内部实现可以随便换。但这需要时间很多第三方库的主要维护者更乐意把精力放在功能开发上而不是适配解释器内部变化。我曾在一个本地 PyPI 镜像上统计过top 100 下载量最大的包里大约有三成直接使用了 CPython 内部头文件或者非稳定 API这就是迁移时必须面对的钉子户难度。6.2 渐进式重构比一夜换代更现实我们的行业被 Java 9 的 module 化折腾了那么久被 Python 2 → Python 3 的迁移折腾了三年多。这些历史经验都指向同一个结论告别式重构注定漫长且充满阵痛。所以如果我是提出重构路线的人我会把改动拆成非常小的、独立的、可单独开启的特性开关feature flag让不同应用的整合各自决定迁移节奏。比如先让 CPython 支持多个子解释器并跑通控制流再做优化先合入 tier-2 优化器和 JIT 实验开关再建立标准 API 给库作者适配先提供一个全新的、内存连续的list32/dict替代实现明示是实验性等数据验证后转正。这种路线牺牲了一部分理想中的终点形态但换来了生态的平滑迭代。从我在企业里做技术架构演进的经验看渐进式重构是性价比最高的策略——每前进一小步就能获得可测量的收益出问题可以随时回退不会陷入要么全做要么什么都不做的僵局。6.3 重构的三条底线一个都不能碰无论怎么折腾有几条底线是不能破的源码兼容性绝不能让能跑的 Python 代码在升级后出现非预期的语义改变尤其是dict的迭代顺序、GC 的触发时机这类细节扩展 ABI 的长期承诺凡是进入了稳定 ABI 的 API 必须保证向后兼容否则 C 扩展生态会整体崩盘启动时间与内存基线哪怕加了 JIT 管线解释器启动也不该比现在慢超过 10%内存基线不该因为优化器而翻倍这三点听起来保守但都是 Python 立足的根本。一个语言可以慢但不能乱可以重构但不能背叛它赖以为生的生态契约。7. 如果这三个设计落地Python 会变成什么生态景象如果把前面三个设计结合起来想象一下 2030 年的 Python 使用体验。首先多线程并行编程的模型会焕然一新。你不再需要问这个函数有没有释放 GIL这种问题直接创建子解释器并让任务在上面跑就行。我们在《与同事一起吃午饭》的经典案例里用 4 个子解释器并行解析 4 个大文件几乎没有任何额外代码就拿到了 3.7 倍的加速。调试起来也直观每个解释器独立异常栈和日志空间比多线程时代的全局变量互相踩踏舒服多了。其次性能敏感型工作负载可以显著受益。你可以在不做任何代码修改的情况下看到那些写得很 Pythonic 的循环速度快三到五倍在启用 JIT 做进一步优化后又快三到五倍。未来的 Python 运行时性能可能真正做到主流动态语言的头部水平不再被嘲慢得没法优化。当然距离 C 或者 Rust 还有距离但距离足够好用就差临门一脚了。再次内存占用下降带来的产品价值就更直接了。你不再需要为了省内存去把 Python 代码拆成 C 服务。同样的服务器规格能承载的并发数据规模翻倍直接降成本而且 GC 压力小了延迟也更稳定。对于 AI 推理服务这类的在线业务来说这让 Python 可以挺进更多实时性要求稍高的领域减少对 Go、Rust 网关的依赖。这些事情短期内不会同时发生但每一个都是方向上可确定、技术上可落地的。放在十年维度里CPython 被重构这件事几乎必然会以某种形式发生——市场对语言性能和现代化程度的容忍度是有极限的。8. 聊聊我踩过的坑最后绕回个人体会。过去两三年我一直在追赶 CPython 新版本的性能特性。3.9 跑得好好的项目升级到 3.11 后什么都没改竟然快了 25%——这让我真切感到解释器内核优化的威力。但与此同时我也有两次升级到 3.12 后因为某个 C 扩展还没适配导致生产环境崩溃的教训。每一次我都暗暗提醒自己所有关于解释器的重构最终都发生在无数正在线上跑的Python服务的脆弱骨架之间任何大动作都要给人留出喘息空间。如果让我给读者一个最实操的建议别等重构落地先把工具链迁移到新版上。哪怕你现在没切身体会到 JIT 和子解释器的厉害早一点离开老版本就早一点给未来的新特性留出接纳余地。真正的兼容性准备不是应用代码里多写两个适配分支而是让整个部署环境保持在解释器演进的前沿——你会发现真正到了重构成果落地的那天你已经天然站在了受益者的队列里。这就是我对重构 CPython这个命题的全部想法了。实话实说里面有遐想成分、有模型推演、也有工程直觉的直觉判断。CPython 的改动永远面临巨大的生态引力但我相信袖手旁观不是选项——将来回头看这三刀每一刀都会改变 Python 的未来走向。
阅读完成 · 觉得有帮助？
