python 線程，GIL 和 ctypes

原文地址：http://zhuoqiang.me/python-thread-gil-and-ctypes.htmlGIL 與 Python 線程的糾葛

GIL 是什麼東西？它對我們的 python 程式會產生什麼樣的影響？我們先來看一個問題。運行下面這段 python 程式，CPU 佔用率是多少？

# 請勿在工作中模仿，危險:)def dead_loop():    while True:        passdead_loop()

答案是什麼呢，佔用 100％ CPU？那是單核！還得是沒有超執行緒的古董 CPU。在我的雙核 CPU 上，這個死迴圈只會吃掉我一個核的工作負載，也就是只佔用 50％ CPU。那如何能讓它在雙核機器上佔用 100％ 的 CPU 呢？答案很容易想到，用兩個線程就行了，線程不正是並發分享 CPU 運算資源的嗎。可惜答案雖然對了，但做起來可沒那麼簡單。下面的程式在主線程之外又起了一個死迴圈的線程

import threadingdef dead_loop():    while True:        pass# 新起一個死迴圈線程t = threading.Thread(target=dead_loop)t.start()# 主線程也進入死迴圈dead_loop()t.join()

按道理它應該能做到佔用兩個核的 CPU 資源，可是實際運行情況卻是沒有什麼改變，還是只佔了 50％ CPU 不到。這又是為什麼呢？難道 python 線程不是作業系統的原生線程？開啟 system monitor 一探究竟，這個佔了 50% 的 python 進程確實是有兩個線程在跑。那這兩個死迴圈的線程為何不能佔滿雙核 CPU 資源呢？其實幕後的黑手就是 GIL。

GIL 的迷思：痛並快樂著

GIL 的全程為 Global Interpreter Lock ，意即全域解譯器鎖。在 Python 語言的主流實現 CPython 中，GIL 是一個貨真價實的全域線程鎖，在解譯器解釋執行任何 Python 代碼時，都需要先獲得這把鎖才行，在遇到
I/O 操作時會釋放這把鎖。如果是純計算的程式，沒有 I/O 操作，解譯器會每隔 100 次操作就釋放這把鎖，讓別的線程有機會執行（這個次數可以通過 sys.setcheckinterval 來調整）。所以雖然 CPython 的線程庫直接封裝作業系統的原生線程，但 CPython 進程做為一個整體，同一時間只會有一個獲得了 GIL 的線程在跑，其它的線程都處於等待狀態等著 GIL 的釋放。這也就解釋了我們上面的實驗結果：雖然有兩個死迴圈的線程，而且有兩個物理
CPU 核心，但因為 GIL 的限制，兩個線程只是做著分時切換，總的 CPU 佔用率還略低於 50％。

看起來 python 很不給力啊。GIL 直接導致 CPython 不能利用物理多核的效能加速運算。那為什麼會有這樣的設計呢？我猜想應該還是曆史遺留問題。多核 CPU 在 1990 年代還屬於類科幻，Guido van Rossum 在創造 python 的時候，也想不到他的語言有一天會被用到很可能 1000＋ 個核的 CPU 上面，一個全域鎖搞定多安全執行緒在那個時代應該是最簡單經濟的設計了。簡單而又能滿足需求，那就是合適的設計（對設計來說，應該只有合適與否，而沒有好與不好）。怪只怪硬體的發展實在太快了，摩爾定律給軟體業的紅利這麼快就要到頭了。短短
20 年不到，代碼工人就不能指望僅僅靠升級 CPU 就能讓老軟體跑的更快了。在多核時代，編程的免費午餐沒有了。如果程式不能用並發擠幹每個核的運算效能，那就意謂著會被淘汰。對軟體如此，對語言也是一樣。那 Python 的對策呢？

Python 的應對很簡單，以不變應萬變。在最新的 python 3 中依然有 GIL。之所以不去掉，原因嘛，不外以下幾點：

• 欲練神功，揮刀自宮：

  CPython 的 GIL 本意是用來保護所有全域的解譯器和環境狀態變數的。如果去掉 GIL，就需要多個更細粒度的鎖對解譯器的眾多全域狀態進行保護。或者採用 Lock-Free 演算法。無論哪一種，要做到多安全執行緒都會比單使用 GIL 一個鎖要難的多。而且改動的對象還是有 20 年歷史的 CPython 代碼樹，更不論有這麼多第三方的擴充也在依賴 GIL。對 Python 社區來說，這不異於揮刀自宮，重新來過。

• 就算自宮，也未必成功：

  有位牛人曾經做了一個驗證用的 CPython，將 GIL 去掉，加入了更多的細部鎖定。但是經過實際的測試，對單線程程式來說，這個版本有很大的效能下降，只有在利用的物理 CPU 超過一定數目後，才會比 GIL 版本的效能好。這也難怪。單線程本來就不需要什麼鎖。單就鎖管理本身來說，鎖 GIL 這個粗粒度的鎖肯定比管理眾多細粒度的鎖要快的多。而現在絕大部分的 python 程式都是單線程的。再者，從需求來說，使用 python 絕不是因為看中它的運算效能。就算能利用多核，它的效能也不可能和 C/C++ 比肩。費了大力氣把
  GIL 拿掉，反而讓大部分的程式都變慢了，這不是南轅北轍嗎。

