深度解密 Python 虚拟机的执行环境：栈帧对象

楔子

从现在开始，我们将剖析虚拟机运行字节码的原理。前面说了，Python 解释器可以分为两部分：Python 编译器和 Python 虚拟机。

编译器将源代码编译成 PyCodeObject 对象之后，就由虚拟机接手整个工作。虚拟机会从 PyCodeObject 中读取字节码，并在当前的上下文中执行，直到所有的字节码都被执行完毕。

那么问题来了，既然源代码在经过编译之后，字节码指令以及静态信息都存储在 PyCodeObject 当中，那么是不是意味着虚拟机就在 PyCodeObject 对象上进行所有的动作呢？

很明显不是的，因为尽管 PyCodeObject 包含了关键的字节码指令以及静态信息，但有一个东西是没有包含、也不可能包含的，就是程序在运行时的执行环境，这个执行环境在 Python 里面就是栈帧。

栈帧：虚拟机的执行环境

那什么是栈帧呢？我们举个例子。

name = "古明地觉"

def some_func():
    name = "八意永琳"
    print(name)

some_func()
print(name)

上面的代码当中出现了两个 print(name)，它们的字节码指令相同，但执行的效果却显然是不同的，这样的结果正是执行环境的不同所产生的。因为环境的不同，name 的值也不同。

因此同一个符号在不同环境中可能指向不同的类型、不同的值，必须在运行时进行动态捕捉和维护，这些信息不可能在 PyCodeObject 对象中被静态存储。

因此虚拟机并不是在 PyCodeObject 对象上执行操作的，而是在栈帧对象上。虚拟机在执行时，会根据 PyCodeObject 对象动态创建出栈帧对象，然后在栈帧里面执行字节码。所以栈帧是虚拟机执行的上下文，执行时依赖的所有信息都存储在栈帧中。

因此对于上面的代码，我们可以大致描述一下流程：

• 首先基于模块的 PyCodeObject 创建一个栈帧，假设叫 A，所有的字节码都会在栈帧中执行，虚拟机可以从栈帧里面获取变量的值，也可以修改；
• 当发生函数调用的时候，这里是 some_func，那么虚拟机会在栈帧 A 之上，为 some_func 创建一个新的栈帧，假设叫 B，然后在栈帧 B 里面执行函数 some_func 的字节码指令；
• 在栈帧 B 里面也有一个名字为 name 的变量，但由于执行环境、或者说栈帧的不同，name 指向的对象也不同；
• 一旦函数 some_func 的字节码指令全部执行完毕，那么会将当前的栈帧 B 销毁（也可以保留），再回到调用者的栈帧中来。就像是递归一样，每当调用函数时，就会在当前栈帧之上创建一个新的栈帧，一层一层创建，一层一层返回；

虚拟机和操作系统

不难发现，Python 虚拟机执行字节码这个过程，就是在模拟操作系统运行可执行文件。比如：

程序加载

• 操作系统：加载可执行文件到内存，设置程序计数器。
• Python 虚拟机：加载 .pyc 文件中的 PyCodeObject 对象，初始化字节码指令指针。

内存管理

• 操作系统：为进程分配内存空间，管理堆和栈。
• Python 虚拟机：创建和管理 Python 对象，处理内存分配和垃圾回收。

指令执行

• 操作系统：CPU 逐条执行机器指令。
• Python 虚拟机：虚拟机逐条执行字节码指令。

资源管理

• 操作系统：管理文件句柄、网络连接等系统资源。
• Python 虚拟机：管理文件对象、套接字等 Python 级别的资源。

异常处理

• 操作系统：处理硬件中断和软件异常。
• Python 虚拟机：捕获和处理 Python 异常。

我们简单地画一张示意图，来看看在一台普通的 x64 机器上，可执行文件是以什么方式运行的，在这里主要关注栈帧的变化。假设有三个函数，函数 f 调用了函数 g，函数 g 又调用了函数 h。

图片

首先 CPU 有两个关键的寄存器，它们在函数调用和栈帧管理中扮演关键角色。

