Python多線程的實例分析

這篇文章給大家介紹Python多線程的實例分析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

為什么有人會說 Python 多線程是雞肋？知乎上有人提出這樣一個問題，在我們常識中，多進程、多線程都是通過并發的方式充分利用硬件資源提高程序的運行效率，怎么在 Python 中反而成了雞肋？

有同學可能知道答案，因為 Python 中臭名昭著的 GIL。

那么 GIL 是什么？為什么會有 GIL？多線程真的是雞肋嗎？ GIL 可以去掉嗎？帶著這些問題，我們一起往下看，同時需要你有一點點耐心。

多線程是不是雞肋，我們先做個實驗，實驗非常簡單，就是將數字 “1億” 遞減，減到 0 程序就終止，這個任務如果我們使用單線程來執行，完成時間會是多少？使用多線程又會是多少？show me the code

# 任務
def decrement(n):
    while n > 0:
        n -= 1

單線程

import time

start = time.time()
decrement(100000000)
cost = time.time() - start
>>> 6.541690826416016

在我的4核 CPU 計算機中，單線程所花的時間是 6.5 秒。可能有人會問，線程在哪里？其實任何程序運行時，默認都會有一個主線程在執行。（關于線程與進程這里不展開，我會單獨開一篇文章）

多線程

import threading

start = time.time()

t1 = threading.Thread(target=decrement, args=[50000000])
t2 = threading.Thread(target=decrement, args=[50000000])

t1.start() # 啟動線程，執行任務
t2.start() # 同上

t1.join() # 主線程阻塞，直到t1執行完成，主線程繼續往后執行
t2.join() # 同上

cost = time.time() - start

>>>6.85541033744812

創建兩個子線程 t1、t2，每個線程各執行 5 千萬次減操作，等兩個線程都執行完后，主線程終止程序運行。結果，兩個線程以合作的方式執行是 6.8 秒，反而變慢了。按理來說，兩個線程同時并行地運行在兩個 CPU 之上，時間應該減半才對，現在不減反增。

是什么原因導致多線程不快反慢的呢？

原因就在于 GIL ，在 Cpython 解釋器（Python語言的主流解釋器）中，有一把全局解釋鎖（Global Interpreter Lock），在解釋器解釋執行 Python 代碼時，先要得到這把鎖，意味著，任何時候只可能有一個線程在執行代碼，其它線程要想獲得 CPU 執行代碼指令，就必須先獲得這把鎖，如果鎖被其它線程占用了，那么該線程就只能等待，直到占有該鎖的線程釋放鎖才有執行代碼指令的可能。

 

因此，這也就是為什么兩個線程一起執行反而更加慢的原因，因為同一時刻，只有一個線程在運行，其它線程只能等待，即使是多核CPU，也沒辦法讓多個線程「并行」地同時執行代碼，只能是交替執行，因為多線程涉及到上線文切換、鎖機制處理（獲取鎖，釋放鎖等），所以，多線程執行不快反慢。

什么時候 GIL 被釋放呢？

當一個線程遇到 I/O 任務時，將釋放GIL。計算密集型（CPU-bound）線程執行 100 次解釋器的計步（ticks）時（計步可粗略看作 Python 虛擬機的指令），也會釋放 GIL。可以通過 sys.setcheckinterval()設置計步長度，sys.getcheckinterval() 查看計步長度。相比單線程，這些多是多線程帶來的額外開銷

CPython 解釋器為什么要這樣設計？

多線程是為了適應現代計算機硬件高速發展充分利用多核處理器的產物，通過多線程使得 CPU 資源可以被高效利用起來，Python 誕生于1991年，那時候硬件配置遠沒有今天這樣豪華，現在一臺普通服務器32核64G內存都不是什么司空見慣的事

但是多線程有個問題，怎么解決共享數據的同步、一致性問題，因為，對于多個線程訪問共享數據時，可能有兩個線程同時修改一個數據情況，如果沒有合適的機制保證數據的一致性，那么程序最終導致異常，所以，Python之父就搞了個全局的線程鎖，不管你數據有沒有同步問題，反正一刀切，上個全局鎖，保證數據安全。這也就是多線程雞肋的原因，因為它沒有細粒度的控制數據的安全，而是用一種簡單粗暴的方式來解決。

這種解決辦法放在90年代，其實是沒什么問題的，畢竟，那時候的硬件配置還很簡陋，單核 CPU 還是主流，多線程的應用場景也不多，大部分時候還是以單線程的方式運行，單線程不要涉及線程的上下文切換，效率反而比多線程更高（在多核環境下，不適用此規則）。所以，采用 GIL 的方式來保證數據的一致性和安全，未必不可取，至少在當時是一種成本很低的實現方式。

那么把 GIL 去掉可行嗎？

還真有人這么干多，但是結果令人失望，在1999年Greg Stein 和Mark Hammond 兩位哥們就創建了一個去掉 GIL 的 Python 分支，在所有可變數據結構上把 GIL 替換為更為細粒度的鎖。然而，做過了基準測試之后，去掉GIL的 Python 在單線程條件下執行效率將近慢了2倍。

Python之父表示：基于以上的考慮，去掉GIL沒有太大的價值而不必花太多精力。

關于Python多線程的實例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。