Python中的線程是操作系統的原生線程，Python虛擬機使用一個全局解釋器鎖（Global Interpreter Lock）來互斥線程對Python虛擬機的使用。為了支持多線程機制，一個基本的要求就是需要實現不同線程對共享資源訪問的互斥，所以引入了GIL。
GIL：在一個線程擁有了解釋器的訪問權之後，其他的所有線程都必須等待它釋放解釋器的訪問權，即使這些線程的下一條指令並不會互相影響。
在調用任何Python C API之前，要先獲得GIL
GIL缺點：多處理器退化為單處理器；優點：避免大量的加鎖解鎖操作.

2.3.1 GIL的早期設計

Python支持多線程，而解決多線程之間數據完整性和狀態同步的最簡單方法自然就是加鎖。 於是有了GIL這把超級大鎖，而當越來越多的代碼庫開發者接受了這種設定後，他們開始大量依賴這種特性（即默認python內部對象是thread-safe的，無需在實現時考慮額外的內存鎖和同步操作）。慢慢的這種實現方式被發現是蛋疼且低效的。但當大家試圖去拆分和去除GIL的時候，發現大量庫代碼開發者已經重度依賴GIL而非常難以去除了。有多難？做個類比，像MySQL這樣的“小項目”為了把Buffer Pool Mutex這把大鎖拆分成各個小鎖也花了從5.5到5.6再到5.7多個大版為期近5年的時間，並且仍在繼續。MySQL這個背後有公司支持且有固定開發團隊的產品走的如此艱難，那又更何況Python這樣核心開發和代碼貢獻者高度社區化的團隊呢？

2.3.2 GIL的影響

無論你啟多少個線程，你有多少個cpu, Python在執行一個進程的時候會淡定的在同一時刻只允許一個線程運行。
所以，python是無法利用多核CPU實現多線程的。
這樣，python對於計算密集型的任務開多線程的效率甚至不如串行(沒有大量切換)，但是，對於IO密集型的任務效率還是有顯著提升的。

所以對於GIL，既然不能反抗，那就學會去享受它吧！

同步鎖

鎖通常被用來實現對共享資源的同步訪問。為每一個共享資源創建一個Lock對象，當你需要訪問該資源時，調用acquire方法來獲取鎖對象（如果其它線程已經獲得了該鎖，則當前線程需等待其被釋放），待資源訪問完後，再調用release方法釋放鎖。

import threading

R=threading.Lock()

R.acquire()
‘‘‘
對公共數據的操作
‘‘‘
R.release()

所謂死鎖： 是指兩個或兩個以上的進程或線程在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。

在Python中為了支持在同一線程中多次請求同一資源，python提供了可重入鎖RLock。這個RLock內部維護著一個Lock和一個counter變量，counter記錄了acquire的次數，從而使得資源可以被多次require。直到一個線程所有的acquire都被release，其他的線程才能獲得資源。上面的例子如果使用RLock代替Lock，則不會發生死鎖。

Semaphore管理一個內置的計數器，
每當調用acquire()時內置計數器-1；
調用release() 時內置計數器+1；
計數器不能小於0；當計數器為0時，acquire()將阻塞線程直到其他線程調用release()。

實例：(同時只有5個線程可以獲得semaphore,即可以限制最大連接數為5)：

Lock與Rlock的區別

這兩種鎖的主要區別是：RLock允許在同一線程中被多次acquire。而Lock卻不允許這種情況。註意：如果使用RLock，那麽acquire和release必須成對出現，即調用了n次acquire，必須調用n次的release才能真正釋放所占用的瑣。

python thread模塊 鎖 同步鎖