我們知道，現在python呢已經成為了一個非常普及的編程語言了，同時呢也已經成為了tiobe統計排名第一的語言，超過了java和C/C++。
TIOBE 2023年9月編程語言排行榜
因為python確實學習門檻低，非常容易上手。現在幾乎所有人都會用python寫一些簡單的代碼，實現自己的需求。但是，如果沒有深入系統的學習python，也會掉進一些坑裡。今天我們就來聊一聊一個有關一個身邊985大學生掉進python 多線程GIL鎖坑裡的故事。
最近部門來了一個剛畢業的985研究生，人很聰明動手能力也很強，在組裡負責激光雷達相關的模塊開發。突然有一天，小伙找到我，說代碼里遇到了性能瓶頸問題，一直解決不了，很困惑。仔細了解後，知道了他在用python里的2個線程分別讀取2個激光雷達的數據然後做進一步分析處理，但發現其中一個線程的讀取效率特別低始終無法提高。這兩個線程是在同一個進程中創建的。顯然，精通python的人都知道，這裡是由於Python 進程中存在GIL鎖（也就是Global Interpreter Lock，即全局解釋器鎖）而導致的，所以我建議他改用多進程來規避這個問題，他照做之後問題得到解決。
小伙也可能是剛接觸python，現學現用，忽略了系統學習，所以導致了對GIL鎖缺乏了解，所以掉進了坑裡。可見，學習一門編程語言，系統的學習，抓住重點，打牢基礎是多麼重要，所謂磨刀不誤砍柴工。同時，勤學好問，也很重要，遇到問題要多向團隊里的人請教，當然，前提是這個團隊不內卷，和諧友好。
現在我們說回這個Pyhon中的GIL鎖。學習GIL鎖，起碼要搞清楚5個問題：1，什麼是GIL鎖；2，為什麼Python必須引入GIL鎖？3，GIL鎖什麼時候釋放？4，如何解決GIL鎖的性能問題？5，有了GIL鎖，還需要用額外的鎖嗎？
第一個問題：什麼是GIL鎖？
GIL鎖和在Python代碼中使用線程鎖Lock並不是一個層面的概念。GIL是在實現Python解釋器(CPython)時所引入的一個概念，每一個Python進程運行時都對應一個CPython解釋器進程。在CPython解釋器內部運行多個線程的時候，每個線程在解釋器內部申請相應的全局資源，為了防止資源競爭而發生錯誤，對所有線程申請全局資源增加了限制-必須獲得全局解釋器鎖GIL。每個線程想要運行首先獲取這個解釋器進程中唯一的GIL，因此Python進程中所有線程只能一個一個交替的執行。所以在Python程序里，就算使用多線程，運行在多核CPUS上，其實還是一個線程在工作，這是CPython的一個缺陷，其他語言沒有。
第二個問題：為什麼Python必須引入GIL？
Python調用的線程都是原生線程，通過C語言提供原生接口，相當於C語言的一個函數，一旦執行Python解釋器就再也不能控制它，必須等它返回結果。如果啟動n個線程，那麼這n個線程獨自執行，訪問全局資源，會造成資源競爭，結果就會有問題。CPython加入GIL，就可以在同一時間只有拿到GIL鎖的一個線程能夠工作。雖然這n個線程都啟動了，但是同一時間只能讓一個線程訪問全局數據，其他的幾個都只能等待。
第三個問題：GIL什麼時候釋放？
在當前線程執行超時後會自動釋放，python 3.x使用計時器（執行時間達到閾值後，當前線程釋放GIL）或Python 2.x，tickets計數達到100
在當前線程執行阻塞操作時會自動釋放，比如在IO操作等可能會引起阻塞的system call之前,可以暫時釋放GIL,但在執行完畢後,必須重新獲取GIL，因此多線程爬取比單線程性能有提升，因為遇到IO阻塞會自動釋放GIL鎖。
第四個問題：如何解決GIL鎖的性能問題？
多線程程序在進行IO等操作時的運行速度還是要比單線程速度快，但是在運行計算密集型的程序時，需要使用CPU進行大量的計算，但由於GIL鎖的性質導致程序執行中始終都是一個CPU進行計算，所以計算速度及其緩慢，運行此類的程序不推薦使用線程，有兩種方式解決：
1，使用多進程的方式，避免GIL鎖的約束；
2，使用其他運行速度較快的語言模塊，例如C語言。
第五個問題：既然存在GIL是否意味每個線程訪問全局數據就不用加Lock互斥鎖了呢？
用戶操作全局數據還是必須加Lock，因為GIL的釋放時機我們無法控制，此時對全局數據的操作很可能並沒有完成，而不像Lock那樣我們用完才釋放。
當然，python的GIL鎖一直被開發者詬病，python官方團隊也心知肚明，所以最近Python 團隊已經正式接受了刪除 GIL 的這個提議，並將其設置為可選模式。
深度學習三巨頭之一的 Yann LeCun 發文歡呼：沒有了 GIL，現在，Python 代碼可以自由的執行多線程了。
深度學習三巨頭之一的 Yann LeCun 發文祝賀
CPython 核心開發者 Thomas Wouters 撰文描述了 Python 中的無 GIL 細節，並對未來發展做了展望。短期內，會將 no-GIL 構建作為一種實驗性構建模式，大概會在 3.13 版本（也有可能推遲到 3.14 版本，目前官網的python版本是3.12版本）支持，比如允許用戶關閉GIL鎖，然後在未來某個版本將no-GIL設置為默認方式。長期來看，希望 no-GIL 成為默認方式，並刪除 GIL 的所有痕迹（但不會不必要地破壞向後兼容性）。所以，python實現真正多線程的那一天也許不會太遙遠了。
好，這次我們就聊到這裡，謝謝大家的觀看，下次再見