RSP（Stack Pointer）：栈指针，指向当前栈帧的顶部，或者说最后一个入栈的元素。因此随着元素的入栈和出栈，RSP 会动态变化。由于地址从栈底到栈顶是逐渐减小的，所以 RSP 会随着数据入栈而减小，随着数据出栈而增大。当然不管 RSP 怎么变，它始终指向当前栈的顶部。

RBP（Base Pointer）：基指针，指向当前栈帧的基址，它的作用是提供一个固定的参考点，用于访问当前函数的局部变量和参数。当新的帧被创建时，它的基址会保存上一个帧的基址，并由 RBP 指向。

我们用一段 C 代码来解释一下。

#include <stdio.h>

int add(int a, int b) {
    int c = a + b;
    return c;
}

int main() {
    int a = 11;
    int b = 22;
    int result = add(a, b);
    printf("a + b = %d\n", result);
}

当执行函数 add 时，那么当前帧显然就是函数 add 的栈帧，而调用者的帧（上一级栈帧）显然就是函数 main 的栈帧。

栈是先入后出的数据结构，地址从栈底到栈顶是减小的。对于一个函数而言，所有对局部变量的操作都在自己的栈帧中完成，而调用函数的时候则会为其创建新的栈帧。

当执行函数 main 的时候，RSP 指向 main 栈帧的顶部，RBP 指向 main 栈帧的基址。然后在 main 里面又调用了函数 add，那么毫无疑问，系统会在地址空间中，在 main 的栈帧之上为 add 创建栈帧。然后让 RSP 指向 add 栈帧的顶部，RBP 指向 add 栈帧的基址，而 add 栈帧的基址保存了上一级栈帧（main 栈帧）的基址。

当函数 add 执行结束时，会销毁对应栈帧，再将 RSP 和 RBP 恢复为创建 add 栈帧之前的值，这样程序的执行流程就又回到了函数 main 里面，当然程序的运行空间也回到了函数 main 的栈帧中。

不难发现，通过两个 CPU 寄存器 RSP、RBP，以及栈帧中保存的上一级栈帧的基址，完美地维护了函数之间的调用链，这就是可执行文件在 x64 机器上的运行原理。

那么 Python 里面的栈帧是怎样的呢？

栈帧的底层结构

相较于 x64 机器上看到的那个简简单单的栈帧，Python 的栈帧实际上包含了更多的信息。注：栈帧也是一个对象。

// Include/pytypedefs.h
typedef struct _frame PyFrameObject;

// Include/internal/pycore_frame.h
struct _frame {
    PyObject_HEAD
    PyFrameObject *f_back;     
    struct _PyInterpreterFrame *f_frame; 
    PyObject *f_trace;          
    int f_lineno;               
    char f_trace_lines;         
    char f_trace_opcodes;       
    char f_fast_as_locals;      
};

typedef struct _PyInterpreterFrame {
    PyCodeObject *f_code; 
    struct _PyInterpreterFrame *previous;
    PyObject *f_funcobj; 
    PyObject *f_globals; 
    PyObject *f_builtins; 
    PyObject *f_locals;
    PyFrameObject *frame_obj;
    _Py_CODEUNIT *prev_instr;
    int stacktop;
    uint16_t return_offset;
    char owner;
    PyObject *localsplus[1];
} _PyInterpreterFrame;

栈帧在底层由 PyFrameObject 表示，在 3.11 之前，所有字段都保存在该结构体中。但里面有一部分字段，在大部分情况下都用不到，比如一些用于 Debug 的字段。而这些不常用的字段，显然会导致内存浪费，因为创建栈帧时要为所有字段都申请内存空间。

于是从 3.11 开始，虚拟机将 PyFrameObject 里面的核心字段提取出来，形成了更加轻量级的 _PyInterpreterFrame，从而减少内存使用并提高性能。

