前言：博主在剛接觸Python的時(shí)候時(shí)常聽(tīng)到GIL這個(gè)詞，并且發(fā)現(xiàn)這個(gè)詞經(jīng)常和Python無(wú)法高效的實(shí)現(xiàn)多線程劃上等號(hào)。本著不光要知其然，還要知其所以然的研究態(tài)度，博主搜集了各方面的資料，花了一周內(nèi)幾個(gè)小時(shí)的閑暇時(shí)間深入理解了下GIL，并歸納成此文，也希望讀者能通過(guò)次本文更好且客觀的理解GIL。

文章歡迎轉(zhuǎn)載，但轉(zhuǎn)載時(shí)請(qǐng)保留本段文字，并置于文章的頂部 作者：盧鈞軼(cenalulu) 本文原文地址：http://cenalulu.github.io/python/gil-in-python/

GIL是什么

首先需要明確的一點(diǎn)是GIL并不是Python的特性，它是在實(shí)現(xiàn)Python解析器(CPython)時(shí)所引入的一個(gè)概念。就好比C++是一套語(yǔ)言（語(yǔ)法）標(biāo)準(zhǔn)，但是可以用不同的編譯器來(lái)編譯成可執(zhí)行代碼。有名的編譯器例如GCC，INTEL C++，Visual C++等。Python也一樣，同樣一段代碼可以通過(guò)CPython，PyPy，Psyco等不同的Python執(zhí)行環(huán)境來(lái)執(zhí)行。像其中的JPython就沒(méi)有GIL。然而因?yàn)镃Python是大部分環(huán)境下默認(rèn)的Python執(zhí)行環(huán)境。所以在很多人的概念里CPython就是Python，也就想當(dāng)然的把GIL歸結(jié)為Python語(yǔ)言的缺陷。所以這里要先明確一點(diǎn)：GIL并不是Python的特性，Python完全可以不依賴于GIL

那么CPython實(shí)現(xiàn)中的GIL又是什么呢？GIL全稱Global Interpreter Lock為了避免誤導(dǎo)，我們還是來(lái)看一下官方給出的解釋：

In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

為什么會(huì)有GIL

由于物理上得限制，各CPU廠商在核心頻率上的比賽已經(jīng)被多核所取代。為了更有效的利用多核處理器的性能，就出現(xiàn)了多線程的編程方式，而隨之帶來(lái)的就是線程間數(shù)據(jù)一致性和狀態(tài)同步的困難。即使在CPU內(nèi)部的Cache也不例外，為了有效解決多份緩存之間的數(shù)據(jù)同步時(shí)各廠商花費(fèi)了不少心思，也不可避免的帶來(lái)了一定的性能損失。

Python當(dāng)然也逃不開(kāi)，為了利用多核，Python開(kāi)始支持多線程。而解決多線程之間數(shù)據(jù)完整性和狀態(tài)同步的最簡(jiǎn)單方法自然就是加鎖。 于是有了GIL這把超級(jí)大鎖，而當(dāng)越來(lái)越多的代碼庫(kù)開(kāi)發(fā)者接受了這種設(shè)定后，他們開(kāi)始大量依賴這種特性（即默認(rèn)python內(nèi)部對(duì)象是thread-safe的，無(wú)需在實(shí)現(xiàn)時(shí)考慮額外的內(nèi)存鎖和同步操作）。

慢慢的這種實(shí)現(xiàn)方式被發(fā)現(xiàn)是蛋疼且低效的。但當(dāng)大家試圖去拆分和去除GIL的時(shí)候，發(fā)現(xiàn)大量庫(kù)代碼開(kāi)發(fā)者已經(jīng)重度依賴GIL而非常難以去除了。有多難？做個(gè)類比，像MySQL這樣的“小項(xiàng)目”為了把Buffer Pool Mutex這把大鎖拆分成各個(gè)小鎖也花了從5.5到5.6再到5.7多個(gè)大版為期近5年的時(shí)間，并且仍在繼續(xù)。MySQL這個(gè)背后有公司支持且有固定開(kāi)發(fā)團(tuán)隊(duì)的產(chǎn)品走的如此艱難，那又更何況Python這樣核心開(kāi)發(fā)和代碼貢獻(xiàn)者高度社區(qū)化的團(tuán)隊(duì)呢？

