Python多線程無法利用多核的原因是什么

這篇文章主要講解了“Python多線程無法利用多核的原因是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Python多線程無法利用多核的原因是什么”吧！

1.全局解釋鎖

如題: Python的多線程為什么不能利用多核處理器?

全局解釋器鎖(Global Interpreter Lock)是計(jì)算機(jī)程序設(shè)計(jì)語言解釋器用于同步線程的一種機(jī)制，它使得任何時(shí)刻僅有一個(gè)線程在執(zhí)行。

即便在多核處理器上，使用 GIL 的解釋器也只允許同一時(shí)間執(zhí)行一個(gè)線程，常見的使用 GIL 的解釋器有CPython與Ruby MRI。

可以看到GIL并不是Python獨(dú)有的特性，是解釋型語言處理多線程問題的一種機(jī)制而非語言特性。

2.Python的解釋器

Python是一門解釋器語言，代碼通過解釋器執(zhí)行，Python存在多種解釋器，分別基于不同語言開發(fā)，每個(gè)解釋器有不同的特點(diǎn)。

Python程序的解釋和執(zhí)行過程簡圖:

• CPython

CPython是主流版本的解釋器，這個(gè)解釋器是使用C語言編寫的，也是使用最為廣泛的解釋器，可以方便地和C/C++的類庫進(jìn)行交互，因此也是最受關(guān)注的解釋器。

• Jython

一種由java語言編寫的python解釋器，是將python編譯成Java字節(jié)碼然后執(zhí)行的一種解釋器，可以方便地和Java的類庫進(jìn)行交互。

• IronPython

將Python代碼解釋為.Net平臺(tái)上運(yùn)行的字節(jié)碼進(jìn)行執(zhí)行，類似Jython解釋器，可以方便的和.Net平臺(tái)上的類庫進(jìn)行交互。IPython

在交互效果上有所增強(qiáng)，但執(zhí)行過程和功能方面和CPython是一樣的。

• PyPy

一種使用JIT(just-in-time)技術(shù)的編譯器，專注于執(zhí)行速度，對(duì)Python代碼進(jìn)行動(dòng)態(tài)編譯，從而提高Python的執(zhí)行速度。

PyPy在處理python代碼的過程中，一小部分功能的處理和CPython的執(zhí)行結(jié)果是有差異的，如果項(xiàng)目中要使用PyPy來進(jìn)行執(zhí)行效率的提升的話，一定要事先了解下PyPy和CPython的區(qū)別。

3.CPython的線程不安全

CPython的線程是操作系統(tǒng)的原生線程，在Linux的pthread完全由操作系統(tǒng)調(diào)度執(zhí)行。

pthread本身不是線程安全的，需要使用者通過鎖來實(shí)現(xiàn)多線程的安全運(yùn)行，因此CPython解釋器下的Python實(shí)現(xiàn)多線程也必然存在線程不安全的問題。

這就為GIL在多核時(shí)代的使用埋下了隱患。

4.GIL產(chǎn)生背景和挑戰(zhàn)

Python是Guido van Rossum  在1989年發(fā)布的，那個(gè)時(shí)候計(jì)算機(jī)的主頻還沒有達(dá)到1G，程序全部都是運(yùn)行在單核計(jì)算機(jī)上面，直到2005年多核處理器才被Intel開發(fā)出來。

Python各版本發(fā)布時(shí)間軸:

4.1 多核化對(duì)軟件系統(tǒng)的沖擊

戈登·摩爾 1965 年預(yù)測，每個(gè)集成電路的元件數(shù)量每 18 到 24 個(gè)月就會(huì)翻一倍，它的適用性預(yù)計(jì)會(huì)持續(xù)到 2015-2020 年。

摩爾定律未失效前軟件系統(tǒng)可以單純借助硬件的進(jìn)步來獲得性能的提升或者只需少量改進(jìn)，就可以坐享性能飛躍。

然而從 2005 年開始，時(shí)鐘速率的增長和晶體管數(shù)量的增長已不再同步。

由于處理器材料的物理性質(zhì)限制，時(shí)鐘速率已停止增長甚至下降，處理器制造商開始將更多執(zhí)行單元核心封裝到單個(gè)芯片中。

