內存分析

情感受了傷害，寫點技術貼吧，不能總是記錄些憂傷的事。

最近一直在分析項目的內存洩露，內存使用情況。老大說，內存與CPU一定要控制住。好吧，一個客戶端程序，也這麼有要求，也只能在這方面給點力了。

先解決內存問題吧。

先查洩露，怎麼查。boundcheck？還沒用過呢。。。但vld我是用過了，感覺還可以。

經過一番改造，已經可以在運行期，通過指令，輸出當前的內存使用情況，是誰在用內存，分配了多少，分配與釋放的頻率多少。

通過分析，感覺客戶端的內存使用都不多，只是分配釋放比較頻繁（到處在使用std::string）。但是通過vmap，堆的使用完全不止

vld統計出來的數目，這讓哥情何以堪啊。

洩露問題基本是可以保證了，使用內存佔用情況，還是沒解決啊

想一想vld的實現機制，還是挺有局限性的，因為它的機制，完全依賴於 crt 的 allochook， 我不走new不走mallc，它完全就沒作用了。

如果整個工程，全部都用debug_new，完全就是等於使用vld來分析了，所以 crl 的內存洩露檢測機制還是挺好的。

但問題是，我的EXE為什麼佔用了那麼多的內存，第一是dll，多一個dll，就多一點內存，dll 的數目，比較難控制，沒辦法。

我把焦點定位在堆的分配上，到底是誰在分配堆，為什麼我明明只分配了小小內存，時間長了，堆長得那麼大了，windows你的堆到底

有沒有自動切分自動合併的啊，難道工程真的存在某些內存分配高峰期，讓你的堆長了，然後小碎片占著讓你無法釋放？！

好吧，vld 只能監視new mallco，那我自己搞一個吧。先只監視 heapalloc吧，監視了這個，vld能實現的我也能實現，vld不能監視的，我也能監視，對吧。

動手寫了一下，我靠，這個heapalloc，heapfree還真TM特別，簡單的加一下鎖，TM的就死鎖了，而且還是兩個不同的鎖來它倆的。

好吧，我不鎖整個函數了，只鎖我的代碼，可以了吧。。。

寫了部分代碼，還沒測試，明天如果有環境跑一跑，再寫一下吧。