協程

協程，又稱微執行緒，纖程。英文名Coroutine。一句話說明什麼是執行緒：協程是一種使用者態的輕量級執行緒。

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

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

協程的好處：

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

缺點：

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

使用yield實現協程操作例子

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(): # 生產者
 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），那麼速度一下子就變慢了，來看下下面的函式

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

假如說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 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) # 啟動一個協程
gr2 = greenlet(test2) #
gr1.switch() # 切換到gr1

程式執行後的結果為：

12
56
34
78

Gevent

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

Gevent 是一個第三方庫，可以輕鬆通過gevent實現併發同步或非同步程式設計，在gevent中用到的主要模式是Greenlet,它是以C擴充套件模組形式接入Python的輕量級協程。 Greenlet全部執行在主程式作業系統程序的內部，但它們被協作式地排程。

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

import gevent

def 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/'),'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 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()

程式執行後的結果為：

socket_client.py

>>:lala
Received 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協程的資料請關注我們其它相關文章！