協程

協程，又稱微線程，纖程。英文名Coroutine。一句話說明什么是線程：協程是一種用戶態的輕量級線程。

協程擁有自己的寄存器上下文和棧。協程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，恢復先前保存的寄存器上下文和棧。因此：

協程能保留上一次調用時的狀態（即所有局部狀態的一個特定組合），每次過程重入時，就相當于進入上一次調用的狀態，換種說法：進入上一次離開時所處邏輯流的位置。

協程的好處：

無需線程上下文切換的開銷 無需原子操作鎖定及同步的開銷 '原子操作(atomic operation)是不需要synchronized'，所謂原子操作是指不會被線程調度機制打斷的操作；這種操作一旦開始，就一直運行到結束，中間不會有任何 context switch （切換到另一個線程）。原子操作可以是一個步驟，也可以是多個操作步驟，但是其順序是不可以被打亂，或者切割掉只執行部分。視作整體是原子性的核心。 方便切換控制流，簡化編程模型 高并發+高擴展性+低成本：一個CPU支持上萬的協程都不是問題。所以很適合用于高并發處理。

缺點：

無法利用多核資源：協程的本質是個單線程,它不能同時將 單個CPU 的多個核用上,協程需要和進程配合才能運行在多CPU上.當然我們日常所編寫的絕大部分應用都沒有這個必要，除非是cpu密集型應用。 進行阻塞（Blocking）操作（如IO時）會阻塞掉整個程序

使用yield實現協程操作例子

import timeimport queuedef 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(): # 生產者 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()

程序執行的結果為：

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

問題來了，現在之所以能夠實現多并發的效果，是因為每一個生產者沒有任何花時間的代碼,所以他根本沒有卡住，如果這個時候在生產者這里sleep（1），那么速度一下子就變慢了，來看下下面的函數

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每次來一個請求都經過函數來處理，但它是一個單線程的情況，假如說nginx請求home頁，因為nginx在后臺處理是單線程，單線程的情況下同事過來三次請求，那該怎么辦？肯定是一次次的串行的執行啊，但是我為了讓他實現感覺是并發的效果，我是不是該在各個協程之間實行切換啊，但什么時候切換呢？那么，我問你，如果從一個請求進來直接打印一個print，那么我會在這個地方立刻切換嗎？因為這里面沒有任何的阻塞，不會被卡主，所以不需要立刻切換。如果他需要干一件事，比如整個home花了5s鐘，單線程是串行的，即便是使用了協程，那它還是串行的，為了保證并發的效果，什么時候進行切換？應該time.sleep(5)這里切換到bbs請求，那么bbs如果也sleep呢？那它就切換到下一個login，那么就是這么的切換。怎么才能實現一個單線程下實現上面程序的并發效果呢？就一句話，遇到io操作就切換，協程之所以能處理大并發，其實就是把io操作給擠掉了，就是io操作就切換，也就是這個程序只有CPU在運算，所以速度很快！那么問題又來了切換完之后，那么什么時候在切換回去啊？也就是說，怎么實現程序自動監測io操作完成了？那么就看下一個知識點吧！

Greenlet

greenlet是一個用C實現的協程模塊，相比與python自帶的yield，它是一塊封裝好了的協程，可以使你在任意函數之間隨意切換，而不需把這個函數先聲明為generator。

from greenlet import greenletdef test1(): print(12) gr2.switch() # 切換到gr2 print(34) gr2.switch() # 切換到gr2def test2(): print(56) gr1.switch() # 切換到gr1 print(78)gr1 = greenlet(test1) # 啟動一個協程gr2 = greenlet(test2) #gr1.switch() # 切換到gr1

程序執行后的結果為：

12563478

Gevent

上面的greenlet為手動擋的自動切換，現在來看一下自動擋的自動切換Gevent，遇到IO就切換。

Gevent 是一個第三方庫，可以輕松通過gevent實現并發同步或異步編程，在gevent中用到的主要模式是Greenlet, 它是以C擴展模塊形式接入Python的輕量級協程。 Greenlet全部運行在主程序操作系統進程的內部，但它們被協作式地調度。

來看下非常簡單的協程切換小程序

