繼續之前的項目。跑錄像的時候，本地測試為2G內存的機器，效果還行。沒有出現掛掉的現象。
但把代碼重新編譯在外面跑的時候就出現了段錯誤，double free list_node_base nohook .一類的gdb信息。
后詢問大牛，得知應該是list的迭代器失效引起。
經檢查，的確如此。。
有一段類似于以下代碼
for(i = list.begin(); i !=list.end();i++)
{
if ( (*) == p)
{
}
}
之前有加鎖。后來使用了新的加鎖方法，、把鏈表的每一次操作加鎖，而不是全部加鎖，
也就是list.end()，并不是調用STL的end() 而是先lock 再調再unlock 自己進行了一次類的封裝操作。
由于這個影響，導致多線程在判斷的時候。有可能會有二個傳入的值同時被判斷，其中一個over這后順利進行。另外一個再進行操作。就段錯誤。
奇怪的是同樣二個機器同時測試。就一個出來了錯誤。。。想來是小錯誤。很少會碰到。double free 的情況和原生代碼雜亂也有一定關系
把之前的項目中的new 與delete進行了替換，使用緩存池來維護獲取到的內存塊指針。
發現如下問題。
一、原代碼中使用多線程結構，有部分指針被多次delete.
二、服務端，客戶端數據壓力大，使用200路時，內存消耗達到700M/240M ，數據使用大起大落，走到后面死掉
100路時跑一晚上暫無問題
內存池本身問題： 加鎖設計不夠，向系統申請時并未加鎖，導致多個線程同時申請多塊內存。
今天拿到一個project 在看。其中的問題就在于多次申請與釋放內存，導致到后期malloc會失敗。
最方便的解決辦法就是做一個內存管理層，接管系統的內存調用函數，使用內存管理的方式，一次申請，一次釋放。
有兩種做法，一個是用一個list來維護全部的數據
另外一個是用兩個list來維護，其中一個是被應用程序使用的內存區，其中一個是已經申請，尚未使用或者被應用程序釋放的區塊。
freelist usedlist
list 大小固定（對于目前的應用場合）