所以簡(jiǎn)單的說(shuō)GIL的存在更多的是歷史原因。如果推到重來(lái)，多線程的問(wèn)題依然還是要面對(duì)，但是至少會(huì)比目前GIL這種方式會(huì)更優(yōu)雅。

GIL的影響

從上文的介紹和官方的定義來(lái)看，GIL無(wú)疑就是一把全局排他鎖。毫無(wú)疑問(wèn)全局鎖的存在會(huì)對(duì)多線程的效率有不小影響。甚至就幾乎等于Python是個(gè)單線程的程序。 那么讀者就會(huì)說(shuō)了，全局鎖只要釋放的勤快效率也不會(huì)差啊。只要在進(jìn)行耗時(shí)的IO操作的時(shí)候，能釋放GIL，這樣也還是可以提升運(yùn)行效率的嘛。或者說(shuō)再差也不會(huì)比單線程的效率差吧。理論上是這樣，而實(shí)際上呢？Python比你想的更糟。

下面我們就對(duì)比下Python在多線程和單線程下得效率對(duì)比。測(cè)試方法很簡(jiǎn)單，一個(gè)循環(huán)1億次的計(jì)數(shù)器函數(shù)。一個(gè)通過(guò)單線程執(zhí)行兩次，一個(gè)多線程執(zhí)行。最后比較執(zhí)行總時(shí)間。測(cè)試環(huán)境為雙核的Mac pro。注：為了減少線程庫(kù)本身性能損耗對(duì)測(cè)試結(jié)果帶來(lái)的影響，這里單線程的代碼同樣使用了線程。只是順序的執(zhí)行兩次，模擬單線程。

順序執(zhí)行的單線程(single_thread.py)

#! /usr/bin/python

from threading import Thread
import time

def my_counter():
    i = 0
    for _ in range(100000000):
        i = i + 1
    return True

def main():
    thread_array = {}
    start_time = time.time()
    for tid in range(2):
        t = Thread(target=my_counter)
        t.start()
        t.join()
    end_time = time.time()
    print("Total time: {}".format(end_time - start_time))

if __name__ == '__main__':
    main()

同時(shí)執(zhí)行的兩個(gè)并發(fā)線程(multi_thread.py)

#! /usr/bin/python

from threading import Thread
import time

def my_counter():
    i = 0
    for _ in range(100000000):
        i = i + 1
    return True

def main():
    thread_array = {}
    start_time = time.time()
    for tid in range(2):
        t = Thread(target=my_counter)
        t.start()
        thread_array[tid] = t
    for i in range(2):
        thread_array[i].join()
    end_time = time.time()
    print("Total time: {}".format(end_time - start_time))

if __name__ == '__main__':
    main()

下圖就是測(cè)試結(jié)果

可以看到python在多線程的情況下居然比單線程整整慢了45%。按照之前的分析，即使是有GIL全局鎖的存在，串行化的多線程也應(yīng)該和單線程有一樣的效率才對(duì)。那么怎么會(huì)有這么糟糕的結(jié)果呢？

讓我們通過(guò)GIL的實(shí)現(xiàn)原理來(lái)分析這其中的原因。

當(dāng)前GIL設(shè)計(jì)的缺陷

基于pcode數(shù)量的調(diào)度方式

