CPU-bound(計(jì)算密集型) 和I/O bound(I/O密集型)

計(jì)算密集型任務(wù)(CPU-bound) 的特點(diǎn)是要進(jìn)行大量的計(jì)算，占據(jù)著主要的任務(wù)，消耗CPU資源，一直處于滿負(fù)荷狀態(tài)。比如復(fù)雜的加減乘除、計(jì)算圓周率、對(duì)視頻進(jìn)行高清解碼等等，全靠CPU的運(yùn)算能力。這種計(jì)算密集型任務(wù)雖然也可以用多任務(wù)完成，但是任務(wù)越多，花在任務(wù)切換的時(shí)間就越多，CPU執(zhí)行任務(wù)的效率就越低，所以，要最高效地利用CPU，計(jì)算密集型任務(wù)同時(shí)進(jìn)行的數(shù)量應(yīng)當(dāng)?shù)扔贑PU的核心數(shù)。

計(jì)算密集型任務(wù)由于主要消耗CPU資源，因此，代碼運(yùn)行效率至關(guān)重要。Python這樣的腳本語(yǔ)言運(yùn)行效率很低，完全不適合計(jì)算密集型任務(wù)。對(duì)于計(jì)算密集型任務(wù)，最好用C語(yǔ)言編寫。

IO密集型任務(wù)(I/O bound)的特點(diǎn)是指磁盤IO、網(wǎng)絡(luò)IO占主要的任務(wù)，CPU消耗很少，任務(wù)的大部分時(shí)間都在等待IO操作完成（因?yàn)镮O的速度遠(yuǎn)遠(yuǎn)低于CPU和內(nèi)存的速度）。

IO密集型任務(wù)執(zhí)行期間，99%的時(shí)間都花在IO上，花在CPU上的時(shí)間很少，因此，用運(yùn)行速度極快的C語(yǔ)言替換用Python這樣運(yùn)行速度極低的腳本語(yǔ)言，完全無法提升運(yùn)行效率。

對(duì)于IO密集型任務(wù)，任務(wù)越多，CPU效率越高，但也有一個(gè)限度。常見的大部分任務(wù)都是IO密集型任務(wù)，比如請(qǐng)求網(wǎng)頁(yè)、讀寫文件等。當(dāng)然我們?cè)赑ython中可以利用sleep達(dá)到IO密集型任務(wù)的目的。

對(duì)于IO密集型任務(wù)，最合適的語(yǔ)言就是開發(fā)效率最高（代碼量最少）的語(yǔ)言，腳本語(yǔ)言是首選，C語(yǔ)言最差。

全局鎖問題：

解釋器被一個(gè)全局解釋器鎖保護(hù)著，它確保任何時(shí)候都只有一個(gè)Python線程執(zhí)行。

GIL最大的問題就是Python的多線程程序并不能利用多核CPU的優(yōu)勢(shì) （比如一個(gè)使用了多個(gè)線程的計(jì)算密集型程序只會(huì)在一個(gè)單CPU上面運(yùn)行）。

GIL只會(huì)影響到那些嚴(yán)重依賴CPU的程序（比如計(jì)算型的）

如果你的程序大部分只會(huì)設(shè)計(jì)到I/O，比如網(wǎng)絡(luò)交互，那么使用多線程就很合適， 因?yàn)樗鼈兇蟛糠謺r(shí)間都在等待。實(shí)際上，你完全可以放心的創(chuàng)建幾千個(gè)Python線程， 現(xiàn)代操作系統(tǒng)運(yùn)行這么多線程沒有任何壓力，沒啥可擔(dān)心的。

解決方案：

首先，如果你完全工作于Python環(huán)境中，你可以使用 multiprocessing 模塊來創(chuàng)建一個(gè)進(jìn)程池， 并像協(xié)同處理器一樣的使用它。

pool = None

# Performs a large calculation (CPU bound)
def some_work(args):
 ...
 return result

def some_thread():
 while True:
  ...
  r = pool.apply(some_work, (args))
  ...

# Initiaze the pool
if __name__ == '__main__':
 import multiprocessing
 pool = multiprocessing.Pool()

另外一個(gè)解決GIL的策略是使用C擴(kuò)展編程技術(shù)。 主要思想是將計(jì)算密集型任務(wù)轉(zhuǎn)移給C，跟Python獨(dú)立，在工作的時(shí)候在C代碼中釋放GIL。

以上這篇淺談Python中的全局鎖(GIL)問題就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論