1.關鍵概念理解
-
同步：發起一個調用，得到結果才返回。
-
異步：調用發起後，調用直接返回；調用方主動詢問被調用方獲取結果，或被調用方通過回調函數。
-
阻塞：調用是指調用結果返回之前，當前線程會被掛起。調用線程只有在得到結果之後纔會返回。
-
非阻塞：調用指在不能立刻得到結果之前，該調用不會阻塞當前線程。
同步纔有阻塞和非阻塞之分；阻塞與非阻塞關乎如何對待事情產生的結果（阻塞：不等到想要的結果我就不走了）
2.明確進程狀態
理解進程的狀態轉換
-
就緒狀態 -> 運行狀態：處於就緒狀態的進程被調度後，獲得CPU資源（分派CPU時間片），於是進程由就緒狀態轉換爲運行狀態。
-
運行狀態 -> 就緒狀態：處於運行狀態的進程在時間片用完後，不得不讓出CPU，從而進程由運行狀態轉換爲就緒狀態。此外，在可剝奪的操作系統中，當有更高優先級的進程就
、 緒時，調度程度將正執行的進程轉換爲就緒狀態，讓更高優先級的進程執行。 -
運行狀態 -> 阻塞狀態：當進程請求某一資源（如外設）的使用和分配或等待某一事件的發生（如I/O操作的完成）時，它就從運行狀態轉換爲阻塞狀態。進程以系統調用的形式請求操作系統提供服務，這是一種特殊的、由運行用戶態程序調用操作系統內核過程的形式。
-
阻塞狀態 -> 就緒狀態：當進程等待的事件到來時，如I/O操作結束或中斷結束時，中斷處理程序必須把相應進程的狀態由阻塞狀態轉換爲就緒狀態。
小編推薦自己的Linux、C/C++技術交流羣:【960994558】整理了一些個人覺得比較好的學習書籍、視頻資料共享在裏面（包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK等等.），有需要的可以自行添加哦！~
3.從操作系統層面執行應用程序理解 IO 模型
阻塞IO模型：
-
簡介：進程會一直阻塞，直到數據拷貝完成應用程序調用一個IO函數，導致應用程序阻塞，等待數據準備好。
如果數據沒有準備好，一直等待….數據準備好了，從內核拷貝到用戶空間，IO函數返回成功指示。 我們 第一次接觸到的網絡編程都是從
listen()、send()、recv()等接口開始的。使用這些接口可以很方便的構建服務器 /客戶機的模型。 -
阻塞I/O模型圖：在調用recv()/recvfrom（）函數時，發生在內核中等待數據和複製數據的過程。
當調用recv()函數時，系統首先查是否有準備好的數據。如果數據沒有準備好，那麼系統就處於等待狀態。當數據準備好後，將數據從系統緩衝區複製到用戶空間，然後該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那麼此時recv()函數就會處於等待狀態。阻塞模式給網絡編程帶來了一個很大的問題，如在調用 send()的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網絡請求。這給多客戶機、多業務邏輯的網絡編程帶來了挑戰。這時，我們可能會選擇多線程的方式來解決這個問題。應對多客戶機的網絡應用，最簡單的解決方式是在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。具體使用多進程還是多線程，並沒有一個特定的模式。傳統意義上，進程的開銷要遠遠大於線程，所以，如果需要同時爲較多的客戶機提供服務，則不推薦使用多進程；如果單個服務執行體需要消耗較多的
CPU 資源，譬如需要進行大規模或長時間的數據運算或文件訪問，則進程較爲安全。
非阻塞IO模型
- 簡介：非阻塞IO通過進程反覆調用IO函數（多次系統調用，並馬上返回）；在數據拷貝的過程中，進程是阻塞的；
我們把一個SOCKET接口設置爲非阻塞就是告訴內核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數將不斷的測試數據是否已經準備好，如果沒有準備好，繼續測試，直到數據準備好爲止。在這個不斷測試的過程中，會大量的佔用CPU的時間。
IO複用模型：
- 簡介：IO multiplexing就是我們說的select，poll，epoll，有些地方也稱這種IO方式爲event driven
IO。select/epoll的好處就在於單個process就可以同時處理多個網絡連接的
IO。它的基本原理就是select，poll，epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程。
當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從kernel拷貝到用戶進程。所以，I/O 多路複用的特點是通過一種機制一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就可以返回。
異步IO模型
- 簡介：用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous
read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
4.區別IO多路複用中的select poll epoll
select
- int select (int n, fd_set *readfds, fd_set writefds, fd_setexceptfds, struct timeval *timeout); select 函數監視的文件描述符分3類，分別是writefds、readfds、和exceptfds。調用後select函數會阻塞，直到有描述符就緒（有數據 可讀、可寫、或者有except），或者超時（timeout指定等待時間，如果立即返回設爲null即可），函數返回。當select函數返回後，可以 通過遍歷fdset，來找到就緒的描述符
poll
- int poll (struct pollfd *fds, unsigned int nfds, int timeout); 不同與select使用三個位圖來表示三個fdset的方式，poll使用一個pollfd的指針實現。pollfd並沒有最大數量限制（但是數量過大後性能也是會下降）。 和select函數一樣，poll返回後，需要輪詢pollfd來獲取就緒的描述符。
epoll
-
epoll是通過事件的就緒通知方式，調用epoll_create創建實例，調用epoll_ctl添加或刪除監控的文件描述符，調用epoll_wait阻塞住，直到有就緒的文件描述符，通過epoll_event參數返回就緒狀態的文件描述符和事件。
-
epoll操作過程需要三個接口，分別如下： int epoll_create(int
size)；//創建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大 生成一個
epoll專用的文件描述符，其實是申請一個內核空間，用來存放想關注的 socket fd 上是否發生以及發生了什麼事件。 -
int epoll_ctl(int epfd, int op, int fd, struct epoll_event
*event)；控制某個 epoll 文件描述符上的事件：註冊、修改、刪除。其中參數 epfd 是 epoll_create() 創建 epoll 專用的文件描述符。 -
int epoll_wait(int epfd, struct epoll_event * events, int maxevents,
int timeout);等待 I/O 事件的發生；返回發生事件數。
參數說明：
epfd: 由 epoll_create() 生成的Epoll 專用的文件描述符；
epoll_event:用於回傳代處理事件的數組；
maxevents: 每次能處理的事件數；
timeout: 等待 I/O 事件發生的超時值；
區別總結
- select，poll實現需要自己不斷輪詢所有fd集合，直到設備就緒，期間可能要睡眠和喚醒多次交替。而epoll其實也需要調用epoll_wait不斷輪詢就緒鏈表，期間也可能多次睡眠和喚醒交替，但是它是設備就緒時，調用回調函數，把就緒fd放入就緒鏈表中，並喚醒在epoll_wait中進入睡眠的進程。雖然都要睡眠和交替，但是select和poll在“醒着”的時候要遍歷整個fd集合，而epoll在“醒着”的時候只要判斷一下就緒鏈表是否爲空就行了，這節省了大量的CPU時間。這就是回調機制帶來的性能提升。
- select，poll每次調用都要把fd集合從用戶態往內核態拷貝一次，epoll通過 mmap把內核空間和用戶空間映射到同一塊內存，省去了拷貝的操作。
應用舉例
- Tornado：
使用單線程的方式，避免線程切換的性能開銷，同時避免在使用一些函數接口時出現線程不安全的情況支持異步非阻塞網絡IO模型，避免主進程阻塞等待。
tornado 的 IOLoop 模塊 是異步機制的核心，它包含了一系列已經打開的文件描述符和每個描述符的處理器 （handlers）。這些 handlers 就是對 select， poll , epoll等的封裝。（所以本質上說是 IO 複用）
- Django
沒有用異步，通過使用多進程的WSGI server（比如uWSGI）來實現併發，這也是WSGI普遍的做法。