• 難道 Python 這麼優秀的語言真的僅僅因為改動困難和意義不大就放棄多核時代了嗎？其實，不做改動最最重要的原因還在於：不用自宮，也一樣能成功！

其它神功

那除了切掉 GIL 外，果然還有方法讓 Python 在多核時代活的滋潤？讓我們回到本文最初的那個問題：如何能讓這個死迴圈的 Python 指令碼在雙核機器上佔用 100％ 的 CPU？其實最簡單的答案應該是：運行兩個 python 死迴圈的程式！也就是說，用兩個分別佔滿一個 CPU 核心的 python 進程來做到。確實，多進程也是利用多個 CPU 的好方法。只是進程間記憶體位址空間獨立，互相協同通訊要比多線程麻煩很多。有感於此，Python 在 2.6 裡新引入了 multiprocessing 這個多進程標準庫，讓多進程的
python 程式編寫簡化到類似多線程的程度，大大減輕了 GIL 帶來的不能利用多核的尷尬。

這還只是一個方法，如果不想用多進程這樣重量級的解決方案，還有個更徹底的方案，放棄 Python，改用 C/C++。當然，你也不用做的這麼絕，只需要把關鍵區段用 C/C++ 寫成 Python 擴充，其它部分還是用 Python 來寫，讓 Python 的歸 Python，C 的歸 C。一般計算密集性的程式都會用 C 代碼編寫並通過擴充的方式整合到 Python 指令碼裡（如 NumPy 模組）。在擴充裡就完全可以用 C 建立原生線程，而且不用鎖 GIL，充分利用 CPU 的計算資源了。不過，寫 Python 擴充總是讓人覺得很複雜。好在
Python 還有另一種與 C 模組進行互連的機制 : ctypes

利用 ctypes 繞過 GIL

ctypes 與 Python 擴充不同，它可以讓 Python 直接調用任意的 C 動態庫的匯出函數。你所要做的只是用 ctypes 寫些 python 代碼即可。最酷的是，ctypes 會在調用 C 函數前釋放 GIL。所以，我們可以通過 ctypes 和 C 動態庫來讓 python 充分利用物理核心的計算能力。讓我們來實際驗證一下，這次我們用 C 寫一個死迴圈函數

extern"C"{  void DeadLoop()  {    while (true);  }}

用上面的 C 代碼編譯產生動態庫 libdead_loop.so （Windows 上是 dead_loop.dll）

，接著就要利用 ctypes 來在 python 裡 load 這個動態庫，分別在主線程和建立線程裡調用其中的 DeadLoop

from ctypes import *from threading import Threadlib = cdll.LoadLibrary("libdead_loop.so")t = Thread(target=lib.DeadLoop)t.start()lib.DeadLoop()

這回再看看 system monitor，Python 解譯器進程有兩個線程在跑，而且雙核 CPU 全被佔滿了，ctypes 確實很給力！需要提醒的是，GIL 是被 ctypes 在調用 C 函數前釋放的。但是 Python 解譯器還是會在執行任意一段 Python 代碼時鎖 GIL 的。如果你使用 Python 的代碼做為 C 函數的 callback，那麼只要 Python 的 callback 方法被執行時，GIL 還是會跳出來的。比如下面的例子：

extern"C"{  typedef void Callback();  void Call(Callback* callback)  {    callback();  }}

from ctypes import *from threading import Threaddef dead_loop():    while True:        passlib = cdll.LoadLibrary("libcall.so")Callback = CFUNCTYPE(None)callback = Callback(dead_loop)t = Thread(target=lib.Call, args=(callback,))t.start()lib.Call(callback)

注意這裡與上個例子的不同之處，這次的死迴圈是發生在 Python 代碼裡 (DeadLoop 函數) 而 C 代碼只是負責去調用這個 callback 而已。運行這個例子，你會發現 CPU 佔用率還是只有 50％ 不到。GIL 又起作用了。

其實，從上面的例子，我們還能看出 ctypes 的一個應用，那就是用 Python 寫自動化測試案例，通過 ctypes 直接調用 C 模組的介面來對這個模組進行黑箱測試，哪怕是有關該模組 C 介面的多安全執行緒方面的測試，ctypes 也一樣能做到。

結語

雖然 CPython 的線程庫封裝了作業系統的原生線程，但卻因為 GIL 的存在導致多線程不能利用多個 CPU 核心的計算能力。好在現在 Python 有了易經筋（multiprocessing）, 吸星大法（C 語言擴充機制）和獨孤九劍（ctypes），足以應付多核時代的挑戰，GIL 切還是不切已經不重要了，不是嗎。