昨天一個同事一大早在群里推薦了一個google project上的開源內(nèi)存分配器（http://code.google.com/p/google-perftools/），據(jù)說google的很多產(chǎn)品都用到了這個內(nèi)存分配庫，而且經(jīng)他測試，我們的游戲客戶端集成了這個最新內(nèi)存分配器后，F(xiàn)PS足足提高了將近10幀左右，這可是個了不起的提升，要知道3D組的兄弟忙了幾周也沒見這么大的性能提升。

如果我們自己本身用的crt提供的內(nèi)存分配器，這個提升也算不得什么。問題是我們內(nèi)部系統(tǒng)是有一個小內(nèi)存管理器的，一般來說小內(nèi)存分配的算法都大同小異，現(xiàn)成的實(shí)現(xiàn)也很多，比如linux內(nèi)核的slab、SGI STL的分配器、ogre自帶的內(nèi)存分配器，我們自己的內(nèi)存分配器也和前面列舉的實(shí)現(xiàn)差不多。讓我們來看看這個項目有什么特別的吧。

一、使用方法

打開主頁，由于公司網(wǎng)絡(luò)禁止SVN從外部更新，所以只能下載了打包的源代碼。解壓后，看到有個doc目錄，進(jìn)去，打開使用文檔，發(fā)現(xiàn)使用方法極為簡單：
To use TCMalloc, just link TCMalloc into your application via the "-ltcmalloc" linker flag.再看算法，也沒什么特別的，還是和slab以及SGI STL分配器類似的算法。
unix環(huán)境居然只要鏈接這個tcmalloc庫就可以了！，太方便了，不過我手頭沒有l(wèi)inux環(huán)境，文檔上也沒提到windows環(huán)境怎么使用，
打開源代碼包，有個vs2003解決方案，打開，隨便挑選一個測試項目，查看項目屬性，發(fā)現(xiàn)僅僅有2點(diǎn)不同：
1、鏈接器命令行里多了
  "..\..\release\libtcmalloc_minimal.lib"，就是鏈接的時候依賴了這個內(nèi)存優(yōu)化庫。
2、鏈接器->輸入->強(qiáng)制符號引用 多了 __tcmalloc。
這樣就可以正確的使用tcmalloc庫了，測試了下，測試項目運(yùn)行OK!

二、如何替換CRT的malloc

從前面的描述可知，項目強(qiáng)制引用了__tcmalloc， 搜索了測試代碼，沒發(fā)現(xiàn)用到_tcmalloc相關(guān)的函數(shù)和變量,這個選項應(yīng)該是為了防止dll被優(yōu)化掉(因為代碼里沒有什么地方用到這個dll的符號)。
初看起來，鏈接這個庫后，不會影響任何現(xiàn)有代碼:我們沒有引用這個Lib庫的頭文件，也沒有使用過這個dll的導(dǎo)出函數(shù)。那么這個dll是怎么優(yōu)化應(yīng)用程序性能的呢？
實(shí)際調(diào)試，果然發(fā)現(xiàn)問題了，看看如下代碼
    void* pData = malloc(100);
