完成埠模型 來自 小豬博文 http://blog.csdn.net/piggyxp/article/details/6922277 自己增加了 postsend 、dosend 和一些錯誤處理 ，正常情況下不會存在什么問題 但是現在還是存在一種情況:當客戶端丟失連接，再進行連接的時候 記憶體會增長，在博文評論也看到有人 提到這個問題 ，但最后好像并沒有什么定論 我猜想的是：假如客戶端連接丟失 而socket有事件并未處理完成 就是說 仍有程式記憶體被系統鎖定 ，系統最后會超時 回傳失敗 所以這塊記憶體一直沒有被釋放掉 但是真實是怎樣的情況并不清楚 所以特來請教
uj5u.com熱心網友回復：
那就自己維護一個鏈表等來用心跳機制等判斷客戶端是否斷開連接了，斷開了就釋放對應的記憶體等uj5u.com熱心網友回復：
嗯 這個鏈表我是有的，我指的是 重疊IO那塊的uj5u.com熱心網友回復：
VMMap 是行程虛擬和物理記憶體分析實用工具。http://technet.microsoft.com/zh-cn/sysinternals/dd535533uj5u.com熱心網友回復：
TCP客戶端連接非正常斷開情況下，server端是檢查不到的，可以采用心跳機制判斷客戶端狀態，客戶端可以使用保活連接uj5u.com熱心網友回復：
我有心跳機制 點不在這 在異步發送階段對于 程式記憶體鎖定 這塊
uj5u.com熱心網友回復：
記憶體鎖定和具體的投遞方式有關
如果socket被關閉，則該socket相關的投遞物件都會回傳
之前看到有相關文章說，存在socket被關閉后，投遞物件長時間未及時回傳的情況
實測如果每路連接保證同一時刻僅有一個投遞物件，
則可以避免這種情況發生
uj5u.com熱心網友回復：
你心跳機制檢查到例外端開的時候，就要主動關閉socket連接，釋放與之系結的所有記憶體。uj5u.com熱心網友回復：
哇 大神誒 仰慕已久誒 代碼略長 我代碼就貼博文里 能幫著看看嘛 嘿嘿
http://blog.csdn.net/tingtings324/article/details/54577077
uj5u.com熱心網友回復：
嗯 單個投遞物件 會影響性能吧
uj5u.com熱心網友回復：
“池”化所有資源（記憶體、socket、……） ？uj5u.com熱心網友回復：
記憶體池只是在時間和管理方式上優化了下記憶體管理，假如存在記憶體泄漏，之后還是會崩潰的吧
uj5u.com熱心網友回復：
所有記憶體都“池”化了，即在主回圈中沒有任何記憶體申請釋放動作了，哪來的記憶體泄漏？
uj5u.com熱心網友回復：
假申請 假釋放
uj5u.com熱心網友回復：
只要在主回圈中還有對任何資源（記憶體、socket、句柄、執行緒、GDI物件、User物件、資料庫連接、……）的申請釋放，都不算嚴格意義上的“池”化了所有資源。uj5u.com熱心網友回復：
嗯 我再理解理解
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/110982.html
標籤：網絡編程