聊聊IOCP，聊聊異步編程

前言

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