為什麼有人說 Python 多執行緒是雞肋？

程式碼灣發表於2018-05-04
Python執行緒

為什麼有人會說 Python 多執行緒是雞肋？知乎上有人提出這樣一個問題，在我們常識中，多程式、多執行緒都是通過併發的方式充分利用硬體資源提高程式的執行效率，怎麼在 Python 中反而成了雞肋？

有同學可能知道答案，因為 Python 中臭名昭著的 GIL，GIL 是什麼？為什麼會有 GIL？多執行緒真的是雞肋嗎？ GIL 可以去掉嗎？帶著這些問題，我們一起往下看，同時需要你有一點點耐心。

多執行緒是不是雞肋，我們先做個實驗，實驗非常簡單，就是將數字 “1億” 遞減，減到 0 程式就終止，這個任務如果我們使用單執行緒來執行，完成時間會是多少？使用多執行緒又會是多少？show me the code

# 任務
def decrement(n):
    while n > 0:
        n -= 1

單執行緒 

import time

start = time.time()
decrement(100000000)
cost = time.time() - start
>>> 6.541690826416016

在我的4核 CPU 計算機中，單執行緒所花的時間是 6.5 秒。可能有人會問，執行緒在哪裡？其實任何程式執行時，預設都會有一個主執行緒在執行。（關於執行緒與程式這裡不展開，我會單獨開一篇文章）

多執行緒 

import threading

start = time.time()

t1 = threading.Thread(target=decrement, args=[50000000])
t2 = threading.Thread(target=decrement, args=[50000000])

t1.start() # 啟動執行緒，執行任務
t2.start() # 同上

t1.join() # 主執行緒阻塞，直到t1執行完成，主執行緒繼續往後執行
t2.join() # 同上

cost = time.time() - start

>>>6.85541033744812

建立兩個子執行緒 t1、t2，每個執行緒各執行 5 千萬次減操作，等兩個執行緒都執行完後，主執行緒終止程式執行。結果，兩個執行緒以合作的方式執行是 6.8 秒，反而變慢了。按理來說，兩個執行緒同時並行地執行在兩個 CPU 之上，時間應該減半才對，現在不減反增。

是什麼原因導致多執行緒不快反慢的呢？

原因就在於 GIL ，在 Cpython 直譯器（Python語言的主流直譯器）中，有一把全域性解釋鎖（Global Interpreter Lock），在直譯器解釋執行 Python 程式碼時，先要得到這把鎖，意味著，任何時候只可能有一個執行緒在執行程式碼，其它執行緒要想獲得 CPU 執行程式碼指令，就必須先獲得這把鎖，如果鎖被其它執行緒佔用了，那麼該執行緒就只能等待，直到佔有該鎖的執行緒釋放鎖才有執行程式碼指令的可能。

因此，這也就是為什麼兩個執行緒一起執行反而更加慢的原因，因為同一時刻，只有一個執行緒在執行，其它執行緒只能等待，即使是多核CPU，也沒辦法讓多個執行緒「並行」地同時執行程式碼，只能是交替執行，因為多執行緒涉及到上線文切換、鎖機制處理（獲取鎖，釋放鎖等），所以，多執行緒執行不快反慢。

什麼時候 GIL 被釋放呢？

當一個執行緒遇到 I/O 任務時，將釋放GIL。計算密集型（CPU-bound）執行緒執行 100 次直譯器的計步（ticks）時（計步可粗略看作 Python 虛擬機器的指令），也會釋放 GIL。可以通過 sys.setcheckinterval()設定計步長度，sys.getcheckinterval() 檢視計步長度。相比單執行緒，這些多是多執行緒帶來的額外開銷

CPython 直譯器為什麼要這樣設計？

多執行緒是為了適應現代計算機硬體高速發展充分利用多核處理器的產物，通過多執行緒使得 CPU 資源可以被高效利用起來，Python 誕生於1991年，那時候硬體配置遠沒有今天這樣豪華，現在一臺普通伺服器32核64G記憶體都不是什麼司空見慣的事，但是多執行緒有個問題，怎麼解決共享資料的同步、一致性問題，因為，對於多個執行緒訪問共享資料時，可能有兩個執行緒同時修改一個資料情況，如果沒有合適的機制保證資料的一致性，那麼程式最終導致異常，所以，Python之父就搞了個全域性的執行緒鎖，不管你資料有沒有同步問題，反正一刀切，上個全域性鎖，保證資料安全。這也就是多執行緒雞肋的原因，因為它沒有細粒度的控制資料的安全，而是用一種簡單粗暴的方式來解決。

這種解決辦法放在90年代，其實是沒什麼問題的，畢竟，那時候的硬體配置還很簡陋，單核 CPU 還是主流，多執行緒的應用場景也不多，大部分時候還是以單執行緒的方式執行，單執行緒不要涉及執行緒的上下文切換，效率反而比多執行緒更高（在多核環境下，不適用此規則）。所以，採用 GIL 的方式來保證資料的一致性和安全，未必不可取，至少在當時是一種成本很低的實現方式。

那麼把 GIL 去掉可行嗎？

還真有人這麼幹多，但是結果令人失望，在1999年Greg Stein 和Mark Hammond 兩位哥們就建立了一個去掉 GIL 的 Python 分支，在所有可變資料結構上把 GIL 替換為更為細粒度的鎖。然而，做過了基準測試之後，去掉GIL的 Python 在單執行緒條件下執行效率將近慢了2倍。

Python之父表示：基於以上的考慮，去掉GIL沒有太大的價值而不必花太多精力。

小結

CPython直譯器提供了GIL（全域性直譯器鎖）保證執行緒資料同步，那麼有了 GIL，我們還需要執行緒同步嗎？多執行緒在IO密集型任務中，表現又怎樣呢？歡迎大家留言

相關文章