題幹與適用場景
面試題：團隊有一個 CPU 密集型 Python 服務，考慮使用 Python 3.14 的 free-threaded 建置來利用多核心。請說明它改變了什麼、如何判斷收益、哪些相依套件會阻止遷移，以及如何設計安全試驗。
本文討論 CPython 的可選 free-threaded 建置，不把它當成所有 Python 發行版的預設行為。Python 文件說明，3.13 起可以使用關閉 GIL 的建置；Python 3.14 已進入官方支援階段，但仍不是預設直譯器建置。核心考察是並行模型、執行緒安全和以證據作效能判斷。
面試官在考察什麼
面試官希望聽到「先測工作負載，再決定是否遷移」，而不是「去掉 GIL 就一定更快」。好的回答會區分 CPU 密集、I/O 密集和混合負載，檢查 C 擴充是否支援 free-threading，並說明一般建置、程序、asyncio 與 free-threaded 執行緒的邊界。
還要能辨識隱含風險：free-threaded 建置可能在匯入不相容擴充後重新啟用 GIL；內建容器目前的內部鎖行為不等於長期語言保證；共用迭代器並行存取可能產生重複或遺漏。Toptal 將 GIL 與工作類型、替代方案和效能思維列為 Python 面試考察點。
回答前需要澄清的問題
先問瓶頸是否真的在 Python 位元組碼。如果請求主要等待資料庫或網路，執行緒或 asyncio 可能已足夠；若是 CPU 密集純 Python，free-threading 才有值得驗證的並行機會。
再問相依套件構成。是否使用 NumPy、Cython、資料庫驅動或其他 C API 擴充？這些擴充若未宣告支援 free-threaded 建置，可能觸發警告並重新啟用 GIL，讓基準結果與預期不同。
最後問成功標準：吞吐量、尾端延遲、CPU 使用率、記憶體、啟動時間還是遷移成本。沒有可比較的基線，就不能把單次 benchmark 當作採用結論。
30 秒回答框架
可以這樣回答：
「我不會把移除 GIL 等同於自動提速。先用生產代表性負載確認 CPU 瓶頸，再建立一般建置、multiprocessing 或 asyncio 的基線。接著在 free-threaded 建置中核對 sys.isgil_enabled()、擴充相容性和執行緒安全，比較吞吐量、尾端延遲、記憶體與回歸錯誤。若相依套件會重新啟用 GIL，或共用狀態需要大幅重寫，就先保留一般建置；只有收益穩定且回滾路徑清楚時才逐步上線。」
分步驟深入解答
先確認執行時真的關閉 GIL
不要只看 Python 版本。官方文件建議檢查 python -VV、sys.version 和 sys.isgilenabled()；也可讀取 sysconfig.getconfigvar("PyGIL_DISABLED") 判斷建置能力。
import sys
import sysconfig
is_free_threaded_build = bool(sysconfig.get_config_var("Py_GIL_DISABLED"))
gil_enabled = sys._is_gil_enabled()
print(is_free_threaded_build, gil_enabled)free-threaded 建置也可以用 PYTHON_GIL 或 -X gil 在執行時重新啟用 GIL，因此基準必須記錄直譯器建置和執行參數。
依工作負載選擇並行模型
CPU 密集純 Python 工作可以從真正的多執行緒並行中受益，但會承擔執行緒安全和記憶體開銷。I/O 密集工作通常先比較 asyncio、執行緒池和程序；移除 GIL 未必值得增加生態相容性成本。混合負載要拆分階段，不能用一個總吞吐量數字掩蓋等待時間。
檢查擴充模組是否會重新啟用 GIL
Python 文件指出，未宣告支援 free-threading 的 C API 擴充在匯入時可能讓 GIL 重新啟用。遷移清單應包括鎖定相依版本、檢查 wheel 標籤、執行匯入測試和記錄警告。只在純 Python 小樣本得到加速，無法證明生產服務可用。
重新檢視共用狀態和容器安全
free-threaded 建置會為 dict、list、set 等內建容器提供內部鎖，但文件明確提醒這屬於目前實作描述，不是歷史上承諾的並行語義。繼續使用 threading.Lock 或其他同步原語保護業務不變量；不要依賴「單次 append 看起來安全」推導複合操作安全。
找出迭代器和回呼的競態
官方文件指出，同一個迭代器被多個執行緒並行存取通常不安全，可能產生重複或遺漏。審查時搜尋共用迭代器、惰性產生器、快取和回呼佇列；改成每執行緒副本、明確佇列或加鎖的所有權模型。
評估擴充模組的 C API 遷移
若團隊維護擴充，需在 free-threaded 建置中宣告模組支援 GIL disabled，並依文件使用 PyGILDISABLED、執行緒狀態 API 和 critical section。擴充不能繼續假設 GIL 會保護全域快取；內部狀態應使用鎖或 thread-local storage。
設計可回滾的基準試驗
固定相同版本程式碼、資料集、執行緒數和硬體，比較一般建置、free-threaded 建置及現有替代方案。記錄吞吐量、p50/p95 延遲、CPU、記憶體、錯誤率和相依警告。測試 CPU 密集、I/O 混合、共用容器和例外重試，並保留設定開關以便回退。
用階段性發布驗證真實收益
先在離線 benchmark 和影子流量中驗證，再讓小比例實例承載真實請求。若 free-threaded 建置帶來單執行緒開銷、記憶體增加或尾端延遲回歸，收益不足以抵消風險就停止擴大。PEP 779 把效能、記憶體、API 穩定性和生態支援列為進入官方支援階段的判斷維度，適合用作評估清單，而不是保證值。
高品質示範回答
「我會把問題拆成執行時、負載和生態三層。執行時先確認是 free-threaded 建置且 GIL 確實關閉；負載用 CPU 密集的生產樣本與一般建置、程序或 asyncio 做基線。接著掃描 C 擴充，因為不相容擴充可能重新啟用 GIL；同時審查共用容器、迭代器、快取和回呼的鎖策略。最後以固定硬體和資料比較吞吐量、尾端延遲、記憶體和錯誤率，先影子流量再小比例發布。只有收益可重複、相依相容、回滾明確，我才採用；否則保留一般建置。」
常見錯誤
把 free-threading 當成無條件提速
錯誤表現：只說「多核心會並行」，沒有說明工作負載和基線。失敗原因：I/O 工作可能不需要它，單執行緒效能也可能有額外開銷。修正方法：先按 CPU、I/O、混合負載分類並量測。
忽略擴充模組
錯誤表現：只執行純 Python benchmark 就宣布遷移成功。失敗原因：未支援的 C 擴充可能重新啟用 GIL 或無法建置。修正方法：鎖定相依、檢查 wheel 和匯入警告，並在真實相依集合中測試。
依賴內建容器的偶然安全
錯誤表現：認為 dict 或 list 的單次操作安全，所以複合讀改寫也安全。失敗原因：業務不變量跨越多個操作，內部鎖不提供交易語義。修正方法：用明確鎖、佇列或所有權模型保護複合狀態。
忽略記憶體和單執行緒成本
錯誤表現：只看吞吐量，不看記憶體、啟動和單執行緒回歸。失敗原因：free-threaded 建置可能需要更多記憶體，額外同步也會有開銷。修正方法：把記憶體、尾端延遲和單執行緒基線列為發布門檻。
沒有回滾路徑
錯誤表現：直接把所有生產實例切換到 free-threaded 建置。失敗原因：相容性和競態問題可能只在真實流量出現。修正方法：保留一般建置映像、設定開關、影子流量和小比例發布。
追問及應對
如果匯入擴充後 GIL 又啟用了怎麼辦？
先把警告和 sys.isgil_enabled() 記錄到啟動診斷，確認是哪一個擴充觸發。若無法升級或替換，就把該相依隔離到程序邊界，或回到一般建置；不要把「直譯器支援 free-threading」誤報成「服務正在並行」。
如果 free-threaded 建置更慢怎麼辦？
確認負載、執行緒數和硬體一致，再分析鎖競爭、記憶體和擴充路徑。官方文件給出的 pyperformance 平均單執行緒開銷在不同平台約為 1% 到 8%，但這不是應用保證。若工作負載沒有獲得並行收益，繼續使用一般建置通常更合理。
如果共用 dict 看起來沒有出錯呢？
把測試從單操作擴展到複合不變量、例外路徑和高並行重複執行，並明確加入鎖。沒有觀察到競態不等於取得語言級保證；執行緒安全應由設計和測試建立。
如果目標是 I/O 密集服務呢？
先比較 asyncio、執行緒池和程序模型的連線開銷、尾端延遲和運維複雜度。free-threading 只有在 CPU 階段成為瓶頸且相依相容時才有明確試驗價值。
如果團隊維護 C 擴充呢？
依 Python C API 指南增加 free-threaded 初始化標記，檢查全域快取、記憶體配置域、執行緒狀態和 critical section；為一般與 free-threaded 建置分別產出 wheel，並用並行壓力測試驗證。