不光还是游戏引擎，任何一个项目都有必要做好内存管理，至少可以监控内存使用量和内存泄露。而对于游戏引擎而言更是如此，在游戏引擎里面动态分配释放内存的地方不在少数，做好内存管理对于提高引擎运行效率是十分必要的。
内存管理就是做两件事，负责内存的分配和释放，再有就是对内存的分配释放进行监控，据此来解决内存泄露和掌握内存使用情况。
先说说内存分配释放，这也是内存管理最重要的部分。一般来说内存管理只管理小内存的分配释放，大内存则无需管理制作监控即可。过多的小内存分配释放会造成系统内存碎片从而可能分配不下内存，与此同时过多的调用系统的内存分配释放函数也是低效。malloc,free这些函数本身就很慢。
现在问题的本质出来了，内存管理关的就是小内存的分配释放，要采用某种办法避免经常性的调用系统的分配释放函数，简单来说就是要解决这个问题。具体办法是这样的，以Unreal的内存管办法为例，他认为32k以下的内存都是小内存，>32k的不作管理。当申请size大小的内存时他一次性分配64k，这样就获得了64k/size个内存块，这就是一个池，当再次分配同样大小的内存时则从这个池中取不仅新真正的内存分配，当池满了则在分配64k以同样的方法管理，当池空了的时候释放这64k的内存。可以看出他的内存分配单位是64k，且只有在池满了或者池空后才做真正的内存分配释放。
再说说内存监控，这一块可发挥的空间非常大，你可以监控内存分配释放相关的任何感兴趣的东西。比如当前使用的指针数，当前使用的内存量，在游戏退出后这两个数据都应该为0否则出现了内存泄露。再比如可以监控峰值内存使用量等，还可以记录每次内存分配是哪个文件那行代码，用于在出现内存泄露的时候定位有问题的代码。
以上就是一个简单的内存管理模块。
接下来说一下使用时候的问题。一般来说引擎都是一个dll之类的，它的内存管理在他系统内部，这就带来了一个问题，如何与工具.exe配合，如何与game.exe配合，这些exe程序要不要也使用内存管理，如果使用是否使用引擎的内存管理，这样做会不会有问题。
我是这么做的，首先引擎的operator new是不会export到dll外的，但是引擎要对外开放Malloc,Free这样的内存分配接口，在exe端重写operator new/delete，并调用引擎的Malloc，Free。这样可以灵活的在exe端决定是否使用内存管理。
在game.exe这块一般都要重写operator new/delete并调用引擎的Malloc, Free，使引擎和游戏本身全部使用内存管理，做统一控制。
但是工具一般都是用mfc写，这会带来另一个问题，也许是MFC的Bug。MFC的大多数类都是从CObject派生来的。你会发现他写的operator new, operator delete调用的内存函数不同，这会引起Crash.所以MFC写的工具干脆就不使用引擎的内存管理，也就是说MFC自己管自几的引擎自己管自己的，只要不互相释放对方的内存就不会有问题。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Leo1981816/archive/2010/08/09/5798020.aspx