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)

同時執行的兩個併發執行緒(multi_thread.py)