python多線程、多進程以及GIL

標籤：生生   rom   force   設計   概念   樣本   oba   線程優先順序   sync   

多線程使用threading模組建立線程傳入一個函數

這種方式是最基本的，即調用threading中的Thread類的建構函式，然後指定參數target=func，再使用返回的Thread的執行個體調用start()方法，即開始運行該線程，該線程將執行函數func，當然，如果func需要參數，可以在Thread的建構函式中傳入參數args=(…)。範例程式碼如下

import threading#用於線程執行的函數def counter(n):    cnt = 0;    for i in xrange(n):        for j in xrange(i):            cnt += j;    print cnt;if __name__ == ‘__main__‘:    #初始化一個線程對象，傳入函數counter，及其參數1000    th = threading.Thread(target=counter, args=(1000,));    #啟動線程    th.start();    #主線程阻塞等待子線程結束    th.join();

傳入一個可調用的對象

許多的python 對象都是我們所說的可調用的，即是任何能通過函數操作符“（）”來調用的對象（見《python核心編程》第14章）。類的對象也是可以調用的，當被調用時會自動調用對象的內建方法call()，因此這種建立線程的方法就是給線程指定一個call方法被重載了的對象。範例程式碼如下：

import threading#可調用的類class Callable(object):    def __init__(self, func, args):        self.func = func;        self.args = args;    def __call__(self):        apply(self.func, self.args);#用於線程執行的函數def counter(n):    cnt = 0;    for i in xrange(n):        for j in xrange(i):            cnt += j;    print cnt;if __name__ == ‘__main__‘:    #初始化一個線程對象，傳入可調用的Callable對象，並用函數counter及其參數1000初始化這個對象    th = threading.Thread(target=Callable(counter, (1000,)));    #啟動線程    th.start();    #主線程阻塞等待子線程結束    th.join();

這個例子關鍵的一句是apply(self.func, self.args); 這裡使用初始化時傳入的函數對象及其參數來進行一次調用

繼承Thread類

這種方式通過繼承Thread類，並重載其run方法，來實現自訂的線程行為，範例程式碼如下：

import threading, time, randomdef counter():    cnt = 0;    for i in xrange(10000):        for j in xrange(i):            cnt += j;class SubThread(threading.Thread):    def __init__(self, name):        threading.Thread.__init__(self, name=name);    def run(self):        i = 0;        while i < 4:            print self.name,‘counting...\n‘;            counter();            print self.name,‘finish\n‘;            i += 1;if __name__ == ‘__main__‘:    th = SubThread(‘thread-1‘);    th.start();    th.join();    print ‘all done‘;

使用multiprocessing建立進程傳入一個函數

• 進程的建立方式跟線程完全一致，只不過要將threading.Thread換成multiprocessing.Process。multiprocessing模組儘力保持了與threading模組在方法名上的一致性，範例程式碼可參考上麵線程部分的。這裡只給出第一種使用函數的方式

import multiprocessing, timedef run():    i = 0;    while i<10000:        print ‘running‘;        time.sleep(2);        i += 1;if __name__ == ‘__main__‘:    p = multiprocessing.Process(target=run);    p.start();    #p.join();    print p.pid;    print ‘master gone‘;

建立進程池

• 該模組還允許一次建立一組進程，然後再給他們分配任務。詳細內容可參考手冊，這部分研究不多，不敢亂寫。

pool = multiprocessing.Pool(processes=4)pool.apply_async(func, args...)

使用進程的好處

• 完全並行，無GIL的限制，可充分利用多cpu多核的環境；可以接受linux訊號，後面將看到，這個功能非常好用

GIL

• python多線程有個討厭的限制，全域解譯器鎖（global interpreter lock），這個鎖的意思是任一時間只能有一個線程使用解譯器，跟單cpu跑多個程式一個意思，大家都是輪著用的，這叫“並發”，不是“並行”。
• 手冊上的解釋是為了保證物件模型的正確性！這個鎖造成的困擾是如果有一個計算密集型的線程佔著cpu，其他的線程都得等著….，試想你的多個線程中有這麼一個線程，得多悲劇，多線程生生被搞成串列；當然這個模組也不是毫無用處，
• 手冊上又說了：當用於IO密集型任務時，IO期間線程會釋放解譯器，這樣別的線程就有機會使用解譯器了！所以是否使用這個模組需要考慮面對的任務類型。

GIL是什麼