• _PyInterpreterFrame：栈帧的核心结构，这是一个轻量级的 C 结构，只包含执行所需的基本信息，虚拟机会在内部使用它。
• PyFrameObject：完整的栈帧对象，在需要更全面的帧信息时使用。比如从 Python 级别获取栈帧时，拿到的对象在底层对应的就是 PyFrameObject 结构体。

通过这种拆分，虚拟机在大多数情况下只需使用轻量级的 _PyInterpreterFrame 即可，只有在需要完整的帧信息时，才会创建 PyFrameObject。

但要强调的是，由于 _PyInterpreterFrame 里面没有 PyObject，所以它不是 Python 对象，它只是包含了栈帧的核心结构，真正的栈帧对象仍是 PyFrameObject。只不过对于虚拟机而言，很多时候只需实例化 _PyInterpreterFrame 结构体，即可完成任务。

另外 _PyInterpreterFrame 除了更轻量、结构更紧凑、创建速度快之外，它对 CPU 缓存也非常友好。

我们知道 Python 对象都是申请在堆上的，栈帧也不例外，当调用嵌套函数时，这些栈帧对象会零散在堆区的不同位置，对缓存不友好。但 _PyInterpreterFrame 则不是这样，虚拟机为它专门引入了一个 Stack，这是一段预分配的内存区域，专门用于存储 _PyInterpreterFrame 实例。

当需要创建 _PyInterpreterFrame 实例时，只需要改动一下栈指针，内存便创建好了。当需要销毁时，直接将它从栈的顶端弹出即可，不需要显式地释放内存。并且由于 _PyInterpreterFrame 都是紧密排列在一起，所以对缓存也更加友好。

字段含义解析与代码演示

下面来看一下这两个结构体里面的字段都表示啥含义，不过在解释字段含义之前，我们需要先知道如何在 Python 中获取栈帧对象。

import inspect

def foo():
    # 返回当前所在的栈帧
    # 这个函数实际上是调用了 sys._getframe(1)
    return inspect.currentframe()

frame = foo()
print(frame) 
"""
<frame at 0x100de0fc0, file '.../main.py', line 6, code foo>
"""
print(type(frame)) 
"""
<class 'frame'>
"""

我们看到栈帧的类型是 <class 'frame'>，正如 PyCodeObject 对象的类型是 <class 'code'> 一样，这两个类没有暴露给我们，所以不可以直接使用。

同理，还有 Python 的函数，类型是 <class 'function'>，模块的类型是 <class 'module'>。这些解释器都没有给我们提供，如果直接使用的话，那么 frame、code、function、module 只是几个没有定义的变量罢了，这些类我们只能通过这种间接的方式获取。

下面我们来看一下 PyFrameObject 里面每个字段的含义。

PyObject_HEAD

对象的头部信息，所以栈帧也是一个对象。

PyFrameObject *f_back

当前栈帧的上一级栈帧，也就是调用者的栈帧。所以 x64 机器是通过 RSP、RBP 两个指针维护函数的调用关系，而 Python 虚拟机则是通过栈帧的 f_back 字段。

import inspect

def foo():
    return inspect.currentframe()

frame = foo()
print(frame)
"""
<frame at 0x100de0fc0, file '.../main.py', line 6, code foo>
"""
# foo 的上一级栈帧，显然对应的是模块的栈帧
print(frame.f_back)
"""
<frame at 0x100adde40, file '.../main.py', line 12, code <module>>
"""
# 相当于模块的上一级栈帧，显然是 None
print(frame.f_back.f_back)
"""
None
"""

所以通过栈帧，你可以轻松地获取完整的函数调用链路，我们一会儿演示。

struct _PyInterpreterFrame *f_frame

指向 struct _PyInterpreterFrame 实例，它包含了栈帧的核心结构。

PyObject *f_trace

追踪函数，用于调试。

int f_lineno

获取该栈帧时的源代码行号。

import inspect

def foo():
    return inspect.currentframe()

frame = foo()
print(frame.f_lineno)  # 4

我们是在第 4 行获取的栈帧，所以打印结果是 4。

char f_trace_lines