import geventdef func1(): print(’033[31;1m李闖在跟海濤搞...033[0m’) gevent.sleep(2) # 模仿IO print(’033[31;1m李闖又回去跟繼續跟海濤搞...033[0m’)def func2(): print(’033[32;1m李闖切換到了跟海龍搞...033[0m’) gevent.sleep(1) print(’033[32;1m李闖搞完了海濤，回來繼續跟海龍搞...033[0m’)gevent.joinall([ gevent.spawn(func1), # spawn 啟動一個協程 gevent.spawn(func2),])

程序執行后的結果為：

李闖在跟海濤搞...李闖切換到了跟海龍搞...李闖搞完了海濤，回來繼續跟海龍搞...李闖又回去跟繼續跟海濤搞...

協程之爬蟲

現在利用協程來實現簡單的爬蟲

from gevent import monkey; monkey.patch_all() # 把當前程序的所有的io操作單獨給我做上標記import gevent # 協程模塊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([ # 利用協程大并發的爬取網頁 gevent.spawn(f, ’https://www.python.org/’), gevent.spawn(f, ’https://www.yahoo.com/’), gevent.spawn(f, ’https://github.com/’),])

程序執行的結果為：

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

協程之Socket

通過gevent實現單線程下的多socket并發

# socket_server #import sysimport socketimport timeimport geventfrom gevent import socket,monkeymonkey.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 socketHOST = ’HW-20180425SPSL’ # The remote hostPORT = 8001 # The same port as used by the servers = 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()

程序執行后的結果為：

socket_client.py

>>:lalaReceived b’lala’>>:

socket_server.py

recv: b’heihei’

論事件驅動和異步IO

通常，我們寫服務器處理模型的程序時，有以下幾種模型：（1）每收到一個請求，創建一個新的進程，來處理該請求；

（2）每收到一個請求，創建一個新的線程，來處理該請求；

（3）每收到一個請求，放入一個事件列表，讓主進程通過非阻塞I/O方式來處理請求

上面的幾種方式，各有千秋，

第（1）中方法，由于創建新的進程的開銷比較大，所以，會導致服務器性能比較差,但實現比較簡單。

第（2）種方式，由于要涉及到線程的同步，有可能會面臨死鎖等問題。

第（3）種方式，在寫應用程序代碼時，邏輯比前面兩種都復雜。

綜合考慮各方面因素，一般普遍認為第（3）種方式是大多數網絡服務器采用的方式

看圖說話講事件驅動模型

在UI編程中，常常要對鼠標點擊進行相應，首先如何獲得鼠標點擊呢？

方式一：創建一個線程，該線程一直循環檢測是否有鼠標點擊，那么這個方式有以下幾個缺點：

1. CPU資源浪費，可能鼠標點擊的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描鼠標點擊的接口是阻塞的呢？

2. 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描鼠標點擊，還要掃描鍵盤是否按下，由于掃描鼠標時被堵塞了，那么可能永遠不會去掃描鍵盤；

3. 如果一個循環需要掃描的設備非常多，這又會引來響應時間的問題；所以，該方式是非常不好的。

方式二：就是事件驅動模型

目前大部分的UI編程都是事件驅動模型，如很多UI平臺都會提供onClick()事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下：

1. 有一個事件（消息）隊列；

2. 鼠標按下時，往這個隊列中增加一個點擊事件（消息）；

3. 有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等；

4. 事件（消息）一般都各自保存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；

什么是事件驅動模型？

其實就是根據事件做出反應！

事件驅動編程是一種編程范式，這里程序的執行流由外部事件來決定。它的特點是包含一個事件循環，當外部事件發生時使用回調機制來觸發相應的處理。另外兩種常見的編程范式是（單線程）同步以及多線程編程。

讓我們用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。下圖展示了隨著時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經用灰色框標示出來了。

在單線程同步模型中，任務按照順序執行。如果某個任務因為I/O而阻塞，其他所有的任務都必須等待，直到它完成之后它們才能依次執行。這種明確的執行順序和串行化處理的行為是很容易推斷得出的。如果任務之間并沒有互相依賴的關系，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。

在多線程版本中，這3個任務分別在獨立的線程中執行。這些線程由操作系統來管理，在多處理器系統上可以并行處理，或者在單處理器系統上交錯執行。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續執行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。多線程程序更加難以推斷，因為這類程序不得不通過線程同步機制如鎖、可重入函數、線程局部存儲或者其他機制來處理線程安全問題，如果實現不當就會導致出現微妙且令人痛不欲生的bug。

在事件驅動版本的程序中，3個任務交錯執行，但仍然在一個單獨的線程控制中。當處理I/O或者其他昂貴的操作時，注冊一個回調到事件循環中，然后當I/O操作完成時繼續執行。回調描述了該如何處理某個事件。事件循環輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數。這種方式讓程序盡可能的得以執行而不需要用到額外的線程。事件驅動型程序比多線程程序更容易推斷出行為，因為程序員不需要關心線程安全問題。

當我們面對如下的環境時，事件驅動模型通常是一個好的選擇：

1、程序中有許多任務，而且…

2、任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）而且…

3、在等待事件到來時，某些任務會阻塞。

當應用程序需要在任務間共享可變的數據時，這也是一個不錯的選擇，因為這里不需要采用同步處理。

網絡應用程序通常都有上述這些特點，這使得它們能夠很好的契合事件驅動編程模型。

此處要提出一個問題，就是，上面的事件驅動模型中，只要一遇到IO就注冊一個事件，然后主程序就可以繼續干其它的事情了，只到io處理完畢后，繼續恢復之前中斷的任務，這本質上是怎么實現的呢？哈哈，下面我們就來一起揭開這神秘的面紗。。。。

請看詳解Python IO口多路復用這篇文章

以上就是淺談Python協程的詳細內容，更多關于Python協程的資料請關注好吧啦網其它相關文章！