Python GIL 全解析：為什麼多線程受限、多進程才是多核利器

Python 全局解釋器鎖 (GIL) 深度解析：從原理到多核並行最佳實踐

「Python 多線程是雞肋，請用多進程」——這句話在社區流傳甚廣。本文從 GIL 設計初衷、運行機制、Python 2/3 差異、CPU/IO 密集型表現差異、多核下的線程顫簸現象，系統論證為何多進程才是 Python 利用多核的正解。

一、GIL 是什麼？為什麼存在？

• 全稱：Global Interpreter Lock（全局解釋器鎖）
• 本質：CPython 解釋器進程內的一把**互斥鎖**，同一時刻**只允許一個線程執行字節碼**
• 歷史緣由：
  1. CPython 內存管理非線程安全（引用計數 + 垃圾回收）
  2. 早期 C 擴展庫大量假設單線程，無鎖設計
  3. 為了兼容性、簡化實現、單線程性能，引入 GIL

二、線程執行流程：搶鎖 → 執行 → 釋放

while (true) {
    acquire(GIL);           // 1. 拿到「通行證」
    run_bytecode(ticks);    // 2. 執行字節碼（直到 IO / 時間片用盡）
    release(GIL);           // 3. 歸還鎖，喚醒其他線程
}

關鍵點：GIL 是**進程級**的，每個進程獨立擁有一把，進程間互不干擾。

三、Python 2 vs 3 釋放策略演進

四、CPU 密集型 vs IO 密集型：多線程表現對比

五、多核下的「線程顫簸」：為何多核多線程比單核更差

1. CPU 0 線程釋放 GIL
2. CPU 1~n 線程被喚醒，**瘋狂搶鎖**
3. GIL 可能瞬間又被 CPU 0 搶回（缓存親和性）
4. 其他 CPU 線程「醒來→等待→再睡眠」，產生 **thrashing（顫簸）**，上下文切換開銷激增

實測結論：CPU 核心數越多，GIL 爭用越劇烈，多線程性能**遞減**。

六、多進程：真正的多核並行

• 每個進程**獨立內存空間**、**獨立 GIL**
• 操作系統調度進程到不同物理核心，**真並行**
• multiprocessing.Process / Pool API 與 threading 極其相似，遷移成本低

from multiprocessing import Pool

def cpu_heavy(x):
    return sum(i * i for i in range(x))

if __name__ == '__main__':
    with Pool(4) as p:           # 4 進程 = 4 核並行
        print(p.map(cpu_heavy, [10**6]*4))

七、繞過 GIL 的其他路徑

1. C 擴展釋放 GIL：NumPy、Pandas、Pillow 等底層 C 代碼執行時主動 Py_BEGIN_ALLOW_THREADS，實現多線程並行
2. 異步 IO (asyncio)：單線程事件循環，適合高併發 IO，無 GIL 爭用
3. 替代解釋器：PyPy (JIT 優化)、Jython (無 GIL)、GraalPython — 生態兼容性需評估
4. 子進程 + 共享內存：multiprocessing.shared_memory (Py3.8+) 降低 IPC 開銷

八、選型決策樹

任務類型
├─ CPU 密集型
│   ├─ 純 Python → multiprocessing / ProcessPoolExecutor
│   └─ 可用 C 庫 (NumPy等) → 多線程（庫內釋放 GIL）
└─ IO 密集型
    ├─ 高併發、長連接 → asyncio / aiohttp
    ├─ 簡單阻塞 IO → threading / ThreadPoolExecutor
    └─ 需繞過 GIL 做並行計算 → multiprocessing

九、總結

• GIL 是 CPython 為內存安全、C 擴展兼容、單線程性能做的權衡，**不會被移除**
• 多線程**無法利用多核並行**（CPU 密集型），只能併發 IO
• 多進程擁有獨立 GIL，**是 Python 利用多核 CPU 的標準方式**
• 認清任務屬性（CPU/IO），選對工具（threading/multiprocessing/asyncio/C擴展）