Python 多進程優於多線程的核心原因：深度解析 GIL 機制

為何 Python 多線程難發揮多核效能？

在 Python 開發圈流傳著一句經典建議：「Python 多線程是雞肋，推薦使用多進程」。許多開發者知其然，卻不知其所以然。本文將從底層機制出發，深入剖析全局解釋器鎖（GIL）如何限制多線程效能，並說明為何多進程能真正實現並行運算。

GIL 是什麼？歷史包袱還是設計權衡？

GIL（Global Interpreter Lock，全局解釋器鎖）是 CPython 解釋器為了保護內部數據結構（如引用計數）的執行緒安全而引入的互斥鎖。在 Python 設計之初，為了簡化記憶體管理並方便整合非執行緒安全的 C 擴展庫，開發團隊做出了這項妥協：同一時間僅允許一條線程持有 GIL 並執行 Python 位元組碼。

線程執行流程與 GIL 爭搶機制

在單一 Python 進程中，GIL 猶如唯一的「通行證」。線程執行週期如下：

1. 獲取 GIL
2. 執行代碼，直到遇到 I/O 操作、時間片用盡（Python 2 為 ticks 計數達 100，Python 3 改為計時器閾值）或主動釋放
3. 釋放 GIL，其他線程競爭獲取

這意味著多核 CPU 上，Python 多線程始終無法實現真正並行，只能在單核上透過快速切換實現併發。頻繁的鎖獲取、釋放與上下文切換反而帶來額外開銷。

多核環境下的「線程顛簸」現象

在多核架構下，情況更糟：CPU 0 釋放 GIL 後，所有核心上的線程同時競爭，但 GIL 往往又被 CPU 0 瞬間搶回。被喚醒的其他核心線程發現拿不到鎖，只能進入等待狀態，造成嚴重的線程顛簸，效率反而低於單核。

CPU 密集型 vs I/O 密集型：多線程的適用邊界

• CPU 密集型任務（大量計算、循環處理）：ticks/計時器閾值極快觸發，頻繁切換上下文，多線程不僅無益反而拖慢效能。
• I/O 密集型任務（網路請求、檔案讀寫、爬蟲）：線程在 I/O 等待時主動釋放 GIL，其他線程可趁機執行，此時多線程能有效掩蓋等待延遲，提升吞吐量。

Python 3 改用計時器取代 ticks 計數，對 CPU 密集型略有優化，但無法突破「單進程單時刻單線程」的根本限制。

多進程：繞過 GIL 的真並行方案

每個 Python 進程擁有獨立的記憶體空間與 GIL，進程間互不干擾。利用 multiprocessing 模組啟動多進程，即可讓多核 CPU 同時執行 Python 代碼，實現真正的並行運算。這是充分利用多核硬體資源的通用最佳實踐。

總結與建議

• I/O 密集型：優先考慮 threading、asyncio 或協程框架
• CPU 密集型：務必使用 multiprocessing、concurrent.futures.ProcessPoolExecutor 或外部 C/C++/Rust 擴展（如 NumPy、Pandas 內部已釋放 GIL）
• 混合場景：進程池處理計算，線程池/協程處理 I/O

理解 GIL 本質，才能在架構選型時做出正確決策，避免在多核機器上陷入「多線程越多越慢」的陷阱。