這一趨勢給應(yīng)用程序開發(fā)和編程語言設(shè)計(jì)帶來越來越大的壓力。

程序員和編程語言決策者不得不考慮如何快速適應(yīng)多核硬件，來提高軟件性能和編程語言的市場占有率，Python也不例外受到?jīng)_擊。

4.2 多核化對(duì)CPython的沖擊

在單核時(shí)代，崇尚優(yōu)美、清晰、簡單的吉多.范羅蘇姆選擇在解釋器層面實(shí)現(xiàn)了一把全局互斥鎖，來保護(hù)Python對(duì)象從而實(shí)現(xiàn)對(duì)單核CPU的使用率，這種做法在單核時(shí)代很奏效。

倘若在單核時(shí)未選擇GIL，那么開發(fā)者就需要自己實(shí)現(xiàn)任務(wù)的管理，這樣做對(duì)于CPU的利用率提高無法做到極致。

圖為Python之父吉多.范羅蘇姆:

但是隨著多核時(shí)代的到來，高效地利用CPU  核心的有效方法就是使用并行性，多線程是充分實(shí)現(xiàn)并行的好方法，但是CPython的GIL卻阻礙了對(duì)多核CPU的利用。

4.3 痛并快樂著的GIL

CPython的GIL給使用者帶來了便利，并且在GIL的基礎(chǔ)上開發(fā)了許多重要的Package和語言功能。

但是多核CPU的普適和其他語言對(duì)Python的沖擊，讓GIL顯得原始而粗暴，無法有效利用多核處理器成為了弊端。

5.多核時(shí)代GIL暴露的問題

要搞清楚GIL對(duì)多線程程序的影響就要了解GIL的運(yùn)行基本原理。

• 單核CPU情況

CPython的Pthread是通過操作系統(tǒng)調(diào)度算法調(diào)度執(zhí)行。

Python解釋器每執(zhí)行一定數(shù)量的字節(jié)碼，或遇到系統(tǒng)IO時(shí)，會(huì)強(qiáng)制釋放GIL，然后觸發(fā)一次操作系統(tǒng)的線程調(diào)度，實(shí)現(xiàn)單核CPU的充分利用，并且在單核上釋放和重新執(zhí)行的時(shí)間間隔非常短。

• 多核CPU情況

多核情況下多線程執(zhí)行時(shí)，一個(gè)線程在CPU-A執(zhí)行完之后釋放GIL，其他CPU上的線程都會(huì)進(jìn)行競爭，但CPU-A可能又馬上獲取到了GIL。

這就導(dǎo)致其他CPU上被喚醒的線程只能眼巴巴地看著CPU-A上的線程再次執(zhí)行，而自己只能等待，直到又被切換到待調(diào)度的狀態(tài)。

這就會(huì)產(chǎn)生多核CPU頻繁進(jìn)行線程切換，消耗著資源，但只有一個(gè)線程能夠拿到GIL真正執(zhí)行Python代碼，這就導(dǎo)致多線程在多核CPU情況下，效率還不如單線程執(zhí)行效率高。

這種情況非常類似于網(wǎng)絡(luò)編程中的多個(gè)線程監(jiān)聽同一端口造成的驚群現(xiàn)象，只不過是CPU級(jí)別的，造成的浪費(fèi)更加奢侈。

6.GIL的實(shí)際影響

• I/O密集型

在單核CPU上執(zhí)行多線程時(shí)由解釋器實(shí)現(xiàn)了有效的切換，這一點(diǎn)是很有益處的。

在I/O密集型的諸如網(wǎng)絡(luò)爬蟲等類型的程序即使使用GIL控制下的多線程程序性能也不會(huì)像你想象中那么糟糕。

• CPU密集型

對(duì)于CPU密集型的計(jì)算類程序GIL就有比較大的問題，因?yàn)镃PU密集型的程序本身沒有太多等待，不需要解釋器介入并且所有任務(wù)只能等待1個(gè)核心，其他核心空閑也無法使用，這么看對(duì)多核的使用確實(shí)很糟糕。

7.拋棄和優(yōu)化GIL

