轉(zhuǎn)一篇關(guān)于Python GIL的文章能庆。
歸納一下鸵贬，CPU的大規(guī)模電路設(shè)計基本已經(jīng)到了物理意義的盡頭，所有廠商們都開始轉(zhuǎn)向多核以進一步提高性能屎媳。Python為了能利用多核多線程的的優(yōu)勢夺溢，但又要保證線程之間數(shù)據(jù)完整性和狀態(tài)同步，就采用了最簡單的加鎖的方式（所以說Python的GIL是設(shè)計之初一時偷懶造成的Ｖ蛞辍）风响。Python庫的開發(fā)者們接受了這個設(shè)定，即默認(rèn)Python是thread-safe丹禀，所以開始大量依賴這個特性状勤，無需在實現(xiàn)時考慮額外的內(nèi)存鎖和同步操作。但是GIL的設(shè)計有時會顯得笨拙低效双泪，但是此時由于內(nèi)置庫和第三方庫已經(jīng)對GIL形成了牢不可破的依賴持搜，想改革GIL反而變得困難了（暈！）焙矛。所以目前的現(xiàn)狀就是葫盼，Python的多線程在多核CPU上，只對于IO密集型計算產(chǎn)生正面效果村斟；而當(dāng)有至少有一個CPU密集型線程存在剪返，那么多線程效率會由于GIL而大幅下降。雖然Python社區(qū)也在不斷為此努力改進邓梅，但恐怕短時間內(nèi)不會有改變脱盲，所以想規(guī)避GIL的，可以使用多進程的multiprocessing或concurrent.futures模塊日缨，或者換個Python的解析器钱反。
多進程有一些缺點，它必須啟動Python的多個實例匣距，啟動時間長面哥，耗費內(nèi)存多。同時毅待，使用多進程并行運行任務(wù)尚卫，有一些極好的優(yōu)點。多進程有它們各自的內(nèi)存空間尸红，使用的是無共享架構(gòu)吱涉，數(shù)據(jù)訪問十分清晰刹泄。也更容易移植到分布式系統(tǒng)中。
Python的解析器 ——
含有GIL的有：CPython怎爵、PyPy特石、Psyco；
沒有GIL的有：JPython鳖链，IronPython姆蘸。
GIL是什么
首先需要明確的一點是GIL并不是Python的特性，它是在實現(xiàn)Python解析器(CPython)時所引入的一個概念芙委。就好比C++是一套語言（語法）標(biāo)準(zhǔn)逞敷，但是可以用不同的編譯器來編譯成可執(zhí)行代碼。有名的編譯器例如GCC灌侣，INTEL C++兰粉，Visual C++等。Python也一樣顶瞳，同樣一段代碼可以通過CPython，PyPy愕秫，Psyco等不同的Python執(zhí)行環(huán)境來執(zhí)行慨菱。像其中的JPython就沒有GIL。然而因為CPython是大部分環(huán)境下默認(rèn)的Python執(zhí)行環(huán)境戴甩。所以在很多人的概念里CPython就是Python符喝，也就想當(dāng)然的把GIL歸結(jié)為Python語言的缺陷。所以這里要先明確一點：GIL并不是Python的特性甜孤，Python完全可以不依賴于GIL
那么CPython實現(xiàn)中的GIL又是什么呢协饲？GIL全稱Global Interpreter Lock為了避免誤導(dǎo)，我們還是來看一下官方給出的解釋：
In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)
好吧缴川，是不是看上去很糟糕茉稠？一個防止多線程并發(fā)執(zhí)行機器碼的一個Mutex，乍一看就是個BUG般存在的全局鎖嘛把夸！別急而线，我們下面慢慢的分析。
為什么會有GIL
由于物理上得限制恋日，各CPU廠商在核心頻率上的比賽已經(jīng)被多核所取代膀篮。為了更有效的利用多核處理器的性能，就出現(xiàn)了多線程的編程方式岂膳，而隨之帶來的就是線程間數(shù)據(jù)一致性和狀態(tài)同步的困難誓竿。即使在CPU內(nèi)部的Cache也不例外，為了有效解決多份緩存之間的數(shù)據(jù)同步時各廠商花費了不少心思谈截，也不可避免的帶來了一定的性能損失筷屡。
Python當(dāng)然也逃不開涧偷，為了利用多核，Python開始支持多線程速蕊。而解決多線程之間數(shù)據(jù)完整性和狀態(tài)同步的最簡單方法自然就是加鎖嫂丙。于是有了GIL這把超級大鎖，而當(dāng)越來越多的代碼庫開發(fā)者接受了這種設(shè)定后规哲，他們開始大量依賴這種特性（即默認(rèn)python內(nèi)部對象是thread-safe的跟啤，無需在實現(xiàn)時考慮額外的內(nèi)存鎖和同步操作）。
慢慢的這種實現(xiàn)方式被發(fā)現(xiàn)是蛋疼且低效的唉锌。但當(dāng)大家試圖去拆分和去除GIL的時候隅肥，發(fā)現(xiàn)大量庫代碼開發(fā)者已經(jīng)重度依賴GIL而非常難以去除了。有多難袄简？做個類比腥放，像MySQL這樣的“小項目”為了把Buffer Pool Mutex這把大鎖拆分成各個小鎖也花了從5.5到5.6再到5.7多個大版為期近5年的時間，并且仍在繼續(xù)绿语。MySQL這個背后有公司支持且有固定開發(fā)團隊的產(chǎn)品走的如此艱難秃症，那又更何況Python這樣核心開發(fā)和代碼貢獻者高度社區(qū)化的團隊呢？
所以簡單的說GIL的存在更多的是歷史原因吕粹。如果推到重來种柑，多線程的問題依然還是要面對，但是至少會比目前GIL這種方式會更優(yōu)雅匹耕。
GIL的影響
從上文的介紹和官方的定義來看聚请，GIL無疑就是一把全局排他鎖。毫無疑問全局鎖的存在會對多線程的效率有不小影響稳其。甚至就幾乎等于Python是個單線程的程序驶赏。 那么讀者就會說了，全局鎖只要釋放的勤快效率也不會差啊既鞠。只要在進行耗時的IO操作的時候煤傍，能釋放GIL，這樣也還是可以提升運行效率的嘛嘱蛋』季茫或者說再差也不會比單線程的效率差吧。理論上是這樣浑槽，而實際上呢蒋失？Python比你想的更糟。
下面我們就對比下Python在多線程和單線程下得效率對比桐玻。測試方法很簡單篙挽，一個循環(huán)1億次的計數(shù)器函數(shù)。一個通過單線程執(zhí)行兩次镊靴，一個多線程執(zhí)行铣卡。最后比較執(zhí)行總時間链韭。測試環(huán)境為雙核的Mac pro。注：為了減少線程庫本身性能損耗對測試結(jié)果帶來的影響煮落，這里單線程的代碼同樣使用了線程敞峭。只是順序的執(zhí)行兩次，模擬單線程蝉仇。
順序執(zhí)行的單線程(single_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
t.join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()
同時執(zhí)行的兩個并發(fā)線程(multi_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
thread_array[tid] = t
for i in range(2):
thread_array[i].join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()
下圖就是測試結(jié)果
可以看到python在多線程的情況下居然比單線程整整慢了45%旋讹。按照之前的分析，即使是有GIL全局鎖的存在轿衔，串行化的多線程也應(yīng)該和單線程有一樣的效率才對沉迹。那么怎么會有這么糟糕的結(jié)果呢？
讓我們通過GIL的實現(xiàn)原理來分析這其中的原因害驹。
當(dāng)前GIL設(shè)計的缺陷
基于pcode數(shù)量的調(diào)度方式
按照Python社區(qū)的想法鞭呕，操作系統(tǒng)本身的線程調(diào)度已經(jīng)非常成熟穩(wěn)定了，沒有必要自己搞一套宛官。所以Python的線程就是C語言的一個pthread葫松，并通過操作系統(tǒng)調(diào)度算法進行調(diào)度（例如linux是CFS）。為了讓各個線程能夠平均利用CPU時間底洗，python會計算當(dāng)前已執(zhí)行的微代碼數(shù)量腋么，達到一定閾值后就強制釋放GIL。而這時也會觸發(fā)一次操作系統(tǒng)的線程調(diào)度（當(dāng)然是否真正進行上下文切換由操作系統(tǒng)自主決定）枷恕。
偽代碼
while True:
acquire GIL
for i in 1000:
do something
release GIL
/* Give Operating System a chance to do thread scheduling */
這種模式在只有一個CPU核心的情況下毫無問題。任何一個線程被喚起時都能成功獲得到GIL（因為只有釋放了GIL才會引發(fā)線程調(diào)度）谭胚。但當(dāng)CPU有多個核心的時候徐块，問題就來了。從偽代碼可以看到灾而，從release GIL到acquire GIL之間幾乎是沒有間隙的胡控。所以當(dāng)其他在其他核心上的線程被喚醒時，大部分情況下主線程已經(jīng)又再一次獲取到GIL了旁趟。這個時候被喚醒執(zhí)行的線程只能白白的浪費CPU時間昼激，看著另一個線程拿著GIL歡快的執(zhí)行著。然后達到切換時間后進入待調(diào)度狀態(tài)锡搜，再被喚醒橙困，再等待，以此往復(fù)惡性循環(huán)耕餐。
PS：當(dāng)然這種實現(xiàn)方式是原始而丑陋的凡傅，Python的每個版本中也在逐漸改進GIL和線程調(diào)度之間的互動關(guān)系。例如先嘗試持有GIL在做線程上下文切換肠缔，在IO等待時釋放GIL等嘗試夏跷。但是無法改變的是GIL的存在使得操作系統(tǒng)線程調(diào)度的這個本來就昂貴的操作變得更奢侈了哼转。 關(guān)于GIL影響的擴展閱讀
為了直觀的理解GIL對于多線程帶來的性能影響，這里直接借用的一張測試結(jié)果圖（見下圖）槽华。圖中表示的是兩個線程在雙核CPU上得執(zhí)行情況壹蔓。兩個線程均為CPU密集型運算線程。綠色部分表示該線程在運行猫态，且在執(zhí)行有用的計算佣蓉，紅色部分為線程被調(diào)度喚醒，但是無法獲取GIL導(dǎo)致無法進行有效運算等待的時間懂鸵。
由圖可見偏螺，GIL的存在導(dǎo)致多線程無法很好的立即多核CPU的并發(fā)處理能力。
那么Python的IO密集型線程能否從多線程中受益呢匆光？我們來看下面這張測試結(jié)果套像。顏色代表的含義和上圖一致。白色部分表示IO線程處于等待终息《峁可見，當(dāng)IO線程收到數(shù)據(jù)包引起終端切換后周崭，仍然由于一個CPU密集型線程的存在柳譬，導(dǎo)致無法獲取GIL鎖，從而進行無盡的循環(huán)等待续镇。
簡單的總結(jié)下就是：Python的多線程在多核CPU上美澳，只對于IO密集型計算產(chǎn)生正面效果；而當(dāng)有至少有一個CPU密集型線程存在摸航，那么多線程效率會由于GIL而大幅下降制跟。
如何避免受到GIL的影響
說了那么多，如果不說解決方案就僅僅是個科普帖酱虎，然并卵雨膨。GIL這么爛，有沒有辦法繞過呢读串？我們來看看有哪些現(xiàn)成的方案聊记。
用multiprocessing替代Thread
multiprocessing庫的出現(xiàn)很大程度上是為了彌補thread庫因為GIL而低效的缺陷。它完整的復(fù)制了一套thread所提供的接口方便遷移恢暖。唯一的不同就是它使用了多進程而不是多線程排监。每個進程有自己的獨立的GIL，因此也不會出現(xiàn)進程之間的GIL爭搶杰捂。
當(dāng)然multiprocessing也不是萬能良藥社露。它的引入會增加程序?qū)崿F(xiàn)時線程間數(shù)據(jù)通訊和同步的困難。就拿計數(shù)器來舉例子琼娘，如果我們要多個線程累加同一個變量峭弟，對于thread來說附鸽，申明一個global變量，用thread.Lock的context包裹住三行就搞定了瞒瘸。而multiprocessing由于進程之間無法看到對方的數(shù)據(jù)坷备，只能通過在主線程申明一個Queue，put再get或者用share memory的方法情臭。這個額外的實現(xiàn)成本使得本來就非常痛苦的多線程程序編碼省撑，變得更加痛苦了。具體難點在哪有興趣的讀者可以擴展閱讀這篇文章俯在。
用其他解析器
之前也提到了既然GIL只是CPython的產(chǎn)物竟秫，那么其他解析器是不是更好呢？沒錯跷乐，像JPython和IronPython這樣的解析器由于實現(xiàn)語言的特性肥败，他們不需要GIL的幫助。然而由于用了Java/C#用于解析器實現(xiàn)愕提，他們也失去了利用社區(qū)眾多C語言模塊有用特性的機會馒稍。所以這些解析器也因此一直都比較小眾。畢竟功能和性能大家在初期都會選擇前者浅侨，Done is better than perfect纽谒。
所以沒救了么？
當(dāng)然Python社區(qū)也在非常努力的不斷改進GIL如输，甚至是嘗試去除GIL鼓黔。并在各個小版本中有了不少的進步。
- 將切換顆粒度從基于opcode計數(shù)改成基于時間片計數(shù)
- 避免最近一次釋放GIL鎖的線程再次被立即調(diào)度
- 新增線程優(yōu)先級功能（高優(yōu)先級線程可以迫使其他線程釋放所持有的GIL鎖）
總結(jié)
Python GIL其實是功能和性能之間權(quán)衡后的產(chǎn)物不见，它尤其存在的合理性澳化，也有較難改變的客觀因素。從本分的分析中脖祈，我們可以做以下一些簡單的總結(jié)：
- 因為GIL的存在肆捕，只有IO Bound場景下得多線程會得到較好的性能
- 如果對并行計算性能較高的程序可以考慮把核心部分也改成C模塊刷晋，或者索性用其他語言實現(xiàn)
- GIL在較長一段時間內(nèi)將會繼續(xù)存在盖高，但是會不斷對其進行改進
進一步參考資料：
http://www.dabeaz.com/python/UnderstandingGIL.pdf
https://mail.python.org/pipermail/python-dev/2009-October/093321.html
