Python之threading多線程 存在的意義

 

在群里經常聽到這樣的爭執，有人是虛心請教問題，有人就大放厥詞因為這個說python辣雞。而爭論的核心無非就是，python的多線程在同一時刻只會有一條線程跑在CPU里面，其他線程都在睡覺。這是真的嗎？

是真的。這個就是因為傳說中的GIL（全局解釋鎖）的存在。不明白這個詞的可以去百度一下，我解釋不好（大家都是程序猿你懂的，我寫錯一個詞就要挨噴了，就算我沒寫錯對方理解錯了，我也一樣要挨噴）。有了這樣一個看似bug的存在，就導致了上面說的情況：同一時刻內，python的線程只有一條在CPU里面運行。

所以python的多線程就沒用咯？當然不是。這要看程序是什么樣的。如果是一個計算為主的程序（專業一點稱為CPU密集型程序），這一點確實是比較吃虧的，每個線程運行一遍，就相當於單線程再跑，甚至比單線程還要慢——CPU切換線程的上下文也是要有開銷的。但是，如果是一個磁盤或網絡為主的程序（IO密集型）就不同了。一個線程處在IO等待的時候，另一個線程還可以在CPU里面跑，有時候CPU閑着沒事干，所有的線程都在等着IO，這時候他們就是同時的了，而單線程的話此時還是在一個一個等待的。我們都知道IO的速度比起CPU來是慢到令人發指的，python的多線程就在這時候發揮作用了。比方說多線程網絡傳輸，多線程往不同的目錄寫文件，等等。

話說回來，CPU密集型的程序用python來做，本身就不合適。跟C，Go，Java的速度比，實在性能差到沒法說。你當然可以寫個C擴展來實現真正的多線程，用python來調用，那樣速度是快。我們之所以用python來做，只是因為開發效率超高，可以快速實現。

最后補充幾點：

1. python中要想利用好CPU，還是用多進程來做吧。或者，可以使用協程。multiprocessing和gevent在召喚你。
2. GIL不是bug，Guido也不是水平有限才留下這么個東西。龜叔曾經說過，嘗試不用GIL而用其他的方式來做線程安全，結果python語言整體效率又下降了一倍，權衡利弊，GIL是最好的選擇——不是去不掉，而是故意留着的。
3. 想讓python計算速度快起來，又不想寫C？用pypy吧，這才是真正的大殺器。

 

 

map 函數一手包辦了序列操作、參數傳遞和結果保存等一系列的操作。

為什么這很重要呢？這是因為借助正確的庫，map 可以輕松實現並行化操作。

 

 

在 Python 中有個兩個庫包含了 map 函數： multiprocessing 和它鮮為人知的子庫 multiprocessing.dummy.

這里多扯兩句： multiprocessing.dummy？ mltiprocessing 庫的線程版克隆？這是蝦米？即便在 multiprocessing 庫的官方文檔里關於這一子庫也只有一句相關描述。而這句描述譯成人話基本就是說:”嘛，有這么個東西，你知道就成.”相信我，這個庫被嚴重低估了！

dummy 是 multiprocessing 模塊的完整克隆，唯一的不同在於 multiprocessing 作用於進程，而 dummy 模塊作用於線程（因此也包括了 Python 所有常見的多線程限制）。

所以替換使用這兩個庫異常容易。你可以針對 IO 密集型任務和 CPU 密集型任務來選擇不同的庫。2

動手嘗試

使用下面的兩行代碼來引用包含並行化 map 函數的庫：

1.  
   from multiprocessing import Pool
2.  
   from multiprocessing.dummy import Pool as ThreadPool

 

實例化 Pool 對象：

pool = ThreadPool()

 

 

這條簡單的語句替代了 example2.py 中 build_worker_pool 函數 7 行代碼的工作。它生成了一系列的 worker 線程並完成初始化工作、將它們儲存在變量中以方便訪問。

Pool 對象有一些參數，這里我所需要關注的只是它的第一個參數：processes. 這一參數用於設定線程池中的線程數。其默認值為當前機器 CPU 的核數。

一般來說，執行 CPU 密集型任務時，調用越多的核速度就越快。但是當處理網絡密集型任務時，事情有有些難以預計了，通過實驗來確定線程池的大小才是明智的。

pool = ThreadPool(4) # Sets the pool size to 4 

 

 

線程數過多時，切換線程所消耗的時間甚至會超過實際工作時間。對於不同的工作，通過嘗試來找到線程池大小的最優值是個不錯的主意。

創建好 Pool 對象后，並行化的程序便呼之欲出了。我們來看看改寫后的 example2.py

 

1.  
   import urllib2
2.  
   from multiprocessing.dummy import Pool as ThreadPool
3.  
    
4.  
   urls = [
5.  
   'http://www.python.org',
6.  
   'http://www.python.org/about/',
7.  
   'http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html',
8.  
   'http://www.python.org/doc/',
9.  
   'http://www.python.org/download/',
10.  
    'http://www.python.org/getit/',
11.  
    'http://www.python.org/community/',
12.  
    'https://wiki.python.org/moin/',
13.  
    'http://planet.python.org/',
14.  
    'https://wiki.python.org/moin/LocalUserGroups',
15.  
    'http://www.python.org/psf/',
16.  
    'http://docs.python.org/devguide/',
17.  
    'http://www.python.org/community/awards/'
18.  
    # etc..
19.  
    ]