• 首先需要明確的一點是GIL並不是Python的特性，它是在實現Python解析器(CPython)時所引入的一個概念。
• 就好比C++是一套語言（文法）標準，但是可以用不同的編譯器來編譯成可執行代碼。有名的編譯器例如GCC，INTEL C++，Visual C++等。
• Python也一樣，同樣一段代碼可以通過CPython，PyPy，Psyco等不同的Python執行環境來執行。像其中的JPython就沒有GIL。
• 然而因為CPython是大部分環境下預設的Python執行環境。所以在很多人的概念裡CPython就是Python，也就想當然的把GIL歸結為Python語言的缺陷。
• 所以這裡要先明確一點：GIL並不是Python的特性，Python完全可以不依賴於GIL
• 那麼CPython實現中的GIL又是什麼呢？GIL全稱Global Interpreter Lock為了避免誤導，我們還是來看一下官方給出的解釋：

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.)

• 1

• 好吧，是不是看上去很糟糕？一個防止多線程並發執行機器碼的一個Mutex，乍一看就是個BUG般存在的全域鎖嘛！別急，我們下面慢慢的分析。

為什麼會有GIL

• 由於物理上得限制，各CPU廠商在核心頻率上的比賽已經被多核所取代。為了更有效利用多核處理器的效能，就出現了多線程的編程方式，而隨之帶來的就是線程間資料一致性和狀態同步的困難。即使在CPU內部的Cache也不例外，為了有效解決多份緩衝之間的資料同步時各廠商花費了不少心思，也不可避免的帶來了一定的效能損失。
• Python當然也逃不開，為了利用多核，Python開始支援多線程。而解決多線程之間資料完整性和狀態同步的最簡單方法自然就是加鎖。 於是有了GIL這把超級大鎖，而當越來越多的程式碼程式庫開發人員接受了這種設定後，他們開始大量依賴這種特性（即預設python內部對象是thread-safe的，無需在實現時考慮額外的記憶體鎖和同步操作）。
• 慢慢的這種實現方式被發現是蛋疼且低效的。但當大家試圖去拆分和去除GIL的時候，發現大量庫代碼開發人員已經重度依賴GIL而非常難以去除了。有多難？做個類比，像MySQL這樣的“小項目”為了把Buffer Pool Mutex這把大鎖拆分成各個小鎖也花了從5.5到5.6再到5.7多個大版為期近5年的時間，並且仍在繼續。MySQL這個背後有公司支援且有固定Team Dev的產品走的如此艱難，那又更何況Python這樣核心開發和代碼貢獻者高度社區化的團隊呢？
• 所以簡單的說GIL的存在更多的是曆史原因。如果推到重來，多線程的問題依然還是要面對，但是至少會比目前GIL這種方式會更優雅。

GIL的影響

• 從上文的介紹和官方的定義來看，GIL無疑就是一把全域獨佔鎖定。毫無疑問全域鎖的存在會對多線程的效率有不小影響。甚至就幾乎等於Python是個單線程的程式。 那麼讀者就會說了，全域鎖只要釋放的勤快效率也不會差啊。只要在進行耗時的IO操作的時候，能釋放GIL，這樣也還是可以提升運行效率的嘛。或者說再差也不會比單線程的效率差吧。理論上是這樣，而實際上呢？Python比你想的更糟。
• 下面我們就對比下Python在多線程和單線程下得效率對比。測試方法很簡單，一個迴圈1億次的計數器函數。一個通過單線程執行兩次，一個多線程執行。最後比較執行總時間。測試環境為雙核的Mac pro。註：為了減少線程庫本身效能損耗對測試結果帶來的影響，這裡單線程的代碼同樣使用了線程。只是順序的執行兩次，類比單線程

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

#! /usr/bin/pythonfrom threading import Threadimport timedef my_counter():    i = 0    for _ in range(100000000):        i = i + 1    return Truedef 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()

同時執行的兩個並發線程(multi_thread.py)

#! /usr/bin/pythonfrom threading import Threadimport timedef my_counter():    i = 0    for _ in range(100000000):        i = i + 1    return Truedef 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()

• 可以看到python在多線程的情況下居然比單線程整整慢了45%。按照之前的分析，即使是有GIL全域鎖的存在，序列化的多線程也應該和單線程有一樣的效率才對。那麼怎麼會有這麼糟糕的結果呢？
• 讓我們通過GIL的實現原理來分析這其中的原因。

當前GIL設計的缺陷基於pcode數量的調度方式

