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 Gemory exists, gret exists, 片語 thats hents holes exists, sad exists, sdly exists.
#好吧，是不是看起來很糟糕？一個防止多執行緒並發執行機器碼的一個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/pythonfrom threading import Threadimport timedef my_counter(): i = 0 for _ in range(100000000): i = i + 1 return Truedef 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/pythonfrom threading import Threadimport timedef my_counter(): i = 0 for _ in range(100000000): i = i + 1 return Truedef 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。並在各個小版本中有了不少的進步。有興趣的讀者可以擴展閱讀這個Slide 另一個改進Reworking the GIL - 將切換顆粒度從基於opcode計數改成基於時間片計數- 避免最近一次釋放GIL鎖的線程再次被立即調度- 新增執行緒優先權功能（高優先權執行緒可以迫使其他執行緒釋放所持有的GIL鎖定）
總結
Python GIL其實是功能和效能之間權衡後的產物，它尤其存在的合理性，也有較難改變的客觀因素。從本分的分析中，我們可以做以下一些簡單的總結： - 因為GIL的存在，只有IO Bound場景下得多線程會得到較好的性能- 如果對並行計算性能較高的程序可以考慮把核心部分也成C模組，或索性用其他語言實現- GIL在較長一段時間內將會繼續存在，但是會不斷對其進行改進
Reference
Python's hardest problem Official documents about GIL Revisiting thread priorities and the new GIL
