前言

IO完成埠（IO completion ports）在多核電腦的並行非同步IO請求方面提供了一種高效的線程模型。當進程創建一個IO完成埠時，系統創建一個相關聯的隊列，其唯一目的是服務與那些請求。IO完成埠通常和預先分配的線程池配合，相比於一個一個創建線程，這使其更快更高效。IOCP在進程之間並不共用，一個IOCP及其句柄只和創建它的進程關聯，但是一個進程中的多個線程可共用。IOCP最關鍵的地方就是，IOCP在IO請求和接收動作完成之後，激活線程池中的任意線程繼續操作，而不是在IO請求和接受完成之後，激活原等待中的線程。這樣的好處是防止等待線程閑置，和必須激活／切換到原等待線程的開銷。

大多應用存在的問題

曾見過很多服務，幾台，幾十臺，幾百台伺服器的，它們cpu大多數時間處於空閑狀態，也許需要大量計算的應用並沒有那麼多，我們常見的應用大多主要讀寫關係資料庫，讀寫記憶體資料庫／緩存，RPC調用介面。IO耗時過多，CPU大量閑置，導致沒看到伺服器資源大量消耗，便已不能承受日益增加的訪問量，再加伺服器，依然大量浪費了資源。 CPU資源昂貴，每一個核心，同一時刻只能有一個線程在運行，超線程cpu同一時刻可以有兩個邏輯線程運行，所以說線程不是創建的越多越好，過多的線程只會增加線程切換帶來的成本。試想一下，如果應用線程池的線程，都在同步等待IO操作的結束，線程池中也就沒有空閑線程繼續處理請求，所以線程池會繼續創建線程以提供服務。惡性迴圈，則會帶來線程過多的成本，好線上程池不會讓這樣的事發生。那麼到達伺服器無法處理更多請求的程度時，http 503便出現了。

windows下使用IOCP

非同步IO在於線程非阻塞，提高CPU利用率，增加伺服器吞吐量，助我們承受更大的併發。在windows下使用IOCP，可以直接使用C#非同步編程await／async。雖然C#可以直接操作win32API，但.NET平臺已提供好非同步IO的操作封裝，只需要簡單的語法，即可完成非同步磁碟IO，非同步HTTP請求，非同步SOCKET，基於.NET框架現有的條件，也很容易做關係資料庫，redis，ElasticSearch，mongodb的非同步讀寫。所以推薦在windows下的IO儘可能使用IOCP。IOCP本質上解決的問題就是CPU和IO速度極大的不對等。

基於IOCP的非同步編程線程行為證明

簡單寫了個API介面，用於證明在非同步IO操作的時候，線程並不阻塞等待IO結束，而是將請求交給驅動後返回線程池，繼續工作。

圖中代碼操作是先記錄當前請求處理中的線程ID，然後請求一個10s返回的網路介面。用http客戶端併發請求圖中該介面後，我們稍後給出線程行為的結論。 我們都知道，如果說服務端線程是IO阻塞的，第一次請求，如果記錄了線程ID為1，那麼在10s內，該線程一直在阻塞等待，所以10s內不會再出現該線程ID被記錄到日誌中。 事實上結論是：

可以看到在同一秒甚至同一毫秒內，一個線程同時處理了多次http請求。另外可以確定的一個事實是，IO前和IO後，線程可能是不一樣的，也可能是一樣的。

感謝志同道合的你的閱讀，如果你希望長期學習到 .Net , Java , Kotlin ,Python 等原理知識，互聯網實踐乾貨，技術感悟等，不妨 關註博客，或者閑暇時在微信公眾號上閱讀。