• 按照Python社區的想法，作業系統本身的線程調度已經非常成熟穩定了，沒有必要自己搞一套。所以Python的線程就是C語言的一個pthread，並通過作業系統調度演算法進行調度（例如linux是CFS）。為了讓各個線程能夠平均利用CPU時間，python會計算當前已執行的微代碼數量，達到一定閾值後就強制釋放GIL。而這時也會觸發一次作業系統的線程調度（當然是否真正進行環境切換由作業系統自主決定）
• 虛擬碼

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

• 這種模式在只有一個CPU核心的情況下毫無問題。任何一個線程被喚起時都能成功獲得到GIL（因為只有釋放了GIL才會引發線程調度）。但當CPU有多個核心的時候，問題就來了。從虛擬碼可以看到，從release GIL到acquire GIL之間幾乎是沒有間隙的。所以當其他在其他核心上的線程被喚醒時，大部分情況下主線程已經又再一次擷取到GIL了。這個時候被喚醒執行的線程只能白白的浪費CPU時間，看著另一個線程拿著GIL歡快的執行著。然後達到切換時間後進入待調度狀態，再被喚醒，再等待，以此往複惡性迴圈。
• PS：當然這種實現方式是原始而醜陋的，Python的每個版本中也在逐漸改進GIL和線程調度之間的互動關係。例如先嘗試持有GIL在做線程環境切換，在IO等待時釋放GIL等嘗試。但是無法改變的是GIL的存在使得作業系統線程調度的這個本來就昂貴的操作變得更奢侈了。 關於GIL影響的擴充閱讀
• 為了直觀的理解GIL對於多線程帶來的效能影響，這裡直接借用的一張測試結果圖（見）。圖中表示的是兩個線程在雙核CPU上得執行情況。兩個線程均為CPU密集型運算線程。綠色部分表示該線程在運行，且在執行有用的計算，紅色部分為線程被調度喚醒，但是無法擷取GIL導致無法進行有效運算等待的時間。
• 簡單的總結下就是：Python的多線程在多核CPU上，只對於IO密集型計算產生正面效果；而當有至少有一個CPU密集型線程存在，那麼多線程效率會由於GIL而大幅下降

如何避免受到GIL的影響

• 說了那麼多，如果不說解決方案就僅僅是個科普帖，然並卵。GIL這麼爛，有沒有辦法繞過呢？我們來看看有哪些現成的方案。

用multiprocessing替代Thread

• multiprocessing庫的出現很大程度上是為了彌補thread庫因為GIL而低效的缺陷。它完整的複製了一套thread所提供的介面方便遷移。唯一的不同就是它使用了多進程而不是多線程。每個進程有自己的獨立的GIL，因此也不會出現進程之間的GIL爭搶。
• 當然multiprocessing也不是萬能良藥。它的引入會增加程式實現時線程間資料通訊和同步的困難。就拿計數器來舉例子，如果我們要多個線程累加同一個變數，對於thread來說，申明一個global變數，用thread.Lock的context包裹住三行就搞定了。而multiprocessing由於進程之間無法看到對方的資料，只能通過在主線程申明一個Queue，put再get或者用share memory的方法。這個額外的實現成本使得本來就非常痛苦的多線程程式編碼，變得更加痛苦了。具體痛點在哪有興趣的讀者可以擴充閱讀這篇文章

用其他解析器

• 之前也提到了既然GIL只是CPython的產物，那麼其他解析器是不是更好呢？沒錯，像JPython和IronPython這樣的解析器由於實現語言的特性，他們不需要GIL的協助。然而由於用了Java/C#用於解析器實現，他們也失去了利用社區眾多C語言模組有用特性的機會。所以這些解析器也因此一直都比較小眾。畢竟功能和效能大家在初期都會選擇前者，Done is better than perfect

所以沒救了嗎？

• 當然Python社區也在非常努力的不斷改進GIL，甚至是嘗試去除GIL。並在各個小版本中有了不少的進步。有興趣的讀者可以擴充閱讀這個Slide 另一個改進Reworking the GIL - 將切換顆粒度從基於opcode計數改成基於時間片計數 - 避免最近一次釋放GIL鎖的線程再次被立即調度 - 新增線程優先順序功能（高優先順序線程可以迫使其他線程釋放所持有的GIL鎖）

總結

• Python GIL其實是功能和效能之間權衡後的產物，它尤其存在的合理性，也有較難改變的客觀因素。從本分的分析中，我們可以做以下一些簡單的總結： - 因為GIL的存在，只有IO Bound情境下得多線程會得到較好的效能 - 如果對並行計算效能較高的程式可以考慮把核心部分也成C模組，或者索性用其他語言實現 - GIL在較長一段時間內將會繼續存在，但是會不斷對其進行改進

python多線程、多進程以及GIL