淺談Python協(xié)程
協(xié)程
協(xié)程,又稱微線程,纖程。英文名Coroutine。一句話說明什么是線程:協(xié)程是一種用戶態(tài)的輕量級線程。
協(xié)程擁有自己的寄存器上下文和棧。協(xié)程調(diào)度切換時,將寄存器上下文和棧保存到其他地方,在切回來的時候,恢復(fù)先前保存的寄存器上下文和棧。因此:
協(xié)程能保留上一次調(diào)用時的狀態(tài)(即所有局部狀態(tài)的一個特定組合),每次過程重入時,就相當(dāng)于進(jìn)入上一次調(diào)用的狀態(tài),換種說法:進(jìn)入上一次離開時所處邏輯流的位置。
協(xié)程的好處:
- 無需線程上下文切換的開銷
- 無需原子操作鎖定及同步的開銷
- "原子操作(atomic operation)是不需要synchronized",所謂原子操作是指不會被線程調(diào)度機制打斷的操作;這種操作一旦開始,就一直運行到結(jié)束,中間不會有任何 context switch (切換到另一個線程)。原子操作可以是一個步驟,也可以是多個操作步驟,但是其順序是不可以被打亂,或者切割掉只執(zhí)行部分。視作整體是原子性的核心。
- 方便切換控制流,簡化編程模型
- 高并發(fā)+高擴展性+低成本:一個CPU支持上萬的協(xié)程都不是問題。所以很適合用于高并發(fā)處理。
缺點:
- 無法利用多核資源:協(xié)程的本質(zhì)是個單線程,它不能同時將 單個CPU 的多個核用上,協(xié)程需要和進(jìn)程配合才能運行在多CPU上.當(dāng)然我們?nèi)粘K帉懙慕^大部分應(yīng)用都沒有這個必要,除非是cpu密集型應(yīng)用。
- 進(jìn)行阻塞(Blocking)操作(如IO時)會阻塞掉整個程序
使用yield實現(xiàn)協(xié)程操作例子
import time import queue def consumer(name): print("--->starting eating baozi...") while True: new_baozi = yield print("[%s] is eating baozi %s" % (name, new_baozi)) # time.sleep(1) def producer(): # 生產(chǎn)者 r = con.__next__() r = con2.__next__() n = 0 while n < 5: n += 1 con.send(n) con2.send(n) print("\033[32;1m[producer]\033[0m is making baozi %s" % n) if __name__ == '__main__': con = consumer("c1") con2 = consumer("c2") p = producer()
程序執(zhí)行的結(jié)果為:
--->starting eating baozi...
--->starting eating baozi...
[c1] is eating baozi 1
[c2] is eating baozi 1
[producer] is making baozi 1
[c1] is eating baozi 2
[c2] is eating baozi 2
[producer] is making baozi 2
[c1] is eating baozi 3
[c2] is eating baozi 3
[producer] is making baozi 3
[c1] is eating baozi 4
[c2] is eating baozi 4
[producer] is making baozi 4
[c1] is eating baozi 5
[c2] is eating baozi 5
[producer] is making baozi 5
問題來了,現(xiàn)在之所以能夠?qū)崿F(xiàn)多并發(fā)的效果,是因為每一個生產(chǎn)者沒有任何花時間的代碼,所以他根本沒有卡住,如果這個時候在生產(chǎn)者這里sleep(1),那么速度一下子就變慢了,來看下下面的函數(shù)
def home():
print("in func 1")
time.sleep(5)
print("home exec done")def bbs():
print("in func 2")
time.sleep(2)def login():
print("in func 2")
假如說nginx每次來一個請求都經(jīng)過函數(shù)來處理,但它是一個單線程的情況,假如說nginx請求home頁,因為nginx在后臺處理是單線程,單線程的情況下同事過來三次請求,那該怎么辦?肯定是一次次的串行的執(zhí)行啊,但是我為了讓他實現(xiàn)感覺是并發(fā)的效果,我是不是該在各個協(xié)程之間實行切換啊,但什么時候切換呢?那么,我問你,如果從一個請求進(jìn)來直接打印一個print,那么我會在這個地方立刻切換嗎?因為這里面沒有任何的阻塞,不會被卡主,所以不需要立刻切換。如果他需要干一件事,比如整個home花了5s鐘,單線程是串行的,即便是使用了協(xié)程,那它還是串行的,為了保證并發(fā)的效果,什么時候進(jìn)行切換?應(yīng)該time.sleep(5)這里切換到bbs請求,那么bbs如果也sleep呢?那它就切換到下一個login,那么就是這么的切換。怎么才能實現(xiàn)一個單線程下實現(xiàn)上面程序的并發(fā)效果呢?就一句話,遇到io操作就切換,協(xié)程之所以能處理大并發(fā),其實就是把io操作給擠掉了,就是io操作就切換,也就是這個程序只有CPU在運算,所以速度很快!那么問題又來了切換完之后,那么什么時候在切換回去???也就是說,怎么實現(xiàn)程序自動監(jiān)測io操作完成了?那么就看下一個知識點吧!
Greenlet
greenlet是一個用C實現(xiàn)的協(xié)程模塊,相比與python自帶的yield,它是一塊封裝好了的協(xié)程,可以使你在任意函數(shù)之間隨意切換,而不需把這個函數(shù)先聲明為generator。
from greenlet import greenlet def test1(): print(12) gr2.switch() # 切換到gr2 print(34) gr2.switch() # 切換到gr2 def test2(): print(56) gr1.switch() # 切換到gr1 print(78) gr1 = greenlet(test1) # 啟動一個協(xié)程 gr2 = greenlet(test2) # gr1.switch() # 切換到gr1
程序執(zhí)行后的結(jié)果為:
12
56
34
78
Gevent
上面的greenlet為手動擋的自動切換,現(xiàn)在來看一下自動擋的自動切換Gevent,遇到IO就切換。
Gevent 是一個第三方庫,可以輕松通過gevent實現(xiàn)并發(fā)同步或異步編程,在gevent中用到的主要模式是Greenlet, 它是以C擴展模塊形式接入Python的輕量級協(xié)程。 Greenlet全部運行在主程序操作系統(tǒng)進(jìn)程的內(nèi)部,但它們被協(xié)作式地調(diào)度。
來看下非常簡單的協(xié)程切換小程序
import gevent def func1(): print('\033[31;1m李闖在跟海濤搞...\033[0m') gevent.sleep(2) # 模仿IO print('\033[31;1m李闖又回去跟繼續(xù)跟海濤搞...\033[0m') def func2(): print('\033[32;1m李闖切換到了跟海龍搞...\033[0m') gevent.sleep(1) print('\033[32;1m李闖搞完了海濤,回來繼續(xù)跟海龍搞...\033[0m') gevent.joinall([ gevent.spawn(func1), # spawn 啟動一個協(xié)程 gevent.spawn(func2), ])
程序執(zhí)行后的結(jié)果為:
李闖在跟海濤搞...
李闖切換到了跟海龍搞...
李闖搞完了海濤,回來繼續(xù)跟海龍搞...
李闖又回去跟繼續(xù)跟海濤搞...
協(xié)程之爬蟲
現(xiàn)在利用協(xié)程來實現(xiàn)簡單的爬蟲
from gevent import monkey; monkey.patch_all() # 把當(dāng)前程序的所有的io操作單獨給我做上標(biāo)記 import gevent # 協(xié)程模塊 from urllib.request import urlopen # 爬蟲所需要的模塊 def f(url): print('GET: %s' % url) resp = urlopen(url) data = resp.read() print('%d bytes received from %s.' % (len(data), url)) gevent.joinall([ # 利用協(xié)程大并發(fā)的爬取網(wǎng)頁 gevent.spawn(f, 'https://www.python.org/'), gevent.spawn(f, 'https://www.yahoo.com/'), gevent.spawn(f, 'https://github.com/'), ])
程序執(zhí)行的結(jié)果為:
GET: https://www.python.org/
GET: https://www.yahoo.com/
GET: https://github.com/
59619 bytes received from https://github.com/.
495691 bytes received from https://www.yahoo.com/.
48834 bytes received from https://www.python.org/.
協(xié)程之Socket
通過gevent實現(xiàn)單線程下的多socket并發(fā)
# socket_server # import sys import socket import time import gevent from gevent import socket,monkey monkey.patch_all() def server(port): s = socket.socket() s.bind(('HW-20180425SPSL', port)) s.listen(500) while True: cli, addr = s.accept() gevent.spawn(handle_request, cli) def handle_request(conn): try: while True: data = conn.recv(1024) print("recv:", data) conn.send(data) if not data: conn.shutdown(socket.SHUT_WR) except Exception as ex: print(ex) finally: conn.close() if __name__ == '__main__': server(8001)
# socket_client # import socket HOST = 'HW-20180425SPSL' # The remote host PORT = 8001 # The same port as used by the server s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST, PORT)) while True: msg = bytes(input(">>:"),encoding="utf8") s.sendall(msg) data = s.recv(1024) #print(data) print('Received', repr(data)) s.close()
程序執(zhí)行后的結(jié)果為:
socket_client.py
>>:lala
Received b'lala'
>>:socket_server.py
recv: b'heihei'
論事件驅(qū)動和異步IO
通常,我們寫服務(wù)器處理模型的程序時,有以下幾種模型:
(1)每收到一個請求,創(chuàng)建一個新的進(jìn)程,來處理該請求;
(2)每收到一個請求,創(chuàng)建一個新的線程,來處理該請求;
(3)每收到一個請求,放入一個事件列表,讓主進(jìn)程通過非阻塞I/O方式來處理請求
上面的幾種方式,各有千秋,
第(1)中方法,由于創(chuàng)建新的進(jìn)程的開銷比較大,所以,會導(dǎo)致服務(wù)器性能比較差,但實現(xiàn)比較簡單。
第(2)種方式,由于要涉及到線程的同步,有可能會面臨死鎖等問題。
第(3)種方式,在寫應(yīng)用程序代碼時,邏輯比前面兩種都復(fù)雜。
綜合考慮各方面因素,一般普遍認(rèn)為第(3)種方式是大多數(shù)網(wǎng)絡(luò)服務(wù)器采用的方式
看圖說話講事件驅(qū)動模型
在UI編程中,常常要對鼠標(biāo)點擊進(jìn)行相應(yīng),首先如何獲得鼠標(biāo)點擊呢?
方式一:創(chuàng)建一個線程,該線程一直循環(huán)檢測是否有鼠標(biāo)點擊,那么這個方式有以下幾個缺點:
1. CPU資源浪費,可能鼠標(biāo)點擊的頻率非常小,但是掃描線程還是會一直循環(huán)檢測,這會造成很多的CPU資源浪費;如果掃描鼠標(biāo)點擊的接口是阻塞的呢?
2. 如果是堵塞的,又會出現(xiàn)下面這樣的問題,如果我們不但要掃描鼠標(biāo)點擊,還要掃描鍵盤是否按下,由于掃描鼠標(biāo)時被堵塞了,那么可能永遠(yuǎn)不會去掃描鍵盤;
3. 如果一個循環(huán)需要掃描的設(shè)備非常多,這又會引來響應(yīng)時間的問題;
所以,該方式是非常不好的。
方式二:就是事件驅(qū)動模型
目前大部分的UI編程都是事件驅(qū)動模型,如很多UI平臺都會提供onClick()事件,這個事件就代表鼠標(biāo)按下事件。事件驅(qū)動模型大體思路如下:
1. 有一個事件(消息)隊列;
2. 鼠標(biāo)按下時,往這個隊列中增加一個點擊事件(消息);
3. 有個循環(huán),不斷從隊列取出事件,根據(jù)不同的事件,調(diào)用不同的函數(shù),如onClick()、onKeyDown()等;
4. 事件(消息)一般都各自保存各自的處理函數(shù)指針,這樣,每個消息都有獨立的處理函數(shù);
什么是事件驅(qū)動模型?
其實就是根據(jù)事件做出反應(yīng)!
事件驅(qū)動編程是一種編程范式,這里程序的執(zhí)行流由外部事件來決定。它的特點是包含一個事件循環(huán),當(dāng)外部事件發(fā)生時使用回調(diào)機制來觸發(fā)相應(yīng)的處理。另外兩種常見的編程范式是(單線程)同步以及多線程編程。
讓我們用例子來比較和對比一下單線程、多線程以及事件驅(qū)動編程模型。下圖展示了隨著時間的推移,這三種模式下程序所做的工作。這個程序有3個任務(wù)需要完成,每個任務(wù)都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經(jīng)用灰色框標(biāo)示出來了。
在單線程同步模型中,任務(wù)按照順序執(zhí)行。如果某個任務(wù)因為I/O而阻塞,其他所有的任務(wù)都必須等待,直到它完成之后它們才能依次執(zhí)行。這種明確的執(zhí)行順序和串行化處理的行為是很容易推斷得出的。如果任務(wù)之間并沒有互相依賴的關(guān)系,但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。
在多線程版本中,這3個任務(wù)分別在獨立的線程中執(zhí)行。這些線程由操作系統(tǒng)來管理,在多處理器系統(tǒng)上可以并行處理,或者在單處理器系統(tǒng)上交錯執(zhí)行。這使得當(dāng)某個線程阻塞在某個資源的同時其他線程得以繼續(xù)執(zhí)行。與完成類似功能的同步程序相比,這種方式更有效率,但程序員必須寫代碼來保護(hù)共享資源,防止其被多個線程同時訪問。多線程程序更加難以推斷,因為這類程序不得不通過線程同步機制如鎖、可重入函數(shù)、線程局部存儲或者其他機制來處理線程安全問題,如果實現(xiàn)不當(dāng)就會導(dǎo)致出現(xiàn)微妙且令人痛不欲生的bug。
在事件驅(qū)動版本的程序中,3個任務(wù)交錯執(zhí)行,但仍然在一個單獨的線程控制中。當(dāng)處理I/O或者其他昂貴的操作時,注冊一個回調(diào)到事件循環(huán)中,然后當(dāng)I/O操作完成時繼續(xù)執(zhí)行?;卣{(diào)描述了該如何處理某個事件。事件循環(huán)輪詢所有的事件,當(dāng)事件到來時將它們分配給等待處理事件的回調(diào)函數(shù)。這種方式讓程序盡可能的得以執(zhí)行而不需要用到額外的線程。事件驅(qū)動型程序比多線程程序更容易推斷出行為,因為程序員不需要關(guān)心線程安全問題。
當(dāng)我們面對如下的環(huán)境時,事件驅(qū)動模型通常是一個好的選擇:
1、程序中有許多任務(wù),而且…
2、任務(wù)之間高度獨立(因此它們不需要互相通信,或者等待彼此)而且…
3、在等待事件到來時,某些任務(wù)會阻塞。
當(dāng)應(yīng)用程序需要在任務(wù)間共享可變的數(shù)據(jù)時,這也是一個不錯的選擇,因為這里不需要采用同步處理。
網(wǎng)絡(luò)應(yīng)用程序通常都有上述這些特點,這使得它們能夠很好的契合事件驅(qū)動編程模型。
此處要提出一個問題,就是,上面的事件驅(qū)動模型中,只要一遇到IO就注冊一個事件,然后主程序就可以繼續(xù)干其它的事情了,只到io處理完畢后,繼續(xù)恢復(fù)之前中斷的任務(wù),這本質(zhì)上是怎么實現(xiàn)的呢?哈哈,下面我們就來一起揭開這神秘的面紗。。。。
請看詳解Python IO口多路復(fù)用這篇文章
以上就是淺談Python協(xié)程的詳細(xì)內(nèi)容,更多關(guān)于Python協(xié)程的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Python報錯ImportError:?IProgress?not?found.?Please?update
在使用Jupyter Notebook或JupyterLab進(jìn)行交互式編程時,我們可能會遇到各種導(dǎo)入錯誤,本文就來介紹一下Python報錯ImportError:?IProgress?not?found.?Please?update?jupyter?and?ipywidgets解決,感興趣的可以了解一下2024-06-06Python+ChatGPT實現(xiàn)5分鐘快速上手編程
最近一段時間chatGPT火爆出圈!無論是在互聯(lián)網(wǎng)行業(yè),還是其他各行業(yè)都賺足了話題。俗話說:“外行看笑話,內(nèi)行看門道”,今天從chatGPT個人體驗感受以及如何用的角度來分享一下2023-02-02python-for x in range的用法(注意要點、細(xì)節(jié))
這篇文章主要介紹了python-for x in range的用法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-05-05python2.7的flask框架之引用js&css等靜態(tài)文件的實現(xiàn)方法
今天小編就為大家分享一篇python2.7的flask框架之引用js&css等靜態(tài)文件的實現(xiàn)方法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-08-08