超過十年以上，沒有比直譯器全域性鎖（GIL）讓Python新手和專家更有挫折感或者更有好奇心。
未解決的問題
隨處都是問題。難度大、耗時多肯定是其中一個問題。僅僅是嘗試解決這個問題就會讓人驚訝。之前是整個社群的嘗試，但現在只是外圍的開發人員在努力。對於新手，去嘗試解決這樣的問題，主要是因為問題難度足夠大，解決之後可以獲得相當的榮譽。電腦科學中未解決的 P = NP 就是這樣的問題。對此如果能給出多項式時間複雜度的答案，那簡直就可以改變世界了。Python最困難的問題比證明P = NP要容易一些，不過迄今仍然沒有一個滿意的解決，要知道，這個問題的實用的解決方案同樣能起著變革性的作用。正因為如此，很容易看到Python社群會有如此多的人關注於這樣的問題: "對於直譯器全域性鎖能做什麼?"
Python的底層
要理解GIL的含義，我們需要從Python的基礎講起。像C++這樣的語言是編譯型語言，所謂編譯型語言，是指程式輸入到編譯器，編譯器再根據語言的語法進行解析，然後翻譯成語言獨立的中間表示，最終連結成具有高度最佳化的機器碼的可執行程式。編譯器之所以可以深層次的對程式碼進行最佳化，是因為它可以看到整個程式（或者一大塊獨立的部分）。這使得它可以對不同的語言指令之間的互動進行推理，從而給出更有效的最佳化手段。
與此相反，Python是解釋型語言。程式被輸入到直譯器來執行。直譯器在程式執行之前對其並不瞭解；它所知道的只是Python的規則，以及在執行過程中怎樣去動態的應用這些規則。它也有一些最佳化，但是這基本上只是另一個級別的最佳化。由於直譯器沒法很好的對程式進行推導，Python的大部分最佳化其實是直譯器自身的最佳化。更快的直譯器自然意味著程式的執行也能“免費”的更快。也就是說，直譯器最佳化後，Python程式不用做修改就可以享受最佳化後的好處。
這一點很重要，讓我們再強調一下。如果其他條件不變，Python程式的執行速度直接與直譯器的“速度”相關。不管你怎樣最佳化自己的程式，你的程式的執行速度還是依賴於直譯器執行你的程式的效率。這就很明顯的解釋了為什麼我們需要對最佳化Python直譯器做這麼多的工作了。對於Python程式設計師來說，這恐怕是與免費午餐最接近的了。
免費午餐結束了
還是沒有結束？摩爾定律給出了硬體速度會按照確定的時間週期增長，與此同時，整整一代程式設計師學會了如何編碼。如果一個人寫了比較慢的程式碼，最簡單的結果通常是更快的處理器去等待程式碼的執行。顯然，摩爾定律仍然是正確的，並且還會在很長一段時間生效，不過它提及的方式有了根本的變化。並非是時脈頻率增長到一個高不可攀的速度，而是透過多核來利用電晶體密度提高帶來的好處。在新處理器上執行的程式要想充分利用其效能，必須按照併發方式進行重寫。
大部分開發者聽到“併發”通常會立刻想到多執行緒的程式。目前來說，多執行緒執行還是利用多核系統最常用的方式。儘管多執行緒程式設計大大好於“順序”程式設計，不過即便是仔細的程式設計師也沒法在程式碼中將併發性做到最好。程式語言在這方面應該做的更好，大部分應用廣泛的現代程式語言都會支援多執行緒程式設計。
意外的事實
現在我們來看一下問題的癥結所在。要想利用多核系統，Python必須支援多執行緒執行。作為解釋型語言，Python的直譯器必須做到既安全又高效。我們都知道多執行緒程式設計會遇到的問題。直譯器要留意的是避免在不同的執行緒操作內部共享的資料。同時它還要保證在管理使用者執行緒時保證總是有最大化的計算資源。
那麼，不同執行緒同時訪問時，資料的保護機制是怎樣的呢？答案是直譯器全域性鎖。從名字上看能告訴我們很多東西，很顯然，這是一個加在直譯器上的全域性（從直譯器的角度看）鎖（從互斥或者類似角度看）。這種方式當然很安全，但是它有一層隱含的意思（Python初學者需要了解這個）：對於任何Python程式，不管有多少的處理器，任何時候都總是隻有一個執行緒在執行。
許多人都是偶然發現這個事實的。網上的很多討論組和留言板都充斥著來自Python初學者和專家的類似這樣的問題——”為什麼我全新的多執行緒Python程式執行得比其只有一個執行緒的時候還要慢？“許多人在問這個問題時還是非常犯暈的，因為顯然一個具有兩個執行緒的程式要比其只有一個執行緒時要快（假設該程式確實是可並行的）。事實上，這個問題被問得如此頻繁以至於Python的專家們精心製作了一個標準答案：”不要使用多執行緒，請使用多程式。“但這個答案比那個問題更加讓人困惑。難道我不能在Python中使用多執行緒？在Python這樣流行的一個語言中使用多執行緒究竟是有多糟糕，連專家都建議不要使用。難道我真的漏掉了一些東西？
很遺憾，沒有任何東西被漏掉。由於Python直譯器的設計，使用多執行緒以提高效能應該算是一個困難的任務。在最壞的情況下，它將會降低（有時很明顯）你的程式的執行速度。一個電腦科學與技術專業的大學生新手可能會告訴你當多個執行緒都在競爭一個共享資源時將會發生什麼。結果通常不會非常理想。很多情況下多執行緒都能很好地工作，可能對於直譯器的實現和核心開發人員來說，沒有關於Python多執行緒效能的過多抱怨。
現在該怎麼辦？驚慌？
那麼，這又能怎樣？問題解決了嗎？難道我們作為Python開發人員就意味著要放棄使用多執行緒來探索並行的想法了？為什麼無論怎樣，GIL需要保證只有一個執行緒在某一時刻處於執行中？難道不可以新增細粒度的鎖來阻止多個獨立物件的同時訪問？並且為什麼之前沒有人去嘗試過類似的事情？
這些實用的問題有著十分有趣的回答。GIL對諸如當前執行緒狀態和為垃圾回收而用的堆分配物件這樣的東西的訪問提供著保護。然而，這對Python語言來說沒什麼特殊的，它需要使用一個GIL。這是該實現的一種典型產物。現在也有其它的Python直譯器（和編譯器）並不使用GIL。雖然，對於CPython來說，自其出現以來已經有很多不使用GIL的直譯器。
那麼為什麼不拋棄GIL呢？許多人也許不知道，在1999年，針對Python 1.5，一個經常被提到但卻不怎麼理解的“free threading”補丁已經嘗試實現了這個想法，該補丁來自Greg Stein。在這個補丁中，GIL被完全的移除，且用細粒度的鎖來代替。然而，GIL的移除給單執行緒程式的執行速度帶來了一定的代價。當用單執行緒執行時，速度大約降低了40%。使用兩個執行緒展示出了在速度上的提高，但除了這個提高，這個收益並沒有隨著核數的增加而線性增長。由於執行速度的降低，這一補丁被拒絕了，並且幾乎被人遺忘。
移除GIL非常困難，讓我們去購物吧！
不過，“free threading”這個補丁是有啟發性意義的，其證明了一個關於Python直譯器的基本要點：移除GIL是非常困難的。由於該補丁釋出時所處的年代，直譯器變得依賴更多的全域性狀態，這使得想要移除當今的GIL變得更加困難。值得一提的是，也正是因為這個原因，許多人對於嘗試移除GIL變得更加有興趣。困難的問題往往很有趣。
但是這可能有點被誤導了。讓我們考慮一下：如果我們有了一個神奇的補丁，其移除了GIL，並且沒有對單執行緒的Python程式碼產生效能上的下降，那麼什麼事情將會發生？我們將會獲得我們一直想要的：一個執行緒API可能會同時利用所有的處理器。那麼現在，我們已經獲得了我們希望的，但這確實是一個好事嗎？
基於執行緒的程式設計毫無疑問是困難的。每當某個人覺得他了解關於執行緒是如何工作的一切的時候，總是會悄無聲息的出現一些新的問題。因為在這方面想要得到正確合理的一致性真的是太難了，因此有一些非常知名的語言設計者和研究者已經總結得出了一些執行緒模型。就像某個寫過多執行緒應用的人可以告訴你的一樣，不管是多執行緒應用的開發還是除錯都會比單執行緒的應用難上數倍。程式設計師通常所具有的順序執行的思維模恰恰就是與並行執行模式不相匹配。GIL的出現無意中幫助了開發者免於陷入困境。在使用多執行緒時仍然需要同步原語的情況下，GIL事實上幫助我們保持不同執行緒之間的資料一致性問題。
那麼現在看起來討論Python最難得問題是有點問錯了問題。我們有非常好的理由來說明為什麼Python專家推薦我們使用多程式代替多執行緒，而不是去試圖隱藏Python執行緒實現的不足。更進一步，我們鼓勵開發者使用更安全更直接的方式實現併發模型，同時保留使用多執行緒進行開發除非你覺的真的非常必要的話。對於大多數人來說什麼是最好的並行程式設計模型可能並不是十分清楚。但是目前我們清楚的是多執行緒的方式可能並不是最好的。
至於GIL，不要認為它在那的存在就是靜態的和未經分析過的。Antoine Pitrou 在Python 3.2中實現了一個新的GIL，並且帶著一些積極的結果。這是自1992年以來，GIL的一次最主要改變。這個改變非常巨大，很難在這裡解釋清楚，但是從一個更高層次的角度來說，舊的GIL透過對Python指令進行計數來確定何時放棄GIL。這樣做的結果就是，單條Python指令將會包含大量的工作，即它們並沒有被1:1的翻譯成機器指令。在新的GIL實現中，用一個固定的超時時間來指示當前的執行緒以放棄這個鎖。在當前執行緒保持這個鎖，且當第二個執行緒請求這個鎖的時候，當前執行緒就會在5ms後被強制釋放掉這個鎖（這就是說，當前執行緒每5ms就要檢查其是否需要釋放這個鎖）。當任務是可行的時候，這會使得執行緒間的切換更加可預測。
然而，這並不是一個完美的改變。對於在各種型別的任務上有效利用GIL這個領域裡，最活躍的研究者可能就是David Beazley了。除了對Python 3.2之前的GIL研究最深入，他還研究了這個最新的GIL實現，並且發現了很多有趣的程式方案。對於這些程式，即使是新的GIL實現，其表現也相當糟糕。他目前仍然透過一些實際的研究和釋出一些實驗結果來引領並推進著有關GIL的討論。
不管某一個人對Python的GIL感覺如何，它仍然是Python語言裡最困難的技術挑戰。想要理解它的實現需要對作業系統設計、多執行緒程式設計、C語言、直譯器設計和CPython直譯器的實現有著非常徹底的理解。單是這些所需準備的就妨礙了很多開發者去更徹底的研究GIL。雖然如此，並沒有跡象表明GIL在不久以後的任何一段時間內會遠離我們。目前，它將繼續給那些新接觸Python，並且與此同時又對解決非常困難的技術問題感興趣的人帶來困惑和驚喜。
以上內容是基於我目前對Python直譯器所做出的研究而寫。雖然我還希望寫一些有關直譯器的其它方面內容，但是沒有任何一個比全域性直譯器鎖（GIL）更為人所知。雖然我認為這裡有些內容是不準確的，但是這些技術上的細節與CPython的很多資源條目是不同的。