GIL一直備受爭議，為此PEP也多次嘗試刪除或者優(yōu)化GIL，但是解釋器本身的復(fù)雜性和眾多GIL下的類庫都讓GIL移除成為遙不可及的想法。

• 移除GIL

在1999年針對(duì)Python 1.5，一個(gè)free threading補(bǔ)丁已經(jīng)嘗試實(shí)現(xiàn)了這個(gè)想法，該補(bǔ)丁來自Greg Stein。

在這個(gè)補(bǔ)丁中，GIL被完全的移除，且用細(xì)粒度的鎖來代替。然而，GIL的移除給單線程程序的執(zhí)行速度帶來了一定的代價(jià)。

當(dāng)用單線程執(zhí)行時(shí)，速度大約降低了40%。使用兩個(gè)線程展示出了在速度上的提高，但除了這個(gè)提高，這個(gè)收益并沒有隨著核數(shù)的增加而線性增長。由于執(zhí)行速度的降低，這一補(bǔ)丁被拒絕了，并且?guī)缀醣蝗诉z忘。

1999年多核還是個(gè)幻想，但是在現(xiàn)今移除GIL也異常困難，真的移除效果如何也是未知的，只能說回頭太難。

• 優(yōu)化GIL

2009年Antoine Pitrou 在Python 3.2中實(shí)現(xiàn)了一個(gè)新的GIL，并且?guī)е恍┓e極的結(jié)果。

這是GIL的一次最主要改變，舊的GIL通過對(duì)Python指令進(jìn)行計(jì)數(shù)來確定何時(shí)放棄GIL。

單條Python指令將會(huì)包含大量的工作，在新的GIL實(shí)現(xiàn)中，用一個(gè)固定的超時(shí)時(shí)間來指示當(dāng)前的線程以放棄這個(gè)鎖，使得線程間的切換更加可預(yù)測。

8.GIL缺陷的解決方案

python作為生命力極強(qiáng)的熱門語言，絕對(duì)不會(huì)在多核時(shí)代坐以待斃。即便有GIL的限制，仍然有許多方法讓程序擁抱多核。

• 多進(jìn)程

Python2.6引入了MultiProcess庫來彌補(bǔ)Threading庫中GIL帶來的缺陷，基于此開發(fā)多進(jìn)程程序，每個(gè)進(jìn)程有單獨(dú)的GIL,避免多進(jìn)程之間對(duì)GIL的競爭，從而實(shí)現(xiàn)多核的利用，但是也帶來一些同步和通信問題，這也是必然會(huì)出現(xiàn)的。

• Ctypes

CPython的優(yōu)勢就是與C模塊的結(jié)合，因此可以借助Ctypes調(diào)用C的動(dòng)態(tài)庫來實(shí)現(xiàn)將計(jì)算轉(zhuǎn)移，C動(dòng)態(tài)庫沒有GIL可以實(shí)現(xiàn)對(duì)多核的利用。

• 協(xié)程

協(xié)程也是一個(gè)很好的手段，在Python3.4之前沒有對(duì)協(xié)程的支持，存在一些三方庫的實(shí)現(xiàn)，比如gevent和Tornado。

Python3.4之后就內(nèi)置了asyncio標(biāo)準(zhǔn)庫真正實(shí)現(xiàn)了協(xié)程這一特性。

9.小結(jié)

GIL仍然是Python語言里最困難的技術(shù)挑戰(zhàn)，GIL問題的并不是編程語言的本身問題，換做其他語言只是將問題轉(zhuǎn)移到了用戶層面，相反Python的作者嘗試將這種問題轉(zhuǎn)移到解釋器給使用者呈現(xiàn)一個(gè)優(yōu)雅的語言。

雖然多核時(shí)代的到來暴露了GIL的缺陷，但是Python決策者和社區(qū)開發(fā)者已經(jīng)做出了許多其他措施來擁抱多核，無知地詬病GIL是不明智的做法。

如同生產(chǎn)關(guān)系要適應(yīng)生產(chǎn)力的發(fā)展一樣，拋開歷史背景談機(jī)制的優(yōu)劣，都是有失偏頗的，所以對(duì)待GIL要辯證看待。

感謝各位的閱讀，以上就是“Python多線程無法利用多核的原因是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)Python多線程無法利用多核的原因是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！