爲什麼有人說 Python 多線程是雞肋?

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

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

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


  1. # 任務
  2. def decrement(n):
  3. while n > 0:
  4. n -= 1

單線程


  1. import time
  2. start = time.time()
  3. decrement(100000000)
  4. cost = time.time() - start
  5. >>> 6.541690826416016

在我的4核 CPU 計算機中,單線程所花的時間是 6.5 秒。可能有人會問,線程在哪裡?其實任何程序運行時,默認都會有一個主線程在執行。(關於線程與進程這裡不展開,我會單獨開一篇文章)

多線程


  1. import threading
  2. start = time.time()
  3. t1 = threading.Thread(target=decrement, args=[50000000])
  4. t2 = threading.Thread(target=decrement, args=[50000000])
  5. t1.start() # 啟動線程,執行任務
  6. t2.start() # 同上
  7. t1.join() # 主線程阻塞,直到t1執行完成,主線程繼續往後執行
  8. t2.join() # 同上
  9. cost = time.time() - start
  10. >>>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密集型任務中,表現又怎樣呢?歡迎大家留言

為什麼有人說 Python 多線程是雞肋?


分享到:


相關文章: