楔子
从现在开始，我们将剖析虚拟机运行字节码的原理。前面说了，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 对象，也就是栈帧。
因此虚拟机是在栈帧里面执行的字节码，它包含了虚拟机在执行字节码时依赖的全部信息。
