在游戲開發領域，按照組件開發這種模式，在很多項目都實施過了，本人也參與過一些。不是理論上的泛泛而談，實施上和設計上都不存在難點了。

游戲領域的需求變更是常事，基本上每幾天一變都可能，甚至還沒做完就在變了，這個和傳統項目完全不同，對開發者是有一定要求的。

內存管理這塊通用的內存優化方案確實是不需要開發者參與了(當然，也固定了優化模式，不可能是對象池)，無論是多線程還是單線程，性能都會有很大的提升。

同意部分觀點,歡迎大家探討。
1、其實按照模塊劃分，針對接口開發，組件式開發這類東西，在游戲項目中已經很成熟了，很多項目都是這樣做的，不存在什么問題和難點。

2、至于先實現再重構，個人覺得很難，游戲項目大部分時間緊，越到后面壓力越大，很難到后面來調動大家積極性來重構，也很難抽出時間來重構,風險也非常大。過多的重構還不如做之前多規劃。

3、內存管理的優化，其實不需要代碼做出優化修改，發布的時候鏈接下特定庫就行，無需人工參與和修改代碼，對開發者基本是透明的。

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

@張立斌
有效，個人感覺這個和模板無關。

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

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

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

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

對“系統內存分配器已針對小內存分配進行優化”，這個我觀點覺得有可能（畢竟沒有驗證），不過我倒覺得crt分配小內存的至少還是會有個head的，這個浪費免不了了（當然tcmalloc現在也是有頭的，一般自己實現的內存分配器是不會有頭的），從比例上來說浪費的還是比較多的，這個可以做個實驗驗證，一次分配50M和多次分配10byte至50M，2者進程的內存差距還是比較明顯的。
好在現在PC和服務器內存越來越大，內存分配器的主要焦點都集中在速度上了。

tcmalloc跨線程歸還內存，確實是因為所有線程公用了底層的一個分配器，所以跨線程歸還是無需加鎖的（從手冊上看的，不知道博文提了沒有）。
關于tcmalloc亮點，我倒覺得算法上的小優化其實倒沒那么振奮，給我沖擊最大的是產品的可用性，以往一個產品要使用新的內存分配器，一般需要改很多代碼，最常見的是將已有類從一個SmallObject之類的類繼承，很麻煩，這方面tcmalloc干的不錯。

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

@yafare
yafare是常在cloud的blog發言的那位？

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

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

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