阻塞IO（blocking IO）

在linux中，默認(rèn)情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：

當(dāng)用戶進(jìn)程調(diào)用了recvfrom這個系統(tǒng)調(diào)用，kernel內(nèi)核就開始了IO的第一個階段：準(zhǔn)備數(shù)據(jù)。對于network io( 網(wǎng)絡(luò)io )來說，很多時候數(shù)據(jù)在一開始還沒有到達(dá)（比如，還沒有收到一個完整的UDP包），這個時候kernel( 內(nèi)核 )就要等待足夠的數(shù)據(jù)到來。

等著對方把數(shù)據(jù)放到自己操作系統(tǒng)內(nèi)存

而在用戶進(jìn)程這邊，整個進(jìn)程會被阻塞。當(dāng)kernel一直等到數(shù)據(jù)準(zhǔn)備好了，它就會將數(shù)據(jù)從kernel操作系統(tǒng)緩存中拷貝到用戶應(yīng)用程序內(nèi)存，

然后kernel返回結(jié)果，用戶進(jìn)程才解除block的狀態(tài)，重新運(yùn)行起來。

這就是阻塞IO

所以，blocking IO的特點(diǎn)就是在IO執(zhí)行的兩個階段（等待數(shù)據(jù)和拷貝數(shù)據(jù)兩個階段）都被block了

網(wǎng)絡(luò)編程都是從listen\(\)、send\(\)、recv\(\) 等接口開始的，
使用這些接口可以很方便的構(gòu)建服務(wù)器/客戶機(jī)的模型。然而大部分的socket接口都是阻塞型的。如下圖

ps：

所謂阻塞型接口是指系統(tǒng)調(diào)用（一般是IO接口）不返回調(diào)用結(jié)果并讓當(dāng)前線程一直阻塞
只有當(dāng)該系統(tǒng)調(diào)用獲得結(jié)果或者超時出錯時才返回。

服務(wù)端：

            
from socket import *
server = socket(AF_INET,SOCK_STREAM)
server.bind(('127.0.0.1',8000))
server.listen(5)
while True:
  print("starting...")
  conn,addr = server.accept()
  print(addr)
  while True:
    try:
      data = conn.recv(1024)
      if not data:break
      conn.send(data.upper())
    except ConnectionResetError:
      break
server.close()
          

客戶端

            
from socket import *
client = socket(AF_INET,SOCK_STREAM)
client.connect(('127.0.0.1',8000))
while True:
  msg = input(">>>:").strip()
  if not msg:continue
  client.send(msg.encode("utf-8"))
  data = client.recv(1024)
  print(data.decode("utf-8"))
client.close()
          

實(shí)際上，除非特別指定，幾乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。這給網(wǎng)絡(luò)編程帶來了一個很大的問題，如在調(diào)用recv(1024)的同時，線程將被阻塞，在此期間，線程將無法執(zhí)行任何運(yùn)算或響應(yīng)任何的網(wǎng)絡(luò)請求。

一個簡單的解決方案：

在服務(wù)器端使用多線程（或多進(jìn)程）。多線程（或多進(jìn)程）的目的是讓每個連接都擁有獨(dú)立的線程（或進(jìn)程），
這樣任何一個連接的阻塞都不會影響其他的連接。

該方案的問題是 ：

開啟多進(jìn)程或都線程的方式，在遇到要同時響應(yīng)成百上千路的連接請求，則無論多線程還是多進(jìn)程都會嚴(yán)重占據(jù)系統(tǒng)資源，
降低系統(tǒng)對外界響應(yīng)效率，而且線程與進(jìn)程本身也更容易進(jìn)入假死狀態(tài)。
隨著客戶端數(shù)量增多，無限制的開線程，開銷非常大
不能解決阻塞IO問題 ，解決思路：起多線程

改進(jìn)方案：

使用“線程池”或“連接池”。“線程池”旨在減少創(chuàng)建和銷毀線程的頻率，
其維持一定合理數(shù)量的線程，并讓空閑的線程重新承擔(dān)新的執(zhí)行任務(wù)。“連接池”維持連接的緩存池，盡量重用已有的連接、
減少創(chuàng)建和關(guān)閉連接的頻率。這兩種技術(shù)都可以很好的降低系統(tǒng)開銷，都被廣泛應(yīng)用很多大型系統(tǒng)，如websphere、tomcat和各種數(shù)據(jù)庫等。

改進(jìn)后方案其實(shí)也存在著問題：

“線程池”和“連接池”技術(shù)也只是在一定程度上緩解了頻繁調(diào)用IO接口帶來的資源占用。而且，所謂“池”始終是有限，
當(dāng)請求大大超過上限時，“池”構(gòu)成的系統(tǒng)對外界的響應(yīng)并不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應(yīng)規(guī)模，

并根據(jù)響應(yīng)規(guī)模調(diào)整“池”的大小。

線程池應(yīng)該隨著規(guī)模數(shù)調(diào)大，但是調(diào)大線程池，要在機(jī)器可承受范圍之內(nèi)。不能把線程池?zé)o限調(diào)大，這樣相當(dāng)于無限開線程一樣，

多線程還是要用在規(guī)模比較小的情況

對應(yīng)上例中的所面臨的可能同時出現(xiàn)的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規(guī)模的服務(wù)請求，但面對大規(guī)模的服務(wù)請求，多線程模型也會遇到瓶頸，可以用非阻塞接口來嘗試解決這個問題。

總結(jié)：

始綜沒有解決單線程遇到IO問題，單線程遇到IO，就阻塞，用的是阻塞IO模型。

阻塞IO模型就是遇到IO阻塞不處理，就在原地等著。

應(yīng)該：

監(jiān)測單線程IO，遇到IO了，這個線程不要阻塞。直接切換到另外一個線程運(yùn)行，這樣單線程效率就非常高了。

要解決的問題是：

單線程IO問題

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。