按照Python社區(qū)的想法，操作系統(tǒng)本身的線程調(diào)度已經(jīng)非常成熟穩(wěn)定了，沒(méi)有必要自己搞一套。所以Python的線程就是C語(yǔ)言的一個(gè)pthread，并通過(guò)操作系統(tǒng)調(diào)度算法進(jìn)行調(diào)度（例如linux是CFS）。為了讓各個(gè)線程能夠平均利用CPU時(shí)間，python會(huì)計(jì)算當(dāng)前已執(zhí)行的微代碼數(shù)量，達(dá)到一定閾值后就強(qiáng)制釋放GIL。而這時(shí)也會(huì)觸發(fā)一次操作系統(tǒng)的線程調(diào)度（當(dāng)然是否真正進(jìn)行上下文切換由操作系統(tǒng)自主決定）。

偽代碼

while True:
    acquire GIL
    for i in 1000:
        do something
    release GIL
    /* Give Operating System a chance to do thread scheduling */

這種模式在只有一個(gè)CPU核心的情況下毫無(wú)問(wèn)題。任何一個(gè)線程被喚起時(shí)都能成功獲得到GIL（因?yàn)橹挥嗅尫帕薌IL才會(huì)引發(fā)線程調(diào)度）。但當(dāng)CPU有多個(gè)核心的時(shí)候，問(wèn)題就來(lái)了。從偽代碼可以看到，從release GIL到acquire GIL之間幾乎是沒(méi)有間隙的。所以當(dāng)其他在其他核心上的線程被喚醒時(shí)，大部分情況下主線程已經(jīng)又再一次獲取到GIL了。這個(gè)時(shí)候被喚醒執(zhí)行的線程只能白白的浪費(fèi)CPU時(shí)間，看著另一個(gè)線程拿著GIL歡快的執(zhí)行著。然后達(dá)到切換時(shí)間后進(jìn)入待調(diào)度狀態(tài)，再被喚醒，再等待，以此往復(fù)惡性循環(huán)。

PS：當(dāng)然這種實(shí)現(xiàn)方式是原始而丑陋的，Python的每個(gè)版本中也在逐漸改進(jìn)GIL和線程調(diào)度之間的互動(dòng)關(guān)系。例如先嘗試持有GIL在做線程上下文切換，在IO等待時(shí)釋放GIL等嘗試。但是無(wú)法改變的是GIL的存在使得操作系統(tǒng)線程調(diào)度的這個(gè)本來(lái)就昂貴的操作變得更奢侈了。 關(guān)于GIL影響的擴(kuò)展閱讀

為了直觀的理解GIL對(duì)于多線程帶來(lái)的性能影響，這里直接借用的一張測(cè)試結(jié)果圖（見(jiàn)下圖）。圖中表示的是兩個(gè)線程在雙核CPU上得執(zhí)行情況。兩個(gè)線程均為CPU密集型運(yùn)算線程。綠色部分表示該線程在運(yùn)行，且在執(zhí)行有用的計(jì)算，紅色部分為線程被調(diào)度喚醒，但是無(wú)法獲取GIL導(dǎo)致無(wú)法進(jìn)行有效運(yùn)算等待的時(shí)間。

由圖可見(jiàn)，GIL的存在導(dǎo)致多線程無(wú)法很好的立即多核CPU的并發(fā)處理能力。

那么Python的IO密集型線程能否從多線程中受益呢？我們來(lái)看下面這張測(cè)試結(jié)果。顏色代表的含義和上圖一致。白色部分表示IO線程處于等待。可見(jiàn)，當(dāng)IO線程收到數(shù)據(jù)包引起終端切換后，仍然由于一個(gè)CPU密集型線程的存在，導(dǎo)致無(wú)法獲取GIL鎖，從而進(jìn)行無(wú)盡的循環(huán)等待。

簡(jiǎn)單的總結(jié)下就是：Python的多線程在多核CPU上，只對(duì)于IO密集型計(jì)算產(chǎn)生正面效果；而當(dāng)有至少有一個(gè)CPU密集型線程存在，那么多線程效率會(huì)由于GIL而大幅下降。

