在io程式設計一節中，我們已經知道，cpu的速度遠遠快於磁碟、網路等io。在乙個執行緒中，cpu執行**的速度極快，然而，一旦遇到io操作，如讀寫檔案、傳送網路資料時，就需要等待io操作完成，才能繼續進行下一步操作。這種情況稱為同步io。
在io操作的過程中，當前執行緒被掛起，而其他需要cpu執行的**就無法被當前執行緒執行了。
因為乙個io操作就阻塞了當前執行緒，導致其他**無法執行，所以我們必須使用多執行緒或者多程序來併發執行**，為多個使用者服務。每個使用者都會分配乙個執行緒，如果遇到io導致執行緒被掛起，其他使用者的執行緒不受影響。
由於我們要解決的問題是cpu高速執行能力和io裝置的龜速嚴重不匹配，多執行緒和多程序只是解決這一問題的一種方法。
另一種解決io問題的方法是非同步io。當**需要執行乙個耗時的io操作時，它只發出io指令，並不等待io結果，然後就去執行其他**了。一段時間後，當io返回結果時，再通知cpu進行處理。
可以想象如果按普通順序寫出的**實際上是沒法完成非同步io的：
do_some_code()
f = open('/path/to/file', 'r')
r = f.read() # <== 執行緒停在此處等待io操作結果
# io操作完成後執行緒才能繼續執行:
do_some_code(r)
非同步io模型需要乙個訊息迴圈，在訊息迴圈中，主線程不斷地重複「讀取訊息-處理訊息」這一過程：
loop = get_event_loop()
while
true:
event = loop.get_event()
process_event(event)
由於gui執行緒處理鍵盤、滑鼠等訊息的速度非常快，所以使用者感覺不到延遲。某些時候，gui執行緒在乙個訊息處理的過程中遇到問題導致一次訊息處理時間過長，此時，使用者會感覺到整個gui程式停止響應了，敲鍵盤、點滑鼠都沒有反應。這種情況說明在訊息模型中，處理乙個訊息必須非常迅速，否則，主線程將無法及時處理訊息佇列中的其他訊息，導致程式看上去停止響應。
訊息模型是如何解決同步io必須等待io操作這一問題的呢？當遇到io操作時，**只負責發出io請求，不等待io結果，然後直接結束本輪訊息處理，進入下一輪訊息處理過程。當io操作完成後，將收到一條「io完成」的訊息，處理該訊息時就可以直接獲取io操作結果。
在「發出io請求」到收到「io完成」的這段時間裡，同步io模型下，主線程只能掛起，但非同步io模型下，主線程並沒有休息，而是在訊息迴圈中繼續處理其他訊息。這樣，在非同步io模型下，乙個執行緒就可以同時處理多個io請求，並且沒有切換執行緒的操作。對於大多數io密集型的應用程式，使用非同步io將大大提公升系統的多工處理能力。
IO模型 對阻塞 非阻塞，同步 非同步的理解
看乙個同學面經的時候看到這個問題，在unp 因此介紹的背景是socket程式設計 上找到了相應的內容介紹 unix下的io模型有五種 socket預設是blocking的，這種情況下，發出乙個系統呼叫，如果當前沒有資料可讀 如果呼叫read 那麼該程序會block直到有資料可讀，然後完成讀取，返回 ...
同步IO和非同步IO 簡單理解
在linux系統中，所有的裝置讀寫都可以看做是檔案的讀寫來進行操作，而對檔案的讀寫一般要經過核心態和使用者態的切換，因此io產生了同步和非同步。同步是阻塞模式，非同步是非阻塞模式。同步就是指乙個程序在執行某個請求的時內候，若該請求需容要一段時間才能返回資訊，那麼這個程序將會一直等待下去，直到收到返回...
掃盲 對非同步的理解
對於非同步的理解。之前對於同步方法和使用async await的非同步方法一直很迷惑。我覺得等待執行結果的非同步和同步方法有什麼區別嗎？他們的執行順序都是一樣的啊？不是都需要等待執行結果嗎？今天翻了一下 c 高階程式設計 才算搞清楚這裡面的差異，原來使用了async await的非同步是不會阻塞執行...