20.  
     
21.  
    # Make the Pool of workers
22.  
    pool = ThreadPool( 4)
23.  
    # Open the urls in their own threads
24.  
    # and return the results
25.  
    results = pool.map(urllib2.urlopen, urls)
26.  
    #close the pool and wait for the work to finish
27.  
    pool.close()
28.  
    pool.join()

 

實際起作用的代碼只有 4 行，其中只有一行是關鍵的。map 函數輕而易舉的取代了前文中超過 40 行的例子。為了更有趣一些，我統計了不同方法、不同線程池大小的耗時情況。

1.  
   # results = []
2.  
   # for url in urls:
3.  
   # result = urllib2.urlopen(url)
4.  
   # results.append(result)
5.  
    
6.  
   # # ------- VERSUS ------- #
7.  
    
8.  
   # # ------- 4 Pool ------- #
9.  
   # pool = ThreadPool(4)
10.  
    # results = pool.map(urllib2.urlopen, urls)
11.  
     
12.  
    # # ------- 8 Pool ------- #
13.  
     
14.  
    # pool = ThreadPool(8)
15.  
    # results = pool.map(urllib2.urlopen, urls)
16.  
     
17.  
    # # ------- 13 Pool ------- #
18.  
     
19.  
    # pool = ThreadPool(13)
20.  
    # results = pool.map(urllib2.urlopen, urls)
21.  
     
22.  
    結果：
23.  
     
24.  
    # Single thread: 14.4 Seconds
25.  
    # 4 Pool: 3.1 Seconds
26.  
    # 8 Pool: 1.4 Seconds
27.  
    # 13 Pool: 1.3 Seconds

 

很棒的結果不是嗎？這一結果也說明了為什么要通過實驗來確定線程池的大小。在我的機器上當線程池大小大於 9 帶來的收益就十分有限了。

另一個真實的例子

生成上千張圖片的縮略圖

這是一個 CPU 密集型的任務，並且十分適合進行並行化。

基礎單進程版本

1.  
   import os
2.  
   import PIL
3.  
    
4.  
   from multiprocessing import Pool
5.  
   from PIL import Image
6.  
    
7.  
   SIZE = ( 75,75)
8.  
   SAVE_DIRECTORY = 'thumbs'
9.  
    
10.  
    def get_image_paths(folder):
11.  
    return (os.path.join(folder, f)
12.  
    for f in os.listdir(folder)
13.  
    if 'jpeg' in f)
14.  
     
15.  
    def create_thumbnail(filename):
16.  
    im = Image.open(filename)
17.  
    im.thumbnail(SIZE, Image.ANTIALIAS)
18.  
    base, fname = os.path.split(filename)
19.  
    save_path = os.path.join(base, SAVE_DIRECTORY, fname)
20.  
    im.save(save_path)
21.  
     
22.  
    if __name__ == '__main__':
23.  
    folder = os.path.abspath(
24.  
    '11_18_2013_R000_IQM_Big_Sur_Mon__e10d1958e7b766c3e840')
25.  
    os.mkdir(os.path.join(folder, SAVE_DIRECTORY))
26.  
     
27.  
    images = get_image_paths(folder)
28.  
     
29.  
    for image in images:
30.  
    create_thumbnail(Image)

 

上邊這段代碼的主要工作就是將遍歷傳入的文件夾中的圖片文件，一一生成縮略圖，並將這些縮略圖保存到特定文件夾中。

這我的機器上，用這一程序處理 6000 張圖片需要花費 27.9 秒。

如果我們使用 map 函數來代替 for 循環：

1.  
   import os
2.  
   import PIL
3.  
    
4.  
   from multiprocessing import Pool
5.  
   from PIL import Image
6.  
    
7.  
   SIZE = ( 75,75)
8.  
   SAVE_DIRECTORY = 'thumbs'
9.  
    
10.  
    def get_image_paths(folder):
11.  
    return (os.path.join(folder, f)
12.  
    for f in os.listdir(folder)
13.  
    if 'jpeg' in f)
14.  
     
15.  
    def create_thumbnail(filename):
16.  
    im = Image.open(filename)
17.  
    im.thumbnail(SIZE, Image.ANTIALIAS)
18.  
    base, fname = os.path.split(filename)
19.  
    save_path = os.path.join(base, SAVE_DIRECTORY, fname)
20.  
    im.save(save_path)
21.  
     
22.  
    if __name__ == '__main__':
23.  
    folder = os.path.abspath(
24.  
    '11_18_2013_R000_IQM_Big_Sur_Mon__e10d1958e7b766c3e840')
25.  
    os.mkdir(os.path.join(folder, SAVE_DIRECTORY))
26.  
     
27.  
    images = get_image_paths(folder)
28.  
     
29.  
    pool = Pool()
30.  
    pool.map(creat_thumbnail, images)
31.  
    pool.close()
32.  
    pool.join()

5.6 秒！

雖然只改動了幾行代碼，我們卻明顯提高了程序的執行速度。在生產環境中，我們可以為 CPU 密集型任務和 IO 密集型任務分別選擇多進程和多線程庫來進一步提高執行速度——這也是解決死鎖問題的良方。此外，由於 map 函數並不支持手動線程管理，反而使得相關的 debug 工作也變得異常簡單。

到這里，我們就實現了（基本）通過一行 Python 實現並行化。