是否为每一行代码调用追踪函数，当设置为真（非零值）时，每当虚拟机执行到一个新的代码行时，都会调用追踪函数。这允许调试器在每行代码执行时进行干预，比如设置断点、检查变量等。

char f_trace_opcodes

是否为每个字节码指令调用追踪函数，当设置为真时，虚拟机会在执行每个字节码指令之前调用追踪函数。这提供了更细粒度的控制，允许进行指令级别的调试。

所以不难发现，f_trace_lines 是行级追踪，对应源代码的每一行，通常用于普通的调试，如设置断点、单步执行等，并且开销相对较小。f_trace_opcodes 是指令级追踪，对应每个字节码指令，通常用于更深层次的调试，比如分析具体的字节码执行过程，并且开销较大。

import sys

def trace_lines(frame, event, arg):
    print(f"行号：{frame.f_lineno}，文件名：{frame.f_code.co_filename}")
    return trace_lines

sys.settrace(trace_lines)

设置追踪函数一般需要通过 sys.settrace，不过不常用，了解一下即可。

char f_fast_as_locals

要解释这个字段，需要用到后续的知识，所以这里先简单了解一下即可。Python 函数的局部变量是采用数组存储的，以便快速访问，这就是所谓的 fast locals。

但有时候我们就是需要一个字典，里面包含所有的局部变量，这时候可以调用 locals 函数，将局部变量的名称和值以 key、value 的形式拷贝到字典中。而 f_fast_as_locals 字段则负责标记这个拷贝过程是否发生过。

然后再来看看 _PyInterpreterFrame 结构体里面的字段，我们说栈帧的核心字段都在该结构体中。

PyCodeObject *f_code

栈帧对象是在 PyCodeObject 之上构建的，所以它内部一定有一个字段指向 PyCodeObject。

import inspect

def e():
    f()

def f():
    g()

def g():
    h()

def h():
    frame = inspect.currentframe()  # 获取栈帧
    func_names = []
    # 只要 frame 不为空，就一直循环，并将函数名添加到列表中
    while frame is not None:
        func_names.append(frame.f_code.co_name)
        frame = frame.f_back
    print(f"函数调用链路：{' -> '.join(func_names[:: -1])}")

f()
"""
函数调用链路：<module> -> f -> g -> h
"""

模块 -> f -> g -> h，显然我们获取了整个调用链路，是不是很有趣呢？

struct _PyInterpreterFrame *previous

指向上一个 struct _PyInterpreterFrame，该字段底层没有暴露出来。

PyObject *f_funcobj

指向对应的函数对象，该字段解释器没有暴露出来。

PyObject *f_globals

指向全局名字空间（一个字典），它是全局变量的容身之所。是的，Python 的全局变量是通过字典存储的，调用函数 globals 即可拿到该字典。

# 等价于 name = "古明地觉"
globals()["name"] = "古明地觉"

# 等价于 print(name)
print(globals()["name"])  # 古明地觉

def foo():
    import inspect
    return inspect.currentframe()

frame = foo()
# frame.f_globals 同样会返回全局名字空间
print(frame.f_globals is globals())  # True
# 相当于创建了一个全局变量 age
frame.f_globals["age"] = 18
print(age)  # 18

关于名字空间，我们后面会用专门的篇幅详细说明。

PyObject *f_locals

指向局部名字空间（一个字典），但和全局变量不同，局部变量不存在局部名字空间中，而是静态存储在数组中。该字段先有个印象，后续再详细说。

PyObject *f_builtins

指向内建名字空间（一个字典），显然一些内置的变量都存在里面。

def foo():
    import inspect
    return inspect.currentframe()

frame = foo()
print(frame.f_builtins["list"]("abcd"))
"""
['a', 'b', 'c', 'd']
"""

和我们直接使用 list("abcd") 是等价的。

PyFrameObject *frame_obj

这个不用多说，负责指向 PyFrameObject 对象。

_Py_CODEUNIT *prev_instr

