IOCP以其高效的性能受到服務器開發(fā)者的青睞，本人有幸在當前的項目中使用了該異步模型，修改調試之余，總結出開發(fā)過程中的經(jīng)驗若干，供大家借鑒。
首先是需要注意的是OVERLAPPED結構。想必該結構大多數(shù)人都是自定義新的結構體，將OVERLAPPED成員放置在第一位，然后后置其他成員。
在函數(shù) WSASend, WSARecv, PostQueuedCompletionStatus 以及GetQueuedCompletionStatus 中都有LPOVERLAPPED的參數(shù)，其中在前面三個函數(shù)中是輸入?yún)?shù)，后面一個函數(shù)中是輸出參數(shù)。對于輸入?yún)?shù)可以傳入強制轉換的自定義結構體指針(不需要取地址)，也可以傳入自定義結構體中OVERLAPPED成員的地址(需要取地址)；對于輸出參數(shù)，將要傳出的是前三個函數(shù)中輸入?yún)?shù)的地址。在開發(fā)過程中，對于該結構地址的操作需要細心。
形如以下的代碼都是正確的：
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, (LPOVERLAPPED)pPerIoData, NULL);
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, &(pPerIoData->overlaped), NULL);
GetQueuedCompletionStatus(pThis->m_hIOCP, &dwBytesTransferred,(LPDWORD)&pPerHandleData, (LPOVERLAPPED *)&pPerIoData, INFINITE); 其次需要注意的是PostQueuedCompletionStatus 函數(shù)。該函數(shù)向IOCP發(fā)送三個參數(shù)(DWORD dwNumberOfBytesTransferred, ULONG_PTR dwCompletionKey, LPOVERLAPPED lpOverlapped)，GetQueuedCompletionStatus 函數(shù)將接收到這三個參數(shù)。IOCP將不會對這三個參數(shù)做任何操作。
在實際應用中，該函數(shù)一般用于控制IOCP接收線程的退出。其實，該函數(shù)的用法遠不止于此，它還可以作為消息來使用。通過定義特定的dwNumberOfBytesTransferred消息值，然后通過PostQueuedCompletionStatus函數(shù)向IOCP中POST該消息，GetQueuedCompletionStatus 函數(shù)就可以捕獲該消息。自定義的dwNumberOfBytesTransferred消息值一定要大于接收BUFFER和發(fā)送BUFFER的最大長度，否則作為消息就沒有意義了。
還有一個需要注意的是WSARecv函數(shù)。在IOCP中多次調用該函數(shù)是有后果的，嚴重的會導致接收緩沖區(qū)被塞滿，就算沒有塞滿接收緩沖區(qū)，如果客戶端意外斷開連接，GetQueuedCompletionStatus 函數(shù)會接到與調用次數(shù)一樣多次數(shù)的返回錯誤，想必大家一定都不希望這些情況發(fā)生。要避免這種問題一定要謹慎的調用WSARecv函數(shù)，最好在GetQueuedCompletionStatus 函數(shù)接收到數(shù)據(jù)后再考慮再次調用WSARecv。
今天又測出一個潛在的BUG，先貼代碼：
首先是定義：
typedef enum _IO_OPERATION
{
IoRecv, //WSARecv
IoSend, //WSASend
IoQuit
}IO_OPERATION, *PIO_OPERATION;
typedef struct _PER_IO_CONTEXT
{
WSAOVERLAPPED ol;
WSABUF WsaRecvDataBuff;
WSABUF WsaSendDataBuff;
char strRecvBuffer[DATA_MAX_BUFFERSIZE]; //接收BUFFER
char strSendBuffer[DATA_MAX_BUFFERSIZE]; //發(fā)送BUFFER
IO_OPERATION IoType;
}PER_IO_CONTEXT, *LPPER_IO_CONTEXT;
這里的IO_OPERATION定義了三種類型，分別表示接收、發(fā)送和退出，GetQueuedCompletionStatus函數(shù)在接收到消息時，可以通過檢測IoType的類型來判斷IOCP剛剛完成的操作是接收操作還是發(fā)送操作亦或是退出操作。
在一次操作中（比如接收到數(shù)據(jù)后的操作），先后調用WSASend和WSARecv，來實現(xiàn)發(fā)送數(shù)據(jù)，然后繼續(xù)Recv的動作，這樣做可行嗎？答案是否定的。分析：調用WSASend之前，設置IoType為IoSend，標志本次操作是發(fā)送操作；然后在調用WSARecv前，設置IoType為IoRecv，標志本次操作是接收操作。IOCP在處理消息隊列時，首先應該接收到的是發(fā)送操作，由于IoType已經(jīng)被設置成了IoRecv，在判斷時就會將這次操作判斷成接收操作，去檢測接收BUFFER，這樣顯然就出錯了；然后會接收到接收操作，此時IoType是IoRecv，仍然判斷為接收操作，此時檢測接收BUFFER，是正確的。這樣做的直觀表現(xiàn)就是接收事件明顯變多了。
以上的這個例子，說明處理IOCP時一定要細心，要注意那些變量是易變的，那些是不易變的。可能上面的這個看起來很明顯，但是如果程序復雜了，這種BUG就不易察覺。