前言
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 等原理知識，互聯網實踐干貨，技術感悟等，不妨 關注博客，或者閑暇時在微信公眾號上閱讀。
