「Python 中的 GIL 將不復存在，這是人工智能生態系統領域中的巨大勝利。」PyTorch 核心維護者 Dmytro Dzhulgakov 感慨道。

GIL 是什么？GIL 的全稱是 Global Interpreter Lock（全局解釋器鎖），它不是 Python 獨有的，而是在實現 CPython（Python 解釋器）時引入的一個概念。我們可以將 GIL 理解為一個互斥鎖，用來保護 Python 里的對象，防止同一時刻多個線程執行 Python 的字節碼，從而確保線程安全。

然而，GIL 存在一個弊端，即在同一時刻只能有一個線程在一個 CPU 上執行，無法將多個線程映射到多個 CPU 上，使得 Python 并不能實現真正的多線程并發，從而降低了執行效率。

現在，Python 團隊已經正式接受了刪除 GIL 的這個提議，并將其設置為可選模式，可謂是利好廣大開發者。

做出這一貢獻的是一位來自 Meta 的名叫 Sam Gross 的軟件工程師，他花費了四年多的時間才完成這一工程。

在得知這一消息后，大家紛紛叫好，深度學習三巨頭之一的 Yann LeCun 發文祝賀：沒有了 GIL，現在，Python 代碼可以自由的執行多線程了。

「Python 中終于沒有 GIL 了！」

「這是一個里程碑式的決定，是編碼社區所熱切期待的。」

具體細節如何，我們接著看下文。

CPython 核心開發者 Thomas Wouters 撰文描述了 Python 中的無 GIL 細節，并對未來發展做了展望。

非常感謝所有人對無 GIL 提議的反饋，整體上都持積極的支持態度。指導委員會打算接受無 GIL 提議，并就以下具體細節與大家分享。

我們的基本設想是：

• 長期來看（大約 5 年以上），no-GIL 構建應是唯一的構建；
• 我們希望非常謹慎地向后兼容。我們不希望出現另一個 Python 3 的情況，所有適應 no-GIL 構建所需的任何第三方代碼更改應只適用于 with-GIL 構建（盡管仍要解決更老 Python 版本的向后兼容性問題）。這不適用于 Python 4。我們仍在考慮對這兩個構建的 ABI 兼容性和其他細節的要求，以及對向后兼容性的影響；
• 在我們承諾完全轉向 no-GIL 之前，需要看到社區的支持。我們不能只是更改默認設置，更希望社區弄清自己需要做什么工作來給予支持。我們核心開發團隊需要獲得新構建模式及相關所有內容的經驗。我們要整理現有代碼中的線程安全性，因而需要弄明白新的 C API 和 Python API。我們在獲得這些洞見時還需要傳達給 Python 社區的其他人，并確保自身想要做出的更改以及希望他們做出的更改是可取的；
• 在我們默認 no-GIL 設置之前的任何時候，如果事實證明了，它的破壞性太大導致收益太少，我們希望能夠改變主意。這也就意味著我們會回滾所有工作，因此在我們確定要將 no-GIL 設為默認方式之前，特定于 no-GIL 的代碼在某種程度上應是可識別的。

目前，我們認為未來的道路分為以下三個階段：

• 短期內，我們會將 no-GIL 構建作為一種實驗性構建模式，大概是在 3.13 版本（也有可能推遲到 3.14 版本）。之所以是實驗性的，是因為我們核心開發團隊雖然支持這一構建模式，但不期望整個社區都會支持它。我們需要時間弄清自己要做什么，至少在 API 設計以及打包和分發方面，從而得到社區的支持。我們也不鼓勵 distributor 將實驗性 no-GIL 構建作為默認解釋器發布。
• 中期來看，在我們確信得到足夠的社區支持并使 no-GIL 的生產使用可行后，我們將支持 no-GIL 構建，但不是默認方式，而是在某個目標日期或某個 Python 版本中使它成為默認方式。具體的時間將取決于很多因素，比如 API 更改最終兼容性如何、社區認為他們仍然需要做多少工作等。我們預計這至少需要一至兩年的時間。一旦我們宣布支持，預計將有一些 distributor 會開始默認發布 no-GIL。
• 長期來看，我們希望 no-GIL 成為默認方式，并刪除 GIL 的所有痕跡（但不會不必要地破壞向后兼容性）。我們不希望等待太長時間，畢竟兩種常用的構建模式同時存在會給社區造成很大的負擔（比如需要雙倍測試資源和 debug 場景）。但是我們也不能急于求成。我們認為這一過程將需要花費五年的時間。

當然在整個過程中，我們整個開發團隊將需要實時評估進程并對時間線進行調整。