00401085 6A 64            push        64h 
00401087 FF 15 A4 20 40 00 call        dword ptr [__imp__malloc (4020A4h)]
跟蹤 call malloc這句，step進(jìn)去，發(fā)現(xiàn)是
78134D09 E9 D2 37 ED 97   jmp         `anonymous namespace'::LibcInfoWithPatchFunctions<8>::Perftools_malloc (100084E0h)
果然，從這里開始，就跳轉(zhuǎn)到libtcmalloc提供的Perftools_malloc了。
原來是通過API掛鉤來實(shí)現(xiàn)無縫替換系統(tǒng)自帶的malloc等crt函數(shù)的，而且還是通過大家公認(rèn)的不推薦的改寫函數(shù)入口指令來實(shí)現(xiàn)的，一般只有在游戲外掛和金山詞霸之類的軟件才會用到這樣的掛鉤技術(shù)，
而且金山詞霸經(jīng)常需要更新補(bǔ)丁解決不同系統(tǒng)兼容問題。

三、性能差別原因

如前面所述，tcmalloc確實(shí)用了很hacker的辦法來實(shí)現(xiàn)無縫的替換系統(tǒng)自帶的內(nèi)存分配函數(shù)（本人在使用這類技術(shù)通常是用來干壞事的。。。），但是這也不足以解釋為什么它的效率比我們自己的好那么多。
回到tcmalloc 的手冊，tcmalloc除了使用常規(guī)的小內(nèi)存管理外，對多線程環(huán)境做了特殊處理，這和我原來見到的內(nèi)存分配器大有不同，一般的內(nèi)存分配器作者都會偷懶，把多線程問題扔給使用者，大多是加
個bool型的模板參數(shù)來表示是否是多線程環(huán)境，還美其名曰:可定制，末了還得吹噓下模板的優(yōu)越性。
tcmalloc是怎么做的呢？ 答案是每線程一個ThreadCache，大部分操作系統(tǒng)都會支持thread local storage 就是傳說中的TLS,這樣就可以實(shí)現(xiàn)每線程一個分配器了，
這樣，不同線程分配都是在各自的threadCache里分配的。我們的項目的分配器由于是多線程環(huán)境的，所以不管三七二十一，全都加鎖了，性能自然就低了。

僅僅是如此，還是不足以將tcmalloc和ptmalloc2分個高下，后者也是每個線程都有threadCache的。
關(guān)于這個問題，doc里有一段說明，原文貼出來：
ptmalloc2 also reduces lock contention by using per-thread arenas but there is a big problem with ptmalloc2's use of per-thread arenas. In ptmalloc2 memory can never move from one arena to another. This can lead to huge amounts of wasted space.
大意是這樣的：ptmalloc2 也是通過tls來降低線程鎖，但是ptmalloc2各個線程的內(nèi)存是獨(dú)立的，也就是說，第一個線程申請的內(nèi)存，釋放的時候還是必須放到第一個線程池中（不可移動），這樣可能導(dǎo)致大量內(nèi)存浪費(fèi)。
 

四、代碼細(xì)節(jié)

1、無縫替換malloc等crt和系統(tǒng)分配函數(shù)。

   前面提到tcmalloc會無縫的替換掉原有dll中的malloc，這就意味著使用tcmalloc的項目必須是 MD（多線程dll）或者M(jìn)Dd（多線程dll調(diào)試）。tcmalloc的dll定義了一個
static TCMallocGuard module_enter_exit_hook;
的靜態(tài)變量，這個變量會在dll加載的時候先于DllMain運(yùn)行，在這個類的構(gòu)造函數(shù)，會運(yùn)行PatchWindowsFunctions來掛鉤所有dll的 malloc、free、new等分配函數(shù)，這樣就達(dá)到了替換功能，除此之外，
為了保證系統(tǒng)兼容性，掛鉤API的時候還實(shí)現(xiàn)了智能分析指令，否則寫入第一條Jmp指令的時候可能會破環(huán)后續(xù)指令的完整性。

2、LibcInfoWithPatchFunctions 和ThreadCache。

LibcInfoWithPatchFunctions模板類包含tcmalloc實(shí)現(xiàn)的優(yōu)化后的malloc等一系列函數(shù)。LibcInfoWithPatchFunctions的模板參數(shù)在我看來沒什么用處，tcmalloc默認(rèn)可以掛鉤
最多10個帶有malloc導(dǎo)出函數(shù)的庫(我想肯定是夠用了)。ThreadCache在每個線程都會有一個TLS對象：
__thread ThreadCache* ThreadCache::threadlocal_heap_。

3、可能的問題

設(shè)想下這樣一個情景：假如有一個dll 在tcmalloc之前加載，并且在分配了內(nèi)存（使用crt提供的malloc），那么在加載tcmalloc后，tcmalloc會替換所有的free函數(shù)，然后，在某個時刻，
在前面的那個dll代碼中釋放該內(nèi)存，這豈不是很危險。實(shí)際測試發(fā)現(xiàn)沒有任何問題，關(guān)鍵在這里：
 span = Static::pageheap()->GetDescriptor(p);
    if (!span) {
      // span can be NULL because the pointer passed in is invalid
      // (not something returned by malloc or friends), or because the
      // pointer was allocated with some other allocator besides
      // tcmalloc.  The latter can happen if tcmalloc is linked in via
      // a dynamic library, but is not listed last on the link line.
      // In that case, libraries after it on the link line will
      // allocate with libc malloc, but free with tcmalloc's free.
      (*invalid_free_fn)(ptr);  // Decide how to handle the bad free request
      return;
    }
tcmalloc會通過span識別這個內(nèi)存是否自己分配的，如果不是，tcmalloc會調(diào)用該dll原始對應(yīng)函數(shù)(這個很重要)釋放。這樣就解決了這個棘手的問題。

五、其他

其實(shí)tcmalloc使用的每個技術(shù)點(diǎn)我從前都用過，但是我從來沒想過用API掛鉤來實(shí)現(xiàn)這樣一個有趣的內(nèi)存優(yōu)化庫（即使想過，也是一閃而過就否定了）。
從tcmalloc得到靈感，結(jié)合常用的外掛技術(shù)，可以很輕松的開發(fā)一個獨(dú)立工具：這個工具可以掛載到指定進(jìn)程進(jìn)行內(nèi)存優(yōu)化，在我看來，這可能可以作為一個外掛輔助工具來優(yōu)化那些
內(nèi)存優(yōu)化做的很差導(dǎo)致幀速很低的國產(chǎn)游戲。