在游戏开发领域，按照组件开发这种模式，在很多项目都实施过了，本人也参与过一些。不是理论上的泛泛而谈，实施上和设计上都不存在难点了。

游戏领域的需求变更是常事，基本上每几天一变都可能，甚至还没做完就在变了，这个和传统项目完全不同，对开发者是有一定要求的。

内存管理这块通用的内存优化方案确实是不需要开发者参与了(当然，也固定了优化模式，不可能是对象池)，无论是多线程还是单线程，性能都会有很大的提升。

同意部分观点,欢迎大家探讨。
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源码剖析，有详细内容的。