6、併發並行與同步異步

併發並行

併發:是指系統具有處理多個任務(動作)的能力,通過CPU切換來完成併發效果;

並行:是指系統具有同時處理多個任務(動作)的能力,如果電腦有多個CPU那麼在同一時刻發生的任務就稱之為並行;

並行是併發的一個子集;

同步異步

同步:當進程到一個IO操作的時候(需要接收外部的數據的時候),如果要決定等那就是同步;

異步:當進程到一個IO操作的時候(需要接收外部的數據的時候),如果要決定不等那就是異步,自己去執行其他的任務,直到數據接受完成之後再回來處理;

異步效率更高,因為同步的等待是沒有意義的;

打電話就是類似一個同步的操作,打出電話要一直等待別人接聽,而發短信就相當於一個異步操作;

效率對比

傳統方式

#!/usr/bin/env python

# -*- coding: utf-8 -*-

# @Time : 2018/4/14 11:07

# @Author : CaiChangEn

# @Email : [email protected]

# @Software: PyCharm

import time,threading

def add():

sum=0

for i in range(1,100000):

sum+=i

print(sum)

def mul():

sum=1

for i in range(1,100000):

sum*=i

print(sum)

start=time.time()

add()

mul()

print('總共用時%s' %(time.time()-start))

# 結果

# 4999950000

# 282422940796034787429...

# 總共用時8.341477155685425

線程方式

#!/usr/bin/env python

# -*- coding: utf-8 -*-

# @Time : 2018/4/14 11:07

# @Author : CaiChangEn

# @Email : [email protected]

# @Software: PyCharm

import time,threading

def add():

sum=0

for i in range(1,100000):

sum+=i

print(sum)

def mul():

sum=1

for i in range(1,100000):

sum*=i

print(sum)

start=time.time()

t1=threading.Thread(target=add)

t2=threading.Thread(target=mul)

l=[]

l.append(t1)

l.append(t2)

for i in l:

i.start()

for i in l:

i.join()

print('總共用時%s' %(time.time()-start))

# 結果

# 4999950000

# 282422940796034787429...

# 總共用時8.40548062324524

結果

可以看出效果不是很明明顯,但是對python2.7版本的來講區別是非常大的,串行的比較快,因為使用多線程的情況下是使用多個CPU進行計算,多核因為GIL的原因是沒有用上的,GIL(全局解釋鎖);

GIL(全局解釋鎖)

Python本身就是一個解釋性的語言,在運行解釋器的過程中,為了線程安全加了一把鎖,而加了這把鎖就造成了一個結果就是在同一時刻只有一個線程在被運行,無論你啟多少個線程,有多少個cpu,python在執行的時候會淡定的在同一時刻只允許一個線程運行;

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

好吧,是不是看上去很糟糕?一個防止多線程併發執行機器碼的一個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這個背後有公司支持且有固定開發團隊的產品走的如此艱難,那又更何況Python這樣核心開發和代碼貢獻者高度社區化的團隊呢?

所以簡單的說GIL的存在更多的是歷史原因。如果推到重來,多線程的問題依然還是要面對,但是至少會比目前GIL這種方式會更優雅。

GIL的影響

從上文的介紹和官方的定義來看,GIL無疑就是一把全局排他鎖。毫無疑問全局鎖的存在會對多線程的效率有不小影響。甚至就幾乎等於Python是個單線程的程序。 那麼讀者就會說了,全局鎖只要釋放的勤快效率也不會差啊。只要在進行耗時的IO操作的時候,能釋放GIL,這樣也還是可以提升運行效率的嘛。或者說再差也不會比單線程的效率差吧。理論上是這樣,而實際上呢?Python比你想的更糟。

下面我們就對比下Python在多線程和單線程下得效率對比。測試方法很簡單,一個循環1億次的計數器函數。一個通過單線程執行兩次,一個多線程執行。最後比較執行總時間。測試環境為雙核的Mac pro。注:為了減少線程庫本身性能損耗對測試結果帶來的影響,這裡單線程的代碼同樣使用了線程。只是順序的執行兩次,模擬單線程。

詳解點擊此處

任務分類

IO密集型:在多線程的情況是有效果的,可以通過IO切換的時間來進行CPU動態分配,sleep等同於IO操作,因為此時我們的CPU是不工作的;

計算密集型:在多線程的情況是沒有效果的,只能通過CPU時間片來決定分配的任務;

結論

對於IO密集型的任務,我們Python的線程是有意義的,因為如何遇到IO操作的時候,CPU是不工作的,當CPU不工作的時候通過多線程的機制就會將CPU轉交給其他的線程,如果是計算密集型的任務多線程是沒有太大的意義的,因為此時的CPU是沒有休息間隔的,CPU會直接運行到CPU最大的時間片之後才會進行切換;

計算密集型的,Python就不推薦了

雖然進程切換消耗大,以及通信的問題,那麼以後我們可以通過協程來解決,它主要解決的問題也是IO密集型的;


分享到:


相關文章: