最近有個模組有記憶體洩露， 非常影響後臺服務質量， 用valgrind也沒有分析出原因（可能是分析的時候沒有洩露）， 就對著程式碼苦苦review, 發現有個基礎業務檔案存在記憶體洩露， 是近半年改動引起的。 程式碼只進行了new,  但沒有delete操作。

        我修改了有記憶體洩露的程式碼， 釋出後， 擦， 系統立即告警， 傻眼了。 絕對不可能啊， 我不就是加了delete嗎？ 難道不應該加？

        沒辦法， 只能回退釋出的版本， 回退後， 告警立即停止。

        可以得出結論： 告警與我發版本有關。

        我仔細反覆看new附近的邏輯， 也沒有找到原因， 想問老大這是為什麼， 但感覺又不太好， 還是希望單獨解決問題。 這種級別的問題， 應該自己想辦法獨立處理掉， 不應該麻煩老大。 於是仔細review上個版本到這個版本的改動， 發現關鍵改動點就在於我加了delete（其餘都是補充一些log）,  難道我delete了不該delete的東西？ 看邏輯， 也不是。

       現在的蛋疼點在於： 從程式碼上上看， 我的改動絕對不會有問題； 從實際看， 我的改動就是有問題。

       好吧， 還是相信實際， 但又找不出程式碼錯在哪裡

       難道還有別的原因， 問問老大吧， 但又想， 不應該總是給老大反饋類似問題， 而應該反饋怎麼解決類似問題。

       好了， 我不糾結了， 原來程式碼不是new嗎？ 我直接用陣列好了， 也不用delete,  也不擔心資料被提前釋放。 修改後， 釋出， 兩個告警問題解決了。

       扯淡的new, 以後能不用就不要用了，   申請4096B甚至更大的的緩衝區， 完全沒有用new的必要， 我討厭這貨！