基礎概念 |
同步:ajax
所謂同步,就是在發出一個功能調用時,在沒有獲得結果以前,該調用就不返回。也就是必須一件一件事作,等前一件作完了才能作下一件事。數組
例如普通B/S模式(同步):提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能幹任何事。瀏覽器
異步:服務器
異步的概念和同步相對。當一個異步過程調用發出後,調用者不能馬上獲得結果。實際處理這個調用的部件在完成後,經過狀態、通知和回調來通知調用者。網絡
例如 ajax請求(異步): 請求經過事件觸發->服務器處理(這是瀏覽器仍然能夠做其餘事情)->處理完畢數據結構
阻塞:併發
阻塞調用是指調用結果返回以前,當前線程會被掛起(線程進入非可執行狀態,在這個狀態下,cpu不會給線程分配時間片,即線程暫停運行)。函數只有在獲得結果以後纔會返回。異步
有人也許會把阻塞調用和同步調用等同起來,實際上他是不一樣的。對於同步調用來講,不少時候當前線程仍是激活的,只是從邏輯上當前函數沒有返回而已。 例如,咱們在socket中調用recv函數,若是緩衝區中沒有數據,這個函數就會一直等待,直到有數據才返回。而此時,當前線程還會繼續處理各類各樣的消息socket
非阻塞:ide
非阻塞和阻塞的概念相對應,指在不能馬上獲得結果以前,該函數不會阻塞當前線程,而會馬上返回。
對象的阻塞模式和阻塞函數調用
對象是否處於阻塞模式和函數是否是阻塞調用有很強的相關性,可是並非一一對應的。阻塞對象上能夠有非阻塞的調用方式,咱們能夠經過必定的API去輪詢狀 態,在適當的時候調用阻塞函數,就能夠避免阻塞。而對於非阻塞對象,調用特殊的函數也能夠進入阻塞調用。函數select就是這樣的一個例子。
總結:
1. 同步,就是我調用一個功能,該功能沒有結束前,我死等結果。 2. 異步,就是我調用一個功能,不須要知道該功能結果,該功能有結果後通知我(回調通知) 3. 阻塞,就是調用我(函數),我(函數)沒有接收完數據或者沒有獲得結果以前,我不會返回 4. 非阻塞,就是調用我(函數),我(函數)當即返回,經過select通知調用者 |
同步IO和異步IO的區別就在於:數據拷貝的時候進程是否阻塞!
阻塞IO和非阻塞IO的區別就在於:應用程序的調用是否當即返回!
阻塞和非阻塞是指當進程訪問的數據若是還沒有就緒,進程是否須要等待,簡單說這至關於函數內部的實現區別,也就是未就緒時是直接返回仍是等待就緒;
而同步和異步是指訪問數據的機制,同步通常指主動請求並等待I/O操做完畢的方式,當數據就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數據後即可以繼續處理其它任務,隨後等待I/O,操做完畢的通知,這可使進程在數據讀寫時也不阻塞。(等待"通知")。
Linux下的五種I/O模型: |
l 阻塞I/O
l 非阻塞I/O
l I/O複用(select、poll、epoll)
l 信號驅動I/O(SIGIO)
l 異步I/O(Posix.1的aio_系列函數)
l 阻塞I/O模型
應用程序調用一個IO函數,致使應用程序阻塞,等待數據準備好。若是數據沒有準備好,一直等待。。。。數據準備好了,從內核拷貝到用戶空,IO函數返回成功指示。在這種模式下,基本上IO操做都會用一個Work Thread來進行(Java)。
l 非阻塞I/O模型
咱們把一個SOCKET接口設置爲非阻塞就是告訴內核,當所請求的I/O操做沒法完成時,不要將進程睡眠,而是返回一個錯誤。這樣咱們的I/O操做函數將不斷的測試數據是否已經準備好,若是沒有準備好,繼續測試,直到數據準備好爲止。在這個不斷測試的過程當中,會大量的佔用CPU的時間。
把SOCKET設置爲非阻塞模式,即通知系統內核:在調用Sockets API時,不要讓線程睡眠,而應該讓函數當即返回。在返回時,該函數返回一個錯誤代碼。圖所示,一個非阻塞模式套接字屢次調用recv()函數的過程。前三次調用recv()函數時,內核數據尚未準備好。所以,該函數當即返回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時,數據已經準備好,被複制到應用程序的緩衝區中,recv()函數返回成功指示,應用程序開始處理數據。
l I/O複用(select、poll、epoll)模型
I/O複用模型會用到select、poll、epoll函數,這幾個函數也會使進程阻塞,可是和阻塞I/O所不一樣的是,這兩個函數能夠同時阻塞多個I/O操做。並且能夠同時對多個讀操做,多個寫操做的I/O函數進行檢測,直到有數據可讀或可寫時,才真正調用I/O操做函數。
l 信號驅動I/O(SIGIO)模型
首先咱們容許SOCKET接口進行信號驅動I/O,並安裝一個信號處理函數,進程繼續運行並不阻塞。當數據準備好時,進程會收到一個SIGIO信號,能夠在信號處理函數中調用I/O操做函數處理數據。
l 異步I/O(Posix.1的aio_系列函數)模型
調用aio_read函數,告訴內核描述字,緩衝區指針,緩衝區大小,文件偏移以及通知的方式,而後當即返回。當內核將數據拷貝到緩衝區後,再通知應用程序。
這個操做和信號驅動的區別就是:異步模式等操做完畢後才通知用戶程序而信號驅動模式在數據到來時就通知用戶程序。
幾種I/O模型的比較
前四種模型的區別是第一階段,第二階段基本相同,都是將數據從內核拷貝到調用者的緩衝區。而異步I/O的兩個階段都不一樣於前四個模型。
Select、Poll、Epoll介紹 |
epoll跟select都能提供多路I/O複用的解決方案。在如今的Linux內核裏有都可以支持,其中epoll是Linux所特有,而select則應該是POSIX所規定,通常操做系統均有實現
select:
select本質上是經過設置或者檢查存放fd標誌位的數據結構來進行下一步處理。這樣所帶來的缺點是:
一、 單個進程可監視的fd數量被限制,即能監聽端口的大小有限。
通常來講這個數目和系統內存關係很大,具體數目能夠cat /proc/sys/fs/file-max察看。32位機默認是102個。64位機默認是2048.
二、 對socket進行掃描時是線性掃描,即採用輪詢的方法,效率較低:
當套接字比較多的時候,每次select()都要經過遍歷FD_SETSIZE個Socket來完成調度,無論哪一個Socket是活躍的,都遍歷一遍。這會浪費不少CPU時間。若是能給套接字註冊某個回調函數,當他們活躍時,自動完成相關操做,那就避免了輪詢,這正是epoll與kqueue作的。
三、須要維護一個用來存放大量fd的數據結構,這樣會使得用戶空間和內核空間在傳遞該結構時複製開銷大
poll:
poll本質上和select沒有區別,它將用戶傳入的數組拷貝到內核空間,而後查詢每一個fd對應的設備狀態,若是設備就緒則在設備等待隊列中加入一項並繼續遍歷,若是遍歷完全部fd後沒有發現就緒設備,則掛起當前進程,直到設備就緒或者主動超時,被喚醒後它又要再次遍歷fd。這個過程經歷了屢次無謂的遍歷。
它沒有最大鏈接數的限制,緣由是它是基於鏈表來存儲的,可是一樣有一個缺點:
一、大量的fd的數組被總體複製於用戶態和內核地址空間之間,而無論這樣的複製是否是有意義。 二、poll還有一個特色是「水平觸發」,若是報告了fd後,沒有被處理,那麼下次poll時會再次報告該fd。 |
epoll:
epoll支持水平觸發和邊緣觸發,最大的特色在於邊緣觸發,它只告訴進程哪些fd剛剛變爲就需態,而且只會通知一次。還有一個特色是,epoll使用「事件」的就緒通知方式,經過epoll_ctl註冊fd,一旦該fd就緒,內核就會採用相似callback的回調機制來激活該fd,epoll_wait即可以收到通知
epoll的優勢:
一、沒有最大併發鏈接的限制,能打開的FD的上限遠大於1024(1G的內存上能監聽約10萬個端口);
二、效率提高,不是輪詢的方式,不會隨着FD數目的增長效率降低。只有活躍可用的FD纔會調用callback函數;
即Epoll最大的優勢就在於它只管你「活躍」的鏈接,而跟鏈接總數無關,所以在實際的網絡環境中,Epoll的效率就會遠遠高於select和poll。
三、 內存拷貝,利用mmap()文件映射內存加速與內核空間的消息傳遞;即epoll使用mmap減小複製開銷。
select、poll、epoll 區別總結:
一、支持一個進程所能打開的最大鏈接數
Select |
單個進程所能打開的最大鏈接數有FD_SETSIZE宏定義,其大小是32個整數的大小(在32位的機器上,大小就是32*32,同理64位機器上FD_SETSIZE爲32*64),固然咱們能夠對進行修改,而後從新編譯內核,可是性能可能會受到影響,這須要進一步的測試。 |
Poll |
poll本質上和select沒有區別,可是它沒有最大鏈接數的限制,緣由是它是基於鏈表來存儲的 |
Epoll |
雖然鏈接數有上限,可是很大,1G內存的機器上能夠打開10萬左右的鏈接,2G內存的機器能夠打開20萬左右的鏈接 |
二、FD劇增後帶來的IO效率問題
Select |
由於每次調用時都會對鏈接進行線性遍歷,因此隨着FD的增長會形成遍歷速度慢的「線性降低性能問題」。 |
Poll |
同上 |
Epoll |
由於epoll內核中實現是根據每一個fd上的callback函數來實現的,只有活躍的socket纔會主動調用callback,因此在活躍socket較少的狀況下,使用epoll沒有前面二者的線性降低的性能問題,可是全部socket都很活躍的狀況下,可能會有性能問題。 |
三、 消息傳遞方式
Select |
內核須要將消息傳遞到用戶空間,都須要內核拷貝動做 |
Poll |
同上 |
Epoll |
epoll經過內核和用戶空間共享一塊內存來實現的。 |
總結:
綜上,在選擇select,poll,epoll時要根據具體的使用場合以及這三種方式的自身特色。
一、表面上看epoll的性能最好,可是在鏈接數少而且鏈接都十分活躍的狀況下,select和poll的性能可能比epoll好,畢竟epoll的通知機制須要不少函數回調。
二、select低效是由於每次它都須要輪詢。但低效也是相對的,視狀況而定,也可經過良好的設計改善。