深度解密 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 對象，也就是棧幀。
因此虛擬機是在棧幀里面執行的字節碼，它包含了虛擬機在執行字節碼時依賴的全部信息。