如何避免受到GIL的影響

說(shuō)了那么多，如果不說(shuō)解決方案就僅僅是個(gè)科普帖，然并卵。GIL這么爛，有沒(méi)有辦法繞過(guò)呢？我們來(lái)看看有哪些現(xiàn)成的方案。

用multiprocessing替代Thread

multiprocessing庫(kù)的出現(xiàn)很大程度上是為了彌補(bǔ)thread庫(kù)因?yàn)镚IL而低效的缺陷。它完整的復(fù)制了一套thread所提供的接口方便遷移。唯一的不同就是它使用了多進(jìn)程而不是多線程。每個(gè)進(jìn)程有自己的獨(dú)立的GIL，因此也不會(huì)出現(xiàn)進(jìn)程之間的GIL爭(zhēng)搶。

當(dāng)然multiprocessing也不是萬(wàn)能良藥。它的引入會(huì)增加程序?qū)崿F(xiàn)時(shí)線程間數(shù)據(jù)通訊和同步的困難。就拿計(jì)數(shù)器來(lái)舉例子，如果我們要多個(gè)線程累加同一個(gè)變量，對(duì)于thread來(lái)說(shuō)，申明一個(gè)global變量，用thread.Lock的context包裹住三行就搞定了。而multiprocessing由于進(jìn)程之間無(wú)法看到對(duì)方的數(shù)據(jù)，只能通過(guò)在主線程申明一個(gè)Queue，put再get或者用share memory的方法。這個(gè)額外的實(shí)現(xiàn)成本使得本來(lái)就非常痛苦的多線程程序編碼，變得更加痛苦了。具體難點(diǎn)在哪有興趣的讀者可以擴(kuò)展閱讀這篇文章

用其他解析器

之前也提到了既然GIL只是CPython的產(chǎn)物，那么其他解析器是不是更好呢？沒(méi)錯(cuò)，像JPython和IronPython這樣的解析器由于實(shí)現(xiàn)語(yǔ)言的特性，他們不需要GIL的幫助。然而由于用了Java/C#用于解析器實(shí)現(xiàn)，他們也失去了利用社區(qū)眾多C語(yǔ)言模塊有用特性的機(jī)會(huì)。所以這些解析器也因此一直都比較小眾。畢竟功能和性能大家在初期都會(huì)選擇前者，Done is better than perfect。

所以沒(méi)救了么？

當(dāng)然Python社區(qū)也在非常努力的不斷改進(jìn)GIL，甚至是嘗試去除GIL。并在各個(gè)小版本中有了不少的進(jìn)步。有興趣的讀者可以擴(kuò)展閱讀這個(gè)Slide 另一個(gè)改進(jìn)Reworking the GIL

• 將切換顆粒度從基于opcode計(jì)數(shù)改成基于時(shí)間片計(jì)數(shù)
• 避免最近一次釋放GIL鎖的線程再次被立即調(diào)度
• 新增線程優(yōu)先級(jí)功能（高優(yōu)先級(jí)線程可以迫使其他線程釋放所持有的GIL鎖）

總結(jié)

Python GIL其實(shí)是功能和性能之間權(quán)衡后的產(chǎn)物，它尤其存在的合理性，也有較難改變的客觀因素。從本分的分析中，我們可以做以下一些簡(jiǎn)單的總結(jié)：

• 因?yàn)镚IL的存在，只有IO Bound場(chǎng)景下得多線程會(huì)得到較好的性能
• 如果對(duì)并行計(jì)算性能較高的程序可以考慮把核心部分也成C模塊，或者索性用其他語(yǔ)言實(shí)現(xiàn)
• GIL在較長(zhǎng)一段時(shí)間內(nèi)將會(huì)繼續(xù)存在，但是會(huì)不斷對(duì)其進(jìn)行改進(jìn)

Reference

Python’s hardest problem Official documents about GIL Revisiting thread priorities and the new GIL