爲何Python多線程沒法利用多核

1.全局解釋鎖

如題: Python的多線程爲何不能利用多核處理器？

全局解釋器鎖(Global Interpreter Lock)是計算機程序設計語言解釋器用於同步線程的一種機制，它使得任什麼時候刻僅有一個線程在執行。

即使在多核處理器上，使用 GIL 的解釋器也只容許同一時間執行一個線程，常見的使用 GIL 的解釋器有CPython與Ruby MRI。

能夠看到GIL並非Python獨有的特性，是解釋型語言處理多線程問題的一種機制而非語言特性。

2.Python的解釋器

Python是一門解釋器語言，代碼經過解釋器執行，Python存在多種解釋器，分別基於不一樣語言開發，每一個解釋器有不一樣的特色。

Python程序的解釋和執行過程簡圖:

• CPython

CPython是主流版本的解釋器，這個解釋器是使用C語言編寫的，也是使用最爲普遍的解釋器，能夠方便地和C/C++的類庫進行交互，所以也是最受關注的解釋器。

• Jython

一種由java語言編寫的python解釋器，是將python編譯成Java字節碼而後執行的一種解釋器，能夠方便地和Java的類庫進行交互。

• IronPython

將Python代碼解釋爲.Net平臺上運行的字節碼進行執行，相似Jython解釋器，能夠方便的和.Net平臺上的類庫進行交互。IPython

在交互效果上有所加強，但執行過程和功能方面和CPython是同樣的。

• PyPy

一種使用JIT(just-in-time)技術的編譯器，專一於執行速度，對Python代碼進行動態編譯，從而提升Python的執行速度。

PyPy在處理python代碼的過程當中，一小部分功能的處理和CPython的執行結果是有差別的，若是項目中要使用PyPy來進行執行效率的提高的話，必定要事先了解下PyPy和CPython的區別。

3.CPython的線程不安全

CPython的線程是操做系統的原生線程，在Linux的pthread徹底由操做系統調度執行。

pthread自己不是線程安全的，須要使用者經過鎖來實現多線程的安全運行，所以CPython解釋器下的Python實現多線程也必然存在線程不安全的問題。

這就爲GIL在多核時代的使用埋下了隱患。

4.GIL產生背景和挑戰

Python是Guido van Rossum 在1989年發佈的，那個時候計算機的主頻尚未達到1G，程序所有都是運行在單核計算機上面，直到2005年多核處理器才被Intel開發出來。

Python各版本發佈時間軸:

4.1 多核化對軟件系統的衝擊

戈登·摩爾 1965 年預測，每一個集成電路的元件數量每 18 到 24 個月就會翻一倍，它的適用性預計會持續到 2015-2020 年。

摩爾定律未失效前軟件系統能夠單純藉助硬件的進步來得到性能的提高或者只需少許改進，就能夠坐享性能飛躍。

然而從 2005 年開始，時鐘速率的增加和晶體管數量的增加已再也不同步。

因爲處理器材料的物理性質限制，時鐘速率已中止增加甚至降低，處理器製造商開始將更多執行單元核心封裝到單個芯片中。

這一趨勢給應用程序開發和編程語言設計帶來愈來愈大的壓力。

程序員和編程語言決策者不得不考慮如何快速適應多核硬件，來提升軟件性能和編程語言的市場佔有率，Python也不例外受到衝擊。

4.2 多核化對CPython的衝擊

在單核時代，崇尚優美、清晰、簡單的吉多.範羅蘇姆選擇在解釋器層面實現了一把全局互斥鎖，來保護Python對象從而實現對單核CPU的使用率，這種作法在單核時代很奏效。

假若在單核時未選擇GIL，那麼開發者就須要本身實現任務的管理，這樣作對於CPU的利用率提升沒法作到極致。

圖爲Python之父吉多.範羅蘇姆:

可是隨着多核時代的到來，高效地利用CPU 核心的有效方法就是使用並行性，多線程是充分實現並行的好方法，可是CPython的GIL卻阻礙了對多核CPU的利用。

4.3 痛並快樂着的GIL

CPython的GIL給使用者帶來了便利，而且在GIL的基礎上開發了許多重要的Package和語言功能。

可是多核CPU的普適和其餘語言對Python的衝擊，讓GIL顯得原始而粗暴，沒法有效利用多核處理器成爲了弊端。

5.多核時代GIL暴露的問題

要搞清楚GIL對多線程程序的影響就要了解GIL的運行基本原理。

• 單核CPU狀況

CPython的Pthread是經過操做系統調度算法調度執行。