指向上一条已执行完毕的字节码指令，比如虚拟机要执行第 n 条指令，那么 prev_instr 便指向第 n - 1 条指令。由于每个指令都带有一个参数，所以 _Py_CODEUNIT 类型的大小是 2 字节。

int stacktop

表示栈顶相对于 localsplus 数组的偏移量。

uint16_t return_offset

表示 RETURN 指令相对 prev_instr 的偏移量，这个值只对被调用的函数有意义，它指示了函数返回后，调用者应该从哪里继续执行。它会在 CALL 指令（调用函数时）和 SEND 指令（发送数据到协程或生成器时）中设置。

这个设计允许更高效的函数返回处理，因为虚拟机可以直接跳转到正确的位置，而不需要额外的查找或计算。

def main():
    x = some_func()  # CALL 指令在这里
    y = x + 1     # 函数返回后应该执行的下一条指令

def some_func():
    return 42

当调用 some_func 时，虚拟机会执行 CALL 指令，在 CALL 指令中，会设置 return_offset。当执行完 some_func 的 RETURN 指令时，它会使用 return_offset 来决定跳转到调用者（main）中的哪个位置。

这种机制的优点是不需要在运行时计算返回位置，因为它已经在调用时预先计算好了，特别适用于处理生成器和协程等复杂控制流。

char owner

表示帧的所有权信息，用于区分帧是在虚拟机栈上的，还是单独分配的。

PyObject *localsplus[1]

一个柔性数组，负责维护 "局部变量 + cell 变量 + free 变量 + 运行时栈"，大小在运行时确定。

以上就是栈帧内部的字段，这些字段先有个印象，后续在剖析虚拟机的时候还会继续细说。

总之我们看到，PyCodeObject 并不是虚拟机的最终目标，虚拟机最终是在栈帧中执行的。每一个栈帧都会维护一个 PyCodeObject 对象，换句话说，每一个 PyCodeObject 对象都会隶属于一个栈帧。并且从 f_back 可以看出，虚拟机在实际执行时，会产生很多的栈帧对象，而这些对象会被链接起来，形成一条执行环境链表，或者说栈帧链表。

而这正是 x64 机器上栈帧之间关系的模拟，在 x64 机器上，栈帧之间通过 RSP 和 RBP 指针建立了联系，使得新栈帧在结束之后能够顺利地返回到旧栈帧中，而 Python 虚拟机则是利用 f_back 来完成这个动作。

当然，获取栈帧除了通过 inspect 模块之外，在捕获异常时，也可以获取栈帧。

def foo():
    try:
        1 / 0
    except ZeroDivisionError:
        import sys
        # exc_info 返回一个三元组
        # 分别是异常的类型、值、以及 traceback
        exc_type, exc_value, exc_tb = sys.exc_info()
        print(exc_type)  # <class 'ZeroDivisionError'>
        print(exc_value)  # division by zero
        print(exc_tb)  # <traceback object at 0x00000135CEFDF6C0>

        # 调用 exc_tb.tb_frame 即可拿到异常对应的栈帧
        # 另外这个 exc_tb 也可以通过下面这种方式获取
        # except ZeroDivisionError as e; e.__traceback__
        print(exc_tb.tb_frame.f_code.co_name)  # foo
        print(exc_tb.tb_frame.f_back.f_code.co_name)  # <module>
        # 显然 tb_frame 是当前函数 foo 的栈帧
        # 那么 tb_frame.f_back 就是整个模块对应的栈帧
        # 而 tb_frame.f_back.f_back 显然就是 None 了
        print(exc_tb.tb_frame.f_back.f_back)  # None

foo()

关于栈帧内部的字段的含义，我们就说完了。当然如果有些字段现在不是很理解，也没关系，随着不断地学习，你会豁然开朗。

小结

因为很多动态信息无法静态地存储在 PyCodeObject 对象中，所以 PyCodeObject 对象在交给虚拟机之后，虚拟机会在其之上动态地构建出 PyFrameObject 对象，也就是栈帧。

因此虚拟机是在栈帧里面执行的字节码，它包含了虚拟机在执行字节码时依赖的全部信息。