對GIL的一些理解

GIL：全局解釋器鎖

GIL設計理念與限制：

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

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

在python中使用都是操做系統級別的線程，linux中使用的pthread，window使用的是其原生線程。

從上面的概述中能夠直觀的看出py在同一時刻只能跑一個線程，這樣在跑多線程的狀況下，只有當線程獲取到全局解釋器鎖後才能運行，而全局解釋器鎖只有一個，所以即便在多核的狀況下也只能發揮出單核的功能。

那麼這樣看起來py不給力啊，GIL直接致使CPython不能利用物理多核的性能加速運行。那麼爲何會有這樣的設計？考慮到Guido van Rossum 在創造python的時候，上世紀90年代，多核cpu徹底屬於不可想象的，如今因爲硬件發展速度太快，程序編寫就要考慮用盡cpu的所有性能，不然就要被淘汰，那麼對於python一樣也要如此。

上面主要說的是這種設計的劣勢，下面再討論它的優點。

GIL的設計簡化了CPython的實現，使得對象模型，包括關鍵的內建類型如字典，都隱式能夠併發訪問。鎖住全局解釋器使得其比較容易的實現對多線程的支持，但也折損了多處理器主機的並行計算能力。

可是不論標準的，仍是第三方的擴展模塊，都被設計成在進行密集計算任務時釋放GIL。另外還有在作IO操做時，GIL老是被釋放。對全部面對內建的操做系統C代碼的程序來講，GIL會在這個IO調用以前被釋放，以容許其它的線程在等待這個IO的時候運行。若是是純計算的程序，沒有IO操做，解釋器會每隔100次或每隔必定時間15ms去釋放GIL。

這裏能夠理解爲IO密集型的python比計算密集型的程序更能利用多線程環境帶來的便利。

GIL對線程執行的影響：

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

1. 設置GIL

2. 切換到一個線程去執行

3. 運行代碼，這裏有兩種機制：

   • 指定數量的字節碼指令（100個）

   • 固定時間15ms線程主動讓出控制

4. 把線程設置爲睡眠狀態

5. 解鎖GIL

6. 再次重複以上步驟

考慮用盡cpu的性能，python的應對方法很簡單，在新的python3中依然有GIL，緣由大概有下幾點：

1. CPython的GIL本意是用來保護全部全局的解釋器和環境狀態變量的，若是去掉GIL，就須要更多的更細粒度的鎖對解釋器的衆多全局狀態進行保護。或者採用Lock-Free算法。不管採用哪種，要作到多線程安全都會比維繫一個GIL要可貴多。另外改動的仍是CPython的代碼樹及其各類第三方擴展也在依賴GIL。

2. 進一步說，有人作過測試將GIL去掉，加入更細粒度的鎖。可是實踐檢測對單線程來講，性能更低。只有利用的物理cpu到必定數目後，性能纔會比GIL版本好。且如今絕大部分的python程序都是單線程的。

3. 而後最重要的還在於如下幾個方面，簡單來講就是py不改，同樣能實現咱們的需求。

4. 自2.6引出的多進程標準庫mutilprocessing，讓多進程的python編寫簡化到相似多線程的程度，大大減輕GIL帶來的諸多不利。

5. 利用ctypes繞過GIL：ctypes可使py直接調用任意的C動態庫的導出函數。所要作的只是用ctypes寫python代碼便可。並且，ctypes會在調用C函數前釋放GIL。