在游戲開發(fā)領(lǐng)域，按照組件開發(fā)這種模式，在很多項(xiàng)目都實(shí)施過了，本人也參與過一些。不是理論上的泛泛而談，實(shí)施上和設(shè)計(jì)上都不存在難點(diǎn)了。

游戲領(lǐng)域的需求變更是常事，基本上每幾天一變都可能，甚至還沒做完就在變了，這個(gè)和傳統(tǒng)項(xiàng)目完全不同，對(duì)開發(fā)者是有一定要求的。

內(nèi)存管理這塊通用的內(nèi)存優(yōu)化方案確實(shí)是不需要開發(fā)者參與了(當(dāng)然，也固定了優(yōu)化模式，不可能是對(duì)象池)，無(wú)論是多線程還是單線程，性能都會(huì)有很大的提升。

同意部分觀點(diǎn),歡迎大家探討。
1、其實(shí)按照模塊劃分，針對(duì)接口開發(fā)，組件式開發(fā)這類東西，在游戲項(xiàng)目中已經(jīng)很成熟了，很多項(xiàng)目都是這樣做的，不存在什么問題和難點(diǎn)。

2、至于先實(shí)現(xiàn)再重構(gòu)，個(gè)人覺得很難，游戲項(xiàng)目大部分時(shí)間緊，越到后面壓力越大，很難到后面來調(diào)動(dòng)大家積極性來重構(gòu)，也很難抽出時(shí)間來重構(gòu),風(fēng)險(xiǎn)也非常大。過多的重構(gòu)還不如做之前多規(guī)劃。

3、內(nèi)存管理的優(yōu)化，其實(shí)不需要代碼做出優(yōu)化修改，發(fā)布的時(shí)候鏈接下特定庫(kù)就行，無(wú)需人工參與和修改代碼，對(duì)開發(fā)者基本是透明的。

4、不過不是好的東西就容易推，要打破現(xiàn)有或者歷史結(jié)構(gòu)，在哪個(gè)項(xiàng)目都不是件容易的事情，大部分情況下，只能互相妥協(xié)。和生活中很多事情一樣，做事情之前，首先要取得別人的信任，否則多半是做不成的。

@張立斌
有效，個(gè)人感覺這個(gè)和模板無(wú)關(guān)。

@linux
3qs,原來還有這個(gè)工具,話說用這個(gè)工具就是linux的思維了?

@DavidChiu
如果是從CSDN那個(gè)鏈接下載的完整包，是可以打開的。

樓主這種辦法比較耗CPU吧？另外，刷新也會(huì)是個(gè)問題，不過探索精神應(yīng)該贊一個(gè)。原來也為朋友做過這個(gè)外掛，當(dāng)時(shí)用的一個(gè)辦法是掛鉤directDraw，直接操作緩沖區(qū)，效率會(huì)比較高，另外顯示上也會(huì)更好。

@maxime
同意加鎖的自定義分配器還不如不用的說法(所以說設(shè)計(jì)討論在項(xiàng)目中是需要的，除了開發(fā)者，我們大家都不知道項(xiàng)目的多線程分配加鎖了：）)。

對(duì)“系統(tǒng)內(nèi)存分配器已針對(duì)小內(nèi)存分配進(jìn)行優(yōu)化”，這個(gè)我觀點(diǎn)覺得有可能（畢竟沒有驗(yàn)證），不過我倒覺得crt分配小內(nèi)存的至少還是會(huì)有個(gè)head的，這個(gè)浪費(fèi)免不了了（當(dāng)然tcmalloc現(xiàn)在也是有頭的，一般自己實(shí)現(xiàn)的內(nèi)存分配器是不會(huì)有頭的），從比例上來說浪費(fèi)的還是比較多的，這個(gè)可以做個(gè)實(shí)驗(yàn)驗(yàn)證，一次分配50M和多次分配10byte至50M，2者進(jìn)程的內(nèi)存差距還是比較明顯的。
好在現(xiàn)在PC和服務(wù)器內(nèi)存越來越大，內(nèi)存分配器的主要焦點(diǎn)都集中在速度上了。

tcmalloc跨線程歸還內(nèi)存，確實(shí)是因?yàn)樗芯€程公用了底層的一個(gè)分配器，所以跨線程歸還是無(wú)需加鎖的（從手冊(cè)上看的，不知道博文提了沒有）。
關(guān)于tcmalloc亮點(diǎn)，我倒覺得算法上的小優(yōu)化其實(shí)倒沒那么振奮，給我沖擊最大的是產(chǎn)品的可用性，以往一個(gè)產(chǎn)品要使用新的內(nèi)存分配器，一般需要改很多代碼，最常見的是將已有類從一個(gè)SmallObject之類的類繼承，很麻煩，這方面tcmalloc干的不錯(cuò)。

最后感謝maxime提供了MT使用tcmalloc的資料，以我從前的看法，靜態(tài)編譯的版本是無(wú)法使用tcmalloc的。

@yafare
yafare是常在cloud的blog發(fā)言的那位？

@yafare
int luaL_loadbuffer (lua_State *L,
const char *buff,
size_t sz,
const char *name);
打包文件加載是從內(nèi)存中加載的，理論上來說是可以沒有文件名的。不過也可能是為了方便調(diào)試，主動(dòng)將最后一個(gè)name設(shè)置為文件名了。
外掛其實(shí)有更簡(jiǎn)單的辦法，結(jié)合協(xié)程可以做一個(gè)單獨(dú)的AI腳本，可以做得比較靈活。逆向資源最初是想做游戲卻沒有資源。。。

@yafare
恩，不過這個(gè)只對(duì)lua有效，打包lua文件一般用luaL_loadBuffer加載。
而且hook了luaL_loadbuffer是得不到文件名的，對(duì)除script以外的資源也無(wú)效。

@chaogu
恩，這篇主要不是講常規(guī)小內(nèi)存分配的，那個(gè)到處都在講，沒啥新意了，文章資料里提到的很多都是常規(guī)小內(nèi)存實(shí)現(xiàn)，也可以直接看代碼或者侯捷的STL源碼剖析，有詳細(xì)內(nèi)容的。