對於IOCP，搞Windows服務器編程的都不會陌生，它所表現出來的性能是其他各種WinSock模型難望其項背的。撰寫本文的目的就是為讓大家能夠在深入理解IOCP的基礎上，再來深入的挖掘Windows系統的性能。此處假設讀者對IOCP模型已經深刻理解，並對Windows線程、線程池有一定的了解。如果對此還不熟悉，限於篇幅的原因，請您先學習理解這些內容後再來閱讀本文。
在IOCP模型編程中，我們經常需要考慮的就是創建多少個線程來作為完成執行線程，很多時候這是個非常需要技巧和經驗的決策性問題。大多數情況下，我們采取的策略是看服務器上有多少CPU然後假定每個CPU最多執行兩個線程，然後我們創建的線程數量就是CPU數*2。這看起來很合理，但是實際上在復雜的服務器應用環境中，這樣做的效果並不盡如人意，很多時候我們希望得到一種更加動態靈活的方案。
有些有經驗的程序員就自己編寫線程池庫，來實現這種動態靈活的管理方式，從而還可以實現一定的擴展性，比如系統動態的添加了一些CPU的資源，或者系統負擔比較重的時候，或者CPU因為頻繁切換線程場景而導致效率低下時，線程池的動態性就發揮出來了。
索性的是，在Windows2000以上的平台上，已經為我們提供了線程池的接口，雖然這些接口有時候看起來還有些簡陋，比如有名的QueueUserWorkItem函數，這些接口簡陋到你連當前線程池中有多少活動線程等信息都無法知道，你只能通過其它的工具來動態觀察和猜測。但這樣的簡單性也為我們帶來了調用方便的實惠。當然到了Windows2008以上的平台時，線程池的函數總算是被大大加強了，你可以控制更多東西了，關於Windows2008線程池的內容請看我的另一篇博客拙作《Windows2008線程池前瞻》。
在結合IOCP和線程池這方面Windows系統也想到了程序員面臨的這個困難，Windows系統干脆直接就在系統內部捆綁了IOCP和線程池，提供了一個帶IOCP功能的線程池函數——BindIoCompletionCallback。
此函數的原形如下：
BOOL WINAPI BindIoCompletionCallback(
__in HANDLE FileHandle,
__in LPOVERLAPPED_COMPLETION_ROUTINE Function,
ULONG Flags
);
需要的完成過程（實際也就是IOCP線程的過程）Function的原形需要你定義成如下的樣子：
VOID CALLBACK FileIOCompletionRoutine(
[in] DWORD dwErrorCode,
[in] DWORD dwNumberOfBytesTransfered,
[in] LPOVERLAPPED lpOverlapped
);
熟悉IOCP的各位可能已經興奮得血管暴脹了吧？
從BindIoCompletionCallback函數的參數你應該已經能夠猜到這個函數的用法了，第一個句柄就是你需要捆綁的文件句柄或者SOCKET套接字句柄，甚至是其他I/O設備的句柄。第二個函數的指針就是你的完成例程的指針，這個函數完全由你實現和控制，最後一個Flags參數當前所有的Windows系統中都必須賦予0值，這個參數實際上還沒有被起用。
這麼簡單？真是難以置信，代表IOCP的句柄上哪去了？其實哪個什麼IOCP的句柄，以及創建多少個線程什麼的都不需要你考慮了，你唯一需要操心的就是如何編寫完成例程以及如何將一個I/O句柄和完成例程捆綁起來。以前需要n多行代碼才能完成的事情，一個BindIoCompletionCallback函數就徹底搞定了，甚至我們不需要再考慮線程的動態性問題了。這一切現在都有Windows系統綜合考慮了，而你就被解放出來了。
還愣著干嘛？快去寫你的高可用性，高可擴展、高動態性的IOCP大型服務應用去了！