Python解釋器每執行必定數量的字節碼，或遇到系統IO時，會強制釋放GIL，而後觸發一次操做系統的線程調度，實現單核CPU的充分利用，而且在單核上釋放和從新執行的時間間隔很是短。

• 多核CPU狀況

多核狀況下多線程執行時，一個線程在CPU-A執行完以後釋放GIL，其餘CPU上的線程都會進行競爭，但CPU-A可能又立刻獲取到了GIL。

這就致使其餘CPU上被喚醒的線程只能眼巴巴地看着CPU-A上的線程再次執行，而本身只能等待，直到又被切換到待調度的狀態。

這就會產生多核CPU頻繁進行線程切換，消耗着資源，但只有一個線程可以拿到GIL真正執行Python代碼，這就致使多線程在多核CPU狀況下，效率還不如單線程執行效率高。

這種狀況很是相似於網絡編程中的多個線程監聽同一端口形成的驚羣現象，只不過是CPU級別的，形成的浪費更加奢侈。

6.GIL的實際影響

• I/O密集型

在單核CPU上執行多線程時由解釋器實現了有效的切換，這一點是頗有益處的。

在I/O密集型的諸如網絡爬蟲等類型的程序即便使用GIL控制下的多線程程序性能也不會像你想象中那麼糟糕。

• CPU密集型

對於CPU密集型的計算類程序GIL就有比較大的問題，由於CPU密集型的程序自己沒有太多等待，不須要解釋器介入而且全部任務只能等待1個核心，其餘核心空閒也沒法使用，這麼看對多核的使用確實很糟糕。

7.拋棄和優化GIL

GIL一直備受爭議，爲此PEP也屢次嘗試刪除或者優化GIL，可是解釋器自己的複雜性和衆多GIL下的類庫都讓GIL移除成爲高不可攀的想法。

• 移除GIL

在1999年針對Python 1.5，一個free threading補丁已經嘗試實現了這個想法，該補丁來自Greg Stein。

在這個補丁中，GIL被徹底的移除，且用細粒度的鎖來代替。然而，GIL的移除給單線程程序的執行速度帶來了必定的代價。

當用單線程執行時，速度大約下降了40%。使用兩個線程展現出了在速度上的提升，但除了這個提升，這個收益並無隨着核數的增長而線性增加。因爲執行速度的下降，這一補丁被拒絕了，而且幾乎被人遺忘。

1999年多核仍是個幻想，可是在現今移除GIL也異常困難，真的移除效果如何也是未知的，只能說回頭太難。

• 優化GIL

2009年Antoine Pitrou 在Python 3.2中實現了一個新的GIL，而且帶着一些積極的結果。

這是GIL的一次最主要改變，舊的GIL經過對Python指令進行計數來肯定什麼時候放棄GIL。

單條Python指令將會包含大量的工做，在新的GIL實現中，用一個固定的超時時間來指示當前的線程以放棄這個鎖，使得線程間的切換更加可預測。

8.GIL缺陷的解決方案

python做爲生命力極強的熱門語言，絕對不會在多核時代坐以待斃。即使有GIL的限制，仍然有許多方法讓程序擁抱多核。

• 多進程

Python2.6引入了MultiProcess庫來彌補Threading庫中GIL帶來的缺陷，基於此開發多進程程序，每一個進程有單獨的GIL,避免多進程之間對GIL的競爭，從而實現多核的利用，可是也帶來一些同步和通訊問題，這也是必然會出現的。

• Ctypes

CPython的優點就是與C模塊的結合，所以能夠藉助Ctypes調用C的動態庫來實現將計算轉移，C動態庫沒有GIL能夠實現對多核的利用。

• 協程

協程也是一個很好的手段，在Python3.4以前沒有對協程的支持，存在一些三方庫的實現，好比gevent和Tornado。

Python3.4以後就內置了asyncio標準庫真正實現了協程這一特性。

9.小結

GIL仍然是Python語言裏最困難的技術挑戰，GIL問題的並非編程語言的自己問題，換作其餘語言只是將問題轉移到了用戶層面，相反Python的做者嘗試將這種問題轉移到解釋器給使用者呈現一個優雅的語言。

雖然多核時代的到來暴露了GIL的缺陷，可是Python決策者和社區開發者已經作出了許多其餘措施來擁抱多核，無知地詬病GIL是不明智的作法。

如同生產關係要適應生產力的發展同樣，拋開歷史背景談機制的優劣，都是有失偏頗的，因此對待GIL要辯證看待。

 

本文的文字及圖片來源於網絡,僅供學習、交流使用,不具備任何商業用途,若有問題請及時聯繫咱們以做處理

想要獲取更多Python學習資料能夠加QQ:2955637827私聊或加Q羣630390733你們一塊兒來學習討論吧！