一、異步IO
對于應用程序而言，有兩種類型的IO調用：即同步IO與異步IO。其本質的區(qū)別是：同步IO會block當前的調用線程，而異步IO則允許發(fā)起IO請求的調用線程繼續(xù)執(zhí)行，等到IO請求被處理后，會通知調用線程。在windows平臺上，應用程序可以調用CreateFile API, 并通過設置FILE_FLAG_OVERLAPPED標志來決定是否發(fā)起異步IO請求。
對于異步的IO請求，其最大的好處是：慢速的IO請求相對于應用程序而言是異步執(zhí)行，這樣可以極大提高應用程序的處理吞吐量。發(fā)起IO請求的應用程序需要關心的是IO執(zhí)行完成的結果，而不必忙等IO請求執(zhí)行的過程。
事實上，無論對于同步IO，還是異步IO,當IO請求發(fā)送到device driver后，device driver的執(zhí)行總是異步的,當它接到IO請求之后，總會馬上返回給IO System。而IO System是否立即返回給調用線程，則取決于FILE_FLAG_OVERLAPPED標志的設置,如下圖：
二、異步IO的同步問題。
我們使用異步IO，是為了提高應用程序的處理吞吐量。但是，當異步IO不再異步時（無論你是否設置FILE_FLAG_OVERLAPPED標志），應用程序的性能會受到極大的影響。根據(jù)Microsoft Knowledge Base 156932, 在下列幾種情況下，異步IO會失去它的異步性，而表現(xiàn)出同步的性質：
1）如果文件使用了NTFS compression壓縮，則system driver不會異步地存取這樣的文件。
2）擴展文件長度的IO操作不會是異步操作。
3）Cache機制。如果IO操作使用了file system cache，則這樣的IO操作會被當成同步IO,而非異步IO。
即使你使用了FILE_FLAG_OVERLAPPED標志。在這種情況下，
a.如果需要讀取的數(shù)據(jù)已經(jīng)在Cache里，那么I/O drivers會認為這樣的IO請求可以被立即處理，其結果是ReadFile 或者WriteFile調用返回TRUE，表示是：同步處理完成。
b.如果需要讀取的數(shù)據(jù)不在Cache里，windows NT的file system是使用page-faulting機制來實現(xiàn)cache管理，而page-faulting總是被同步處理， Windows NT沒有提供異步的page-faulting機制。的確， file system driver使用了線程池來緩解這一問題，但是，當應用程序發(fā)起的IO請求足夠多時，線程池還是不能應付的。
在我們開發(fā)基于異步IO應用程序時，應該避免上述問題的出現(xiàn)，因為它們會使程序的性能大打折扣。
那么，對于Cache,我們如何避免呢？答案是：請使用FILE_FLAG_NO_BUFFERING標志。這個標志會使異步IO真實地異步執(zhí)行。
三、性能的測試數(shù)據(jù)（僅供參考）。
我在我的機器上，簡單地對使用FILE_FLAG_NO_BUFFERING標志的異步IO,與不使用FILE_FLAG_NO_BUFFERING標志的異步IO進行了對比。
操作：順序讀取1G的文件。
x軸表示：每次讀取的字節(jié)數(shù)（單位：K/每次）
Y軸表示：讀取完成所需要的時間。（單位：millisecond)
注意：每次測試讀取的內容總數(shù)是相等的（1000M）。
例如：如果每次讀取128k,則需要讀取8000次(128k*8000 = 1000M)。
如果每次讀取256k,則需要讀取4000次(256k*4000 = 1000M)。
粉紅色的線沒有使用FILE_FLAG_NO_BUFFERING標志,而黃色的線使用了FILE_FLAG_NO_BUFFERING標志。
從以上的數(shù)據(jù),我們可以得出以下結論:
1) 當使用FILE_FLAG_NO_BUFFERING標志，應用程序的性能會極大提高，大概有50%的提高。
2）在使用異步IO的時候，還有一個注意的問題是：當你每次讀取的字節(jié)數(shù)增大的時候，性能也會提高。尤其在小于1024k時，當增大次讀取的字節(jié)數(shù)，性能都有明顯的提高。在混合了網(wǎng)絡傳輸?shù)葟碗s因素的應用程序開發(fā)過程中，建議將該值設置為可配置的參數(shù)，通過調整該參數(shù)，使你的應用達到最好的性能。
參考資料：
1） Microsoft Knowledge Base 156932
2) Microsoft Windows Internals, Fourth Edition.