重构CPython：三大关键设计如何重塑Python的未来

1. 先把“重构 CPython”这件事说清楚CPython 是 Python 的默认解释器也是绝大多数人跑python x.py时真正执行的那套 C 代码。提到“重构 CPython”很多人第一反应是“核心团队才需要关心的事”但你写过 C 扩展、调过解释器参数、或者只是好奇 Python 为什么比 C 慢其实都绕不开这个话题。我最近把 Python 3.13 的源码从解析器到调试器完整溜了一圈一个想法特别强烈与其继续在一个三十年前设计的架构上打补丁不如认真想一想——如果真有重新设计 CPython 的机会有哪三个关键设计会真正改变 Python 的未来。1.1 为什么“重构”这个词让我既兴奋又警惕“重构”不等于“重写”。这个直觉在业务系统里已经反复被验证到了 CPython 身上更加明显。CPython 的源码大概有几十万行 C 代码包含解析器、编译器、字节码解释器、对象系统、内存分配器、垃圾回收器、标准库以及一整套面向第三方库的 C API。这些模块不是独立的它们互相纠缠。举个例子你在 Python 里执行d[key] value时底层会走字典的插入逻辑。这个逻辑里要增加 value 的引用计数引用计数又会触发对象可能被销毁的检查销毁前还要看对象是否在 GC 跟踪链表里而 GC 的链表节点又来自 CPython 自己的内存池。这一条链路上任何一环改动都会像波纹一样扩散到其他模块。所以我心里的“重构 CPython”不是推倒重来而是先做一次结构性的重新梳理把历史包袱识别出来把“必须稳定兼容”的部分和“可以激进优化”的部分切开然后在兼容层之上逐步替换核心实现。这件事不可能在一个版本里完成也不可能靠少数几个人独立完成但它值得被认真讨论。原因是 Python 的应用范围已经扩大到让解释器本身成为瓶颈的程度——从自动化脚本到 AI 训练的前处理、量化交易、数据管道CPU 密集场景越来越多运行时的上限已经开始反过来限制生态的发展。1.2 这次重构的边界在哪里既然是“遐想”我给自己划了三道边界。第一不能破坏 Python 的表达习惯。for x in items、动态类型、对象模型、__dunder__协议这些是 Python 的灵魂。重构的只能是实现路径不能是语言契约。第二不能假设所有 C 扩展一夜之间全部改完。科学计算、图像处理、数据库驱动这些第三方扩展很多直接调用 C API 操作解释器内部结构。重构必须考虑老扩展怎么继续运行而不是逼着生态断臂求生。第三不能以牺牲单线程性能为代价去换多线程能力。这句话看似简单做起来极难因为 CPython 目前很多性能优势恰恰建立在这个“简单模型”上GIL 保证了引用计数的原子性对象头设计紧凑单线程解释执行时没有多余锁竞争。在这三条边界下我从运行模型、编译执行、内存布局三个方向选出了三个我心中“一旦改变就会重塑 Python 未来”的关键设计。它们分别是用所有权模型替换 GIL、把 JIT 变成编译器的一等公民、把对象内存从“散落的指针图”变成“紧凑的数据向量”。后面的部分我会分别拆解并说明每个方案落地时可能踩的坑。2. 设计一用所有权模型替换 GIL让并行真正成为默认2.1 GIL 真正的价值比你想的要复杂这几年“去掉 GIL”成了 Python 社区的高频口号。但如果你仔细看 CPython 的历史就会明白 GIL 并不是一拍脑袋加上去的笨锁。它最核心的价值是让引用计数操作变成原子的。CPython 用引用计数管理对象生命周期每个对象被引用时计数加一引用释放时计数减一。如果没有 GIL两个线程同时增减同一个对象的引用计数计数器就会出错对象可能被提前释放或者内存泄漏。CPython 选择用一把全局锁同时保护解释器核心状态和引用计数本质上是用“单一收银台”换来了“货架安全”。但 GIL 的代价也很明显CPU 密集型任务无法利用多个核心。我在一台 16 核机器上测试过纯 Python 的质数计算启动 16 个线程结果跑了 20 多秒比单线程还慢一点。原因就是线程之间频繁争用 GIL大量时间花在锁切换上。更讽刺的是IO 密集型任务不受太大影响因为线程在等待 IO 时会主动释放 GIL。所以 Python 给人“多线程是摆设”的印象主要就是 CPU 密集型场景的痛。2.2 不能简单删锁得给对象加上“所有权”“别删 GIL要替换 GIL”是我设计一的核心观点。怎么替换我借用了所有权思维。设想给每个 Python 对象增加一个“拥有者线程”的概念。对象只在创建它的线程内被直接访问时走最快的路径读字段不加锁、修改引用计数也不加锁。只有对象需要被其他线程访问时才执行所有权转移或者建立一个临时借用关系。这种思路和 Rust 的所有权模型类似但 CPython 不能引入静态检查必须在运行时动态判断。具体的实现至少需要三步。第一步扩展对象头增加 owner 字段或者一个偏向状态位。第二步把跨线程访问包装成一组 API比如PyObject_Transfer、PyObject_Borrow。第三步给解释器的字节码分发加上快速判断路径如果当前线程就是 owner跳过所有同步逻辑否则走慢速路径需要抢锁或者做原子操作。这里可以大胆设想一种简化结构typedef struct { PyObject_HEAD PyThreadState *owner_thread; PyMutex lock; } PyOwnedObject;当然真实 CPython 的对象头不可能这么简单但方向是明确的单线程执行时owner 判断几乎不花钱多线程争用时只有真正需要共享的对象才付出同步成本。这就把 GIL 的“全局面板锁”改成了“按需的小抽屉锁”。2.3 差异化运行时比一步到位更现实如果真按这个方案重构最大的风险不是设计本身而是生态兼容。现状是成千上万的 C 扩展直接使用Py_INCREF、Py_DECREF它们根本没有 owner 概念。如果新解释器强推所有权模型这些扩展全部会崩。更现实的路径是提供两种运行时模式。一种是带 GIL 的兼容模式继续给老扩展使用另一种是 free-threaded 模式要求扩展显式声明“我是线程安全的”。Python 3.13 其实已经在往这个方向试探了虽然离成熟还远但至少证明了差异化模式可行。在包管理层面可以给每个扩展加一个元数据标记。比如没有标记只能在 GIL 模式下加载标记了thread-safe可以在 free-threaded 模式下加载标记了owner-aware能完整利用所有权模型这样老扩展还能跑新扩展可以渐进迁移。对普通 Python 用户来说未来可能就是一个安装参数或者环境变量的事但这背后的取舍非常深每一次对象共享都要回答“谁拥有、谁借用、谁释放”三个问题这对解释器开发者来说是巨大的心智负担但一旦做成了开发者写的普通 Python 代码不需要任何改动就能用满多核。这一层的价值是战略性的。数据科学里很多 DataFrame 操作被诟病“跑不快”根因之一就是 pandas 这类库必须考虑 GIL 下的内存安全。如果解释器层能安全地并行整个数据生态都能受益。3. 设计二把 JIT 当成编译器的一部分而不是事后优化3.1 解释器到底慢在哪很多人以为 Python 慢是因为“边解释边执行”其实不完全是。CPython 的字节码解释器是一个巨大的switch循环每个字节码一条分支分支里再调用对应的处理函数。这个流程的开销确实不低但更致命的其实是两个细节动态类型检查和间接方法调用。执行a b时解释器必须先取到 a 的类型找到对应的加法槽位再判断 b 能不能转成同类型。这个过程每个操作都要做。C 语言里一个就是一条指令Python 里却可能触发几十条 C 指令。另一个开销来源是缓存不友好。Python 对象分散在堆里对象字段通过指针互相引用CPU 访问时经常跳来跳去缓存命中率远低于 C 语言的局部变量。解决这些问题靠把解释循环写得更精细已经没有太大空间。真正有效的是 JIT运行时根据热点代码生成机器指令把“每次都要做动态检查”变成“只检查一次然后执行便宜的机器码”。3.2 分层设计字节码、微指令、机器码我理想中的 CPython JIT 应该分为三层。第一层还是字节码但字节码的格式要重新设计让每个操作码携带更多类型信息。第二层是微指令层micro ops它把字节码展开成更小的操作原语方便优化器做重排。第三层才是机器码。这个分层的好处是不同层之间可以互相反馈。举个例子total 0 for i in range(10): total i这段代码第一次运行时走解释器同时记录每个操作的运行时类型。当total和i连续多次都是int时JIT 可以生成一段特化代码把循环变成一个简单的加法寄存器循环不再检查类型也不再创建临时对象。这背后要用到一个技术叫“内联缓存”inline cache。CPython 目前在属性访问上已经有一些内联缓存的雏形但覆盖范围还不够。我设想的新设计中每个属性访问、方法调用入口都会维护一个最近几次命中的类型指纹JIT 先生成“假设类型匹配”的快速路径命中就直接执行。这就像开车时导航发现这条路今天特别通畅于是每次都优先走这条路只在走不通时才重新规划。3.3 去优化动态语言的“安全网”提到 JIT大家容易只想到“变快”却忽略了一个更重要的机制去优化deoptimization。Python 是动态语言变量类型任何时候都可能变化。JIT 基于“假设类型不变”生成快速代码就必须随时验证假设。一旦发现假设不成立比如某个变量从int变成了strJIT 就得回到解释器继续执行。这个机制听起来简单实际非常复杂。因为在快速路径里可能已经执行了好几条指令必须把这些状态完整恢复到解释器能理解的样子。否则轻则性能回退重则直接崩溃。我理想中的去优化机制要满足三个条件保证语义可解释总能回到字节码层继续执行保证状态可重建栈、局部变量、异常信息都要保留保证回退成本可接受不能一旦触发就永久放弃 JIT而是记录触发原因后续重新尝试这一层如果做不好JIT 优化得再好也没用。因为真实世界的数据分布变化太多一个“纸面性能很高、碰到类型变动就崩”的解释器没人敢用在生产环境。所以设计二落到最后真正的核心不是“生成代码”而是“如何安全地放弃快速代码”。把这个想通了JIT 才配叫编译器的组成部分而不是挂在解释器旁边的一台跑分机器。我认为未来 CPython 的发布形态会是默认开启某种程度的 JIT但不是每次都编译所有代码而是用复杂度阈值和热点检测来判断。这样做的好处是普通小脚本不会因为启动编译而变慢长时间运行的服务器任务能逐渐进入全速状态。4. 设计三内存布局与 GC 解耦让对象不再“指来指去”4.1 引用计数够用但不够快CPython 当前的内存管理核心是引用计数加周期性 GC。引用计数的最大优点是确定性强当引用数归零对象立刻被析构内存马上可复用。对于临时对象特别多的 Python 脚本而言这个机制保证了内存使用不会无限膨胀。但缺点是对象头太重而且一切都要“指来指去”。每个 Python 对象有一个PyObject头里面至少包含类型指针和引用计数。大多数对象里还有更多字段。访问对象的属性时得到的是一个指针必须解引用两次或三次才能拿到真正的数据。这导致数据在内存里分布得极其碎片化CPU 缓存经常一抓一个空。我在 perf 工具里观察过纯 Python 循环内存访问的 cache miss 往往比指令执行的开销还大。也就是说 Python 慢不只是“解释”更是“没把数据放好”。4.2 把对象内存摊平从单对象分配到批量分块设计三的核心是改变对象的存放方式。与其让每个对象独立申请一块堆内存不如让同一批同类型对象生活在连续的内存区域里也就是常见的“Arena”或“区域分配”。更进一步要把对象的“字段”和“对象本体”分离把真正高频访问的数据放在连续数组里。举一个具体的想法如果你有一个全是二维坐标点的列表当前 CPython 会为每个点分配一个独立对象每个对象内部还有两个实数对象。访问 100 万个点要跳 200 多万次指针。如果改成结构化的连续数组所有点的 x、y 坐标分别放在两个连续数组中访问一个点就只是一次数组下标获取效率完全不一样。这种布局被称为 struct-of-arrays。它对编译器和 CPU 都非常友好但代价是牺牲了 Python 对象模型的统一性。因为在 Python 里point.x和point.y必须是可以动态赋值的属性甚至可以在对象上随便添加新属性。连续数组很难支持任意属性扩展。所以更现实的路径是“混合布局”在新解释器内部对某些内置类型和用户类当确定“这个类的属性集合不再变化”时才切换到紧凑布局。属性访问协议保持不变对外还是一模一样的 Python 对象内部则是高效存储。4.3 GC 变成后台整理器而不是兜底扫大街者如果内存变成了紧凑分块引用计数就不太适合做唯一生命周期机制了。因为一个紧凑数组里可能装着很多对象每个对象都要维护独立引用计数反而增加了内存头部的负担。更好的方案是让 GC 承担更主动的角色用分代追踪为主引用计数作为辅助。听起来像 Java 和 Go 的 GC 思路但 Python 有一个额外的挑战它允许对象定义__del__析构方法还允许弱引用存在。如果 GC 不配合对象销毁顺序会变得诡异甚至出现复活现象。所以我的设计是GC 在后台定期整理内存但保证在用户代码可见的边界上对象析构和弱引用清理仍然遵循原有语义。换句话说用户感知不到 GC 在做什么只感觉到内存的局部性更好了并且多线程访问对象时也不会动不动就撞锁。这个改动对 C 扩展的影响也很大。目前很多 C 扩展直接读取ob_type、ob_refcnt如果对象头部布局改了这些代码就全废。为此必须提供一套新的 ABI 访问宏比如PyObject_GET_OWNER、PyObject_GET_DATA老 API 则被标记为 deprecated。可以想见这个过渡期要比 GIL 移除还长因为内存布局的改动会让所有野指针操作现出原形。5. 从代码层面看这个重构会动到哪些老骨头5.1 先认识一下 CPython 的家底如果你真的想去研究 CPython 重构第一步是读源码但别在读的时候被绕晕。建议以这几个文件/目录为核心Include/cpython/object.h对象头和对象协议Objects/各类内置对象的实现例如dictobject.c、listobject.c、longobject.cPython/ceval.c新版本里则看Python/bytecodes.c字节码解释器核心Python/gc.c垃圾回收器Modules/_threadmodule.c线程模块和 GIL 密切相关这些文件之间高度耦合。想独立理解其中一个往往要把另外三个也大致翻一遍。我刚开始看的时候非常气馁因为每个文件都引用了一堆内部符号。后来我给自己定了一个目标先不看细节只关注“对象是怎样从一个模块传到另一个模块的”。这个视角特别有用因为重构里最怕的就是“这个结构到底归谁管”的问题。5.2 一个小实验用模拟代码验证所有权模型的感觉真实修改 CPython 门槛很高但我们可以做一个迷你模拟来理解所有权模型的复杂性。比如写一个简单的 Python 类模拟对象所有权的转移class SimObject: def __init__(self, value): self.value value self.owner None def transfer(self, new_owner): if self.owner is not None and self.owner ! new_owner: print(ftransfer {self.value} from {self.owner} to {new_owner}) self.owner new_owner这个模拟非常简单但能让你立刻体会到一个核心矛盾所有权转移到底应该在“哪个时机”发生比如对象刚创建时 owner 是谁从列表里取出来时算不算转移多个线程同时读同一个对象是共享借用还是复制一份这些问题如果不提前想清楚真实解释器的并发代码根本写不下去。5.3 重构中最容易被低估的坑我列几个自己的观察也是真正动手时最容易翻车的地方对象头多一个字段可能让所有对象变大。一个字段看似不多但 Python 程序里常常有几十万甚至上百万个对象内存增幅可能直接到 10% 以上。引用计数原子化不等于线程安全。即使引用计数用原子指令实现对象内部的两个字段之间依然可能不一致。去优化时的现场还原最难写。JIT 的开发者常开玩笑写完快速路径只用一周写完去优化要用三个月。GC 和内存池的交互顺序错了会引发幽灵崩溃。改动 GC 优先级时最好先跑一遍内存压力测试。C 扩展的 ABI 一旦变所有需要预编译的包都受影响。所以在设计时就必须要有一个过渡方案。这些坑不是空想都是在真实 Python 演化过程中出现过的。比如 Python 3.8 到 3.10 的 symbol 表改动引发过不少 C 扩展编译失败3.12 重构字节码也带来了调试器的适配风波。所以“重构”字面上听着很酷落到代码上全是细节。6. 我的真实看法重构之后Python 还是 Python 吗说实话思考这三个设计的过程中我最担心的不是技术实现能不能落地而是重构会不会让 Python 变成一个“看起来很相似、其实很陌生”的语言。GIL 去掉以后线程安全模型变了JIT 加入以后性能轮廓变了内存布局改了以后C 扩展生态要经历一次大换血。但反过来想C 语言也经历过类似的过程从一把大锁到细粒度并发从简单编译器到复杂优化器从手工管理内存到更多静态工具辅助。语言还是那门语言只是底层更复杂、能力边界更大了。Python 如果要继续承载未来十年的计算场景CPython 恐怕也得走这条路。我从这个“遐想”里获得的最大收获不是方案本身而是看待问题的方式任何大型系统的重构都不是靠一个天才设计完成的而是靠无数个小步骤、兼容层、灰度策略以及最关键的一点——始终尊重用户已经写下的代码。每次改动之前先回答一个问题“过去十年里依赖这个行为的 Python 程序员他们怎么办”想清楚了这个问题再动手也不迟。如果你也对 CPython 内部感兴趣我建议从读对象系统开始然后自己试着改一点字节码指令哪怕只是在本地打印一些日志。那种“改动一个字段跑起来观察变化”的体验比看十篇源码分析都更有用。重构真正开始的地方是你第一次发现自己能看懂解释器在想什么的时候。