替代系統自帶的malloc/new原因無非兩個：
reason 1. 做內存profile或查找問題
reason 2. 自定義的分配方案提高性能
不過文章[1]中說明了，替代全局new不是一個好做法. 其實要達到以上兩點目的，筆者認為用valgrind工具鏈就可以了。
解決方案：
1. 用valgrind和massif
valgrind的memcheck做內存泄露和bug的查找, 里面的massif工具包做內存性能profile, 足矣。比自己山寨的一個profiler要好。
注意：tcmalloc目前還不能很好支持valgrind, 實測中jemalloc可以
2. linux下C的程序可以用wrap的方式(相當于python的decorator)
編譯加上選項：gcc -Wl,-wrap,malloc
可以做到對malloc這個函數，linker會調用__wrap_malloc代替之, 若要調用原來的malloc函數__real_malloc
缺點：依賴于編譯器支持； 對c++的new不起作用 --> 不實用
啟示：這個方法作為function裝飾器，對于調試別的問題倒有幫助。（例如不改變函數的情況下，wrap一層，輸出些調試信息)
3. 用__malloc_hook
#include <malloc.h>
void *(*__malloc_hook)(size_t size, const void *caller);
缺點：依賴GNU編譯工具鏈; 容易死循環(想利用原有malloc，要參考例子中，把原__malloc_hook變量保存起來使用，并恢復現場)
4. LD_PRELOAD注入.so ，替代原
環境變量LD_PRELOAD指定程序運行時優先加載的動態連接庫，這個動態鏈接庫中的符號優先級是最高的。標準C的各種函數都是存放在libc.so.6的文件中，在程序運行時自動鏈接。使用LD_PRELOAD后，自己編寫的malloc的加載順序高于glibc中的malloc，這樣就實現了替換。用法 LD_PRELOAD=" ./mymalloc.so"
缺點：在生產環境不現實。因為LD_PRELOAD相當于庫注入，有安全性問題，是必須禁止的。(生產環境很多時候用-static連接)
5. 用宏或另外的函數替代new/malloc
比如定義一個宏或者指定的函數，規定所有的分配釋放都調用他。這樣相當于給項目引入了額外的代碼規則(而且是一立項就要遵循這個規則，否則該方法無效），不能很自然的new/delete, 如果分配和釋放調用得不一致，會產生問題的。某產品組就是用宏，然后加上__FILE__, __LINE__之類的信息。
有時候valgrind的效率是個問題(尤其生產環境)，這種方案有其價值所在, 就是代碼看上去比較ugly罷了
用宏的例子：
#define _New(Type, Catergory) (Type*)MyMemController::New((new Type), #Type, 1, sizeof(Type), Catergory, __FILE__, __LINE__, false)
#define _NewArray(Type, N, Catergory) (Type*)MyMemController::New((new Type[N]), #Type, N, sizeof(Type)*(N), Catergory, __FILE__, __LINE__, true)
MALLOC的替代品：
自己寫一個malloc其實很復雜，要考慮線程安全等各種問題，性能到頭來可能更差。google 的tcmalloc, facebook使用的jemalloc. 多線程下性能較好，可以考慮使用。
缺點：筆者嘗試過。tcmalloc不能正確用valgrind,只能用自帶gperftools（運行中會core)
jemalloc可以使用valgrind，不過還沒完全驗證是否都準確。
tcmalloc相關:
在64位系統上要裝libunwind, 對x86-64架構使用還有些問題
源碼包的INSTALL文檔里面也提到了這個問題。
CAUTION: if you install libunwind from the url above, be aware that
you may have trouble if you try to statically link your binary with
perftools: that is, if you link with 'gcc -static -lgcc_eh ...'.
This is because both libunwind and libgcc implement the same C++
exception handling APIs, but they implement them differently on
some platforms. This is not likely to be a problem on ia64, but
may be on x86-64.
主要是64位機frame-pointer的影響, 他的profile工具里的backtrace用libunwind這個庫，這個庫又有版本問題，各種囧啊....
筆者試過系統x86-64, freebsd，用靜態鏈接。實際用了一下，問題很多很折騰，等他fix了再說吧.
windows下可以參考：
jemalloc暫時未發現有什么兼容性問題，運行得挺好的。