爲何在Python裏推薦使用多進程而不是多線程？

最近在看Python的多線程，常常咱們會聽到老手說：「Python下多線程是雞肋，推薦使用多進程！」，可是爲何這麼說呢？

要知其然，更要知其因此然。因此有了下面的深刻研究：

首先強調背景：
一、GIL是什麼？ GIL的全稱是Global Interpreter Lock(全局解釋器鎖)，來源是python設計之初的考慮，爲了數據安全所作的決定。
二、每一個CPU在同一時間只能執行一個線程（在單核CPU下的多線程其實都只是併發，不是並行，併發和並行從宏觀上來說都是同時處理多路請求的概念。但併發和並行又有區別，並行是指兩個或者多個事件在同一時刻發生；而併發是指兩個或多個事件在同一時間間隔內發生。）

在Python多線程下，每一個線程的執行方式： 一、獲取GIL 二、執行代碼直到sleep或者是python虛擬機將其掛起。 三、釋放GIL

可見，某個線程想要執行，必須先拿到GIL，咱們能夠把GIL看做是「通行證」，而且在一個python進程中，GIL只有一個。拿不到通行證的線程，就不容許進入CPU執行。

在Python2.x裏，GIL的釋放邏輯是當前線程碰見IO操做或者ticks計數達到100（ticks能夠看做是Python自身的一個計數器，專門作用於GIL，每次釋放後歸零，這個計數能夠經過 sys.setcheckinterval 來調整），進行釋放。

而每次釋放GIL鎖，線程進行鎖競爭、切換線程，會消耗資源。而且因爲GIL鎖存在，python裏一個進程永遠只能同時執行一個線程(拿到GIL的線程才能執行)，這就是爲何在多核CPU上，python的多線程效率並不高。

那麼是否是python的多線程就徹底沒用了呢？
在這裏咱們進行分類討論：
一、CPU密集型代碼(各類循環處理、計數等等)，在這種狀況下，因爲計算工做多，ticks計數很快就會達到閾值，而後觸發GIL的釋放與再競爭（多個線程來回切換固然是須要消耗資源的），因此python下的多線程對CPU密集型代碼並不友好。

二、IO密集型代碼(文件處理、網絡爬蟲等)，多線程可以有效提高效率(單線程下有IO操做會進行IO等待，形成沒必要要的時間浪費，而開啓多線程能在線程A等待時，自動切換到線程B，能夠不浪費CPU的資源，從而能提高程序執行效率)。因此python的多線程對IO密集型代碼比較友好。

而在python3.x中，GIL不使用ticks計數，改成使用計時器（執行時間達到閾值後，當前線程釋放GIL），這樣對CPU密集型程序更加友好，但依然沒有解決GIL致使的同一時間只能執行一個線程的問題，因此效率依然不盡如人意。

請注意：多核多線程比單核多線程更差，緣由是單核下多線程，每次釋放GIL，喚醒的那個線程都能獲取到GIL鎖，因此可以無縫執行，但多核下，CPU0釋放GIL後，其餘CPU上的線程都會進行競爭，但GIL可能會立刻又被CPU0拿到，致使其餘幾個CPU上被喚醒後的線程會醒着等待到切換時間後又進入待調度狀態，這樣會形成線程顛簸(thrashing)，致使效率更低

回到最開始的問題：常常咱們會聽到老手說：「python下想要充分利用多核CPU，就用多進程」，緣由是什麼呢？

緣由是：每一個進程有各自獨立的GIL，互不干擾，這樣就能夠真正意義上的並行執行，因此在python中，多進程的執行效率優於多線程(僅僅針對多核CPU而言)。

因此在這裏說結論：多核下，想作並行提高效率，比較通用的方法是使用多進程，可以有效提升執行效率