前言
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 等原理知識，網際網路實踐幹貨，技術感悟等，不妨 關注部落格，或者閑暇時在微信公衆号上閱讀。