python全局解釋器鎖（GIL）

文章做者：盧鈞軼(cenalulu) 本文原文地址：http://cenalulu.github.io/python/gil-in-python/ ，對文章作了適當的修改，加入了一些本身的理解。

CPU-bound(計算密集型) 和I/O bound(I/O密集型)

計算密集型任務(CPU-bound) 的特色是要進行大量的計算，佔據着主要的任務，消耗CPU資源，一直處於滿負荷狀態。好比複雜的加減乘除、計算圓周率、對視頻進行高清解碼等等，全靠CPU的運算能力。這種計算密集型任務雖然也能夠用多任務完成，可是任務越多，花在任務切換的時間就越多，CPU執行任務的效率就越低，因此，要最高效地利用CPU，計算密集型任務同時進行的數量應當等於CPU的核心數。

計算密集型任務因爲主要消耗CPU資源，所以，代碼運行效率相當重要。Python這樣的腳本語言運行效率很低，徹底不適合計算密集型任務。對於計算密集型任務，最好用C語言編寫。

IO密集型任務(I/O bound)的特色是指磁盤IO、網絡IO佔主要的任務，CPU消耗不多，任務的大部分時間都在等待IO操做完成（由於IO的速度遠遠低於CPU和內存的速度）。

IO密集型任務執行期間，99%的時間都花在IO上，花在CPU上的時間不多，所以，用運行速度極快的C語言替換用Python這樣運行速度極低的腳本語言，徹底沒法提高運行效率。

對於IO密集型任務，任務越多，CPU效率越高，但也有一個限度。常見的大部分任務都是IO密集型任務，好比請求網頁、讀寫文件等。固然咱們在Python中能夠利用sleep達到IO密集型任務的目的。

對於IO密集型任務，最合適的語言就是開發效率最高（代碼量最少）的語言，腳本語言是首選，C語言最差。

什麼是GIL（Global Interpreter Lock）

首先須要明確的一點是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。

Python代碼的執行由Python 虛擬機(也叫解釋器主循環，CPython版本)來控制，Python 在設計之初就考慮到要在解釋器的主循環中，同時只有一個線程在執行，即在任意時刻，只有一個線程在解釋器中運行。對Python 虛擬機的訪問由全局解釋器鎖（GIL）來控制，正是這個鎖能保證同一時刻只有一個線程在運行。

在多線程環境中，Python 虛擬機按如下方式執行：

1. 設置GIL
2. 切換到一個線程去運行
3. 運行：
    a. 指定數量的字節碼指令，或者
    b. 線程主動讓出控制（能夠調用time.sleep(0)）
4. 把線程設置爲睡眠狀態
5. 解鎖GIL
6. 再次重複以上全部步驟

在調用外部代碼（如C/C++擴展函數）的時候，GIL 將會被鎖定，直到這個函數結束爲止（因爲在這期間沒有Python 的字節碼被運行，因此不會作線程切換）。

爲何會有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設計原理及缺陷

基於pcode數量的調度方式

按照Python社區的想法，操做系統自己的線程調度已經很是成熟穩定了，沒有必要本身搞一套。因此Python的線程就是C語言的一個pthread，並經過操做系統調度算法進行調度（例如linux是CFS）。爲了讓各個線程可以平均利用CPU時間，python會計算當前已執行的微代碼數量，達到必定閾值後就強制釋放GIL。而這時也會觸發一次操做系統的線程調度（固然是否真正進行上下文切換由操做系統自主決定）。

任何Python線程執行前，必須先得到GIL鎖，而後，每執行100條字節碼，解釋器就自動釋放GIL鎖，讓別的線程有機會執行。這個GIL全局鎖實際上把全部線程的執行代碼都給上了鎖，因此，多線程在Python中只能交替執行，即便100個線程跑在100核CPU上，也只能用到1個核。

僞代碼

while True:
    acquire GIL
    for i in 100:
        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的影響

用multiprocess替代Thread

multiprocess庫的出現很大程度上是爲了彌補thread庫由於GIL而低效的缺陷。它完整的複製了一套thread所提供的接口方便遷移。惟一的不一樣就是它使用了多進程而不是多線程。每一個進程有本身的獨立的GIL，所以也不會出現進程之間的GIL爭搶。

固然multiprocess也不是萬能良藥。它的引入會增長程序實現時線程間數據通信和同步的困難。就拿計數器來舉例子，若是咱們要多個線程累加同一個變量，對於thread來講，申明一個global變量，用thread.Lock的context包裹住三行就搞定了。而multiprocess因爲進程之間沒法看到對方的數據，只能經過在主線程申明一個Queue，put再get或者用share memory的方法。這個額外的實現成本使得原本就很是痛苦的多線程程序編碼，變得更加痛苦了。具體難點在哪有興趣的讀者能夠擴展閱讀這篇文章

用其餘解析器

以前也提到了既然GIL只是CPython的產物，那麼其餘解析器是否是更好呢？沒錯，像JPython和IronPython這樣的解析器因爲實現語言的特性，他們不須要GIL的幫助。然而因爲用了Java/C#用於解析器實現，他們也失去了利用社區衆多C語言模塊有用特性的機會。因此這些解析器也所以一直都比較小衆。畢竟功能和性能你們在初期都會選擇前者，Done is better than perfect。

總結

Python GIL實際上是功能和性能之間權衡後的產物，它尤爲存在的合理性，也有較難改變的客觀因素。從本分的分析中，咱們能夠作如下一些簡單的總結：

• • 由於GIL的存在，只有IO Bound場景下得多線程會獲得較好的性能
  • 若是對並行計算性能較高的程序能夠考慮把核心部分也成C模塊，或者索性用其餘語言實現
  • GIL在較長一段時間內將會繼續存在，可是會不斷對其進行改進