轉一篇關于Python GIL的文章。
歸納一下，CPU的大規模電路設計基本已經到了實體意義的盡頭，所有廠商們都開始轉向多核以進一步提高性能。Python為了能利用多核多線程的的優勢，但又要保證線程之間資料完整性和狀态同步，就采用了最簡單的加鎖的方式（是以說Python的GIL是設計之初一時偷懶造成的！）。Python庫的開發者們接受了這個設定，即預設Python是thread-safe，是以開始大量依賴這個特性，無需在實作時考慮額外的記憶體鎖和同步操作。但是GIL的設計有時會顯得笨拙低效，但是此時由于内置庫和第三方庫已經對GIL形成了牢不可破的依賴，想改革GIL反而變得困難了（暈！）。是以目前的現狀就是，Python的多線程在多核CPU上，隻對于IO密集型計算産生正面效果；而當有至少有一個CPU密集型線程存在，那麼多線程效率會由于GIL而大幅下降。雖然Python社群也在不斷為此努力改進，但恐怕短時間内不會有改變，是以想規避GIL的，可以使用多程序的multiprocessing或concurrent.futures子產品，或者換個Python的解析器。
多程序有一些缺點，它必須啟動Python的多個執行個體，啟動時間長，耗費記憶體多。同時，使用多程序并行運作任務，有一些極好的優點。多程序有它們各自的記憶體空間，使用的是無共享架構，資料通路十厘清晰。也更容易移植到分布式系統中。
Python的解析器 ——
含有GIL的有：CPython、PyPy、Psyco；
沒有GIL的有：JPython，IronPython。
原文位址： http://cenalulu.github.io/python/gil-in-python/
GIL是什麼
首先需要明确的一點是GIL并不是Python的特性，它是在實作Python解析器(CPython)時所引入的一個概念。就好比C++是一套語言（文法）标準，但是可以用不同的編譯器來編譯成可執行代碼。有名的編譯器例如GCC，INTEL C++，Visual C++等。Python也一樣，同樣一段代碼可以通過CPython，PyPy，Psyco等不同的Python執行環境來執行。像其中的JPython就沒有GIL。然而因為CPython是大部分環境下預設的Python執行環境。是以在很多人的概念裡CPython就是Python，也就想當然的把GIL歸結為Python語言的缺陷。是以這裡要先明确一點：GIL并不是Python的特性，Python完全可以不依賴于GIL
那麼CPython實作中的GIL又是什麼呢？GIL全稱Global Interpreter Lock為了避免誤導，我們還是來看一下官方給出的解釋：
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.)
好吧，是不是看上去很糟糕？一個防止多線程并發執行機器碼的一個Mutex，乍一看就是個BUG般存在的全局鎖嘛！别急，我們下面慢慢的分析。
為什麼會有GIL
由于實體上得限制，各CPU廠商在核心頻率上的比賽已經被多核所取代。為了更有效的利用多核處理器的性能，就出現了多線程的程式設計方式，而随之帶來的就是線程間資料一緻性和狀态同步的困難。即使在CPU内部的Cache也不例外，為了有效解決多份緩存之間的資料同步時各廠商花費了不少心思，也不可避免的帶來了一定的性能損失。
Python當然也逃不開，為了利用多核，Python開始支援多線程。而解決多線程之間資料完整性和狀态同步的最簡單方法自然就是加鎖。于是有了GIL這把超級大鎖，而當越來越多的代碼庫開發者接受了這種設定後，他們開始大量依賴這種特性（即預設python内部對象是thread-safe的，無需在實作時考慮額外的記憶體鎖和同步操作）。
慢慢的這種實作方式被發現是蛋疼且低效的。但當大家試圖去拆分和去除GIL的時候，發現大量庫代碼開發者已經重度依賴GIL而非常難以去除了。有多難？做個類比，像MySQL這樣的“小項目”為了把Buffer Pool Mutex這把大鎖拆分成各個小鎖也花了從5.5到5.6再到5.7多個大版為期近5年的時間，并且仍在繼續。MySQL這個背後有公司支援且有固定開發團隊的産品走的如此艱難，那又更何況Python這樣核心開發和代碼貢獻者高度社群化的團隊呢？
是以簡單的說GIL的存在更多的是曆史原因。如果推到重來，多線程的問題依然還是要面對，但是至少會比目前GIL這種方式會更優雅。
GIL的影響
從上文的介紹和官方的定義來看，GIL無疑就是一把全局排他鎖。毫無疑問全局鎖的存在會對多線程的效率有不小影響。甚至就幾乎等于Python是個單線程的程式。 那麼讀者就會說了，全局鎖隻要釋放的勤快效率也不會差啊。隻要在進行耗時的IO操作的時候，能釋放GIL，這樣也還是可以提升運作效率的嘛。或者說再差也不會比單線程的效率差吧。理論上是這樣，而實際上呢？Python比你想的更糟。
下面我們就對比下Python在多線程和單線程下得效率對比。測試方法很簡單，一個循環1億次的計數器函數。一個通過單線程執行兩次，一個多線程執行。最後比較執行總時間。測試環境為雙核的Mac pro。注：為了減少線程庫本身性能損耗對測試結果帶來的影響，這裡單線程的代碼同樣使用了線程。隻是順序的執行兩次，模拟單線程。
順序執行的單線程(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()
同時執行的兩個并發線程(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()
下圖就是測試結果
可以看到python在多線程的情況下居然比單線程整整慢了45%。按照之前的分析，即使是有GIL全局鎖的存在，串行化的多線程也應該和單線程有一樣的效率才對。那麼怎麼會有這麼糟糕的結果呢？
讓我們通過GIL的實作原理來分析這其中的原因。
目前GIL設計的缺陷
基于pcode數量的排程方式
按照Python社群的想法，作業系統本身的線程排程已經非常成熟穩定了，沒有必要自己搞一套。是以Python的線程就是C語言的一個pthread，并通過作業系統排程算法進行排程（例如linux是CFS）。為了讓各個線程能夠平均利用CPU時間，python會計算目前已執行的微代碼數量，達到一定門檻值後就強制釋放GIL。而這時也會觸發一次作業系統的線程排程（當然是否真正進行上下文切換由作業系統自主決定）。
僞代碼
while True:
acquire GIL
for i in 1000:
do something
release GIL
/* Give Operating System a chance to do thread scheduling */
這種模式在隻有一個CPU核心的情況下毫無問題。任何一個線程被喚起時都能成功獲得到GIL（因為隻有釋放了GIL才會引發線程排程）。但當CPU有多個核心的時候，問題就來了。從僞代碼可以看到，從release GIL到acquire GIL之間幾乎是沒有間隙的。是以當其他在其他核心上的線程被喚醒時，大部分情況下主線程已經又再一次擷取到GIL了。這個時候被喚醒執行的線程隻能白白的浪費CPU時間，看着另一個線程拿着GIL歡快的執行着。然後達到切換時間後進入待排程狀态，再被喚醒，再等待，以此往複惡性循環。
PS：當然這種實作方式是原始而醜陋的，Python的每個版本中也在逐漸改進GIL和線程排程之間的互動關系。例如先嘗試持有GIL在做線程上下文切換，在IO等待時釋放GIL等嘗試。但是無法改變的是GIL的存在使得作業系統線程排程的這個本來就昂貴的操作變得更奢侈了。
關于GIL影響的擴充閱讀為了直覺的了解GIL對于多線程帶來的性能影響，這裡直接借用的一張測試結果圖（見下圖）。圖中表示的是兩個線程在雙核CPU上得執行情況。兩個線程均為CPU密集型運算線程。綠色部分表示該線程在運作，且在執行有用的計算，紅色部分為線程被排程喚醒，但是無法擷取GIL導緻無法進行有效運算等待的時間。
由圖可見，GIL的存在導緻多線程無法很好的立即多核CPU的并發處理能力。
那麼Python的IO密集型線程能否從多線程中受益呢？我們來看下面這張測試結果。顔色代表的含義和上圖一緻。白色部分表示IO線程處于等待。可見，當IO線程收到資料包引起終端切換後，仍然由于一個CPU密集型線程的存在，導緻無法擷取GIL鎖，進而進行無盡的循環等待。
簡單的總結下就是：Python的多線程在多核CPU上，隻對于IO密集型計算産生正面效果；而當有至少有一個CPU密集型線程存在，那麼多線程效率會由于GIL而大幅下降。
如何避免受到GIL的影響
說了那麼多，如果不說解決方案就僅僅是個科普帖，然并卵。GIL這麼爛，有沒有辦法繞過呢？我們來看看有哪些現成的方案。
用multiprocessing替代Thread
multiprocessing庫的出現很大程度上是為了彌補thread庫因為GIL而低效的缺陷。它完整的複制了一套thread所提供的接口友善遷移。唯一的不同就是它使用了多程序而不是多線程。每個程序有自己的獨立的GIL，是以也不會出現程序之間的GIL争搶。
當然multiprocessing也不是萬能良藥。它的引入會增加程式實作時線程間資料通訊和同步的困難。就拿計數器來舉例子，如果我們要多個線程累加同一個變量，對于thread來說，申明一個global變量，用thread.Lock的context包裹住三行就搞定了。而multiprocessing由于程序之間無法看到對方的資料，隻能通過在主線程申明一個Queue，put再get或者用share memory的方法。這個額外的實作成本使得本來就非常痛苦的多線程程式編碼，變得更加痛苦了。具體難點在哪有興趣的讀者可以擴充閱讀這篇文章。
用其他解析器
之前也提到了既然GIL隻是CPython的産物，那麼其他解析器是不是更好呢？沒錯，像JPython和IronPython這樣的解析器由于實作語言的特性，他們不需要GIL的幫助。然而由于用了Java/C#用于解析器實作，他們也失去了利用社群衆多C語言子產品有用特性的機會。是以這些解析器也是以一直都比較小衆。畢竟功能和性能大家在初期都會選擇前者，Done is better than perfect。
是以沒救了麼？
當然Python社群也在非常努力的不斷改進GIL，甚至是嘗試去除GIL。并在各個小版本中有了不少的進步。
- 将切換顆粒度從基于opcode計數改成基于時間片計數
- 避免最近一次釋放GIL鎖的線程再次被立即排程
- 新增線程優先級功能（高優先級線程可以迫使其他線程釋放所持有的GIL鎖）
總結
Python GIL其實是功能和性能之間權衡後的産物，它尤其存在的合理性，也有較難改變的客觀因素。從本分的分析中，我們可以做以下一些簡單的總結：
- 因為GIL的存在，隻有IO Bound場景下得多線程會得到較好的性能
- 如果對并行計算性能較高的程式可以考慮把核心部分也改成C子產品，或者索性用其他語言實作
- GIL在較長一段時間内将會繼續存在，但是會不斷對其進行改進
進一步參考資料：
http://www.dabeaz.com/python/UnderstandingGIL.pdf https://mail.python.org/pipermail/python-dev/2009-October/093321.html