服务端与客户端绝对是两码事。在客户端我们提倡 Create/New 和 Free/Dispose，随用随申请，不用即释放。但在服务端要尽量避免这样做。在客户端可以随时使用 string 类型，但在服务端也必须尽量避免使用 string 。string使用起来异常方便，但我们看看编译后的代码恐怕就会只冒冷汗：原来编译器为string的方便做了那么多额外的工作。客户端要为客户解决内存，但服务端能“浪费”则“浪费”。
“玩服务器就是玩内存”。 内存管理不当就会造成内存泄漏和内存碎片。对于客户端而言，内存碎片几乎不算是问题。内存泄漏那么一点点也可以接受。但对于 24 * 7 的服务器而言，这却绝对致命
关于内存泄漏，只要记得保证申请和释放动作的对称性即可，外加一系列的测试工具，基本就可以把这个问题解决。
其次就是内存碎片。内存碎片问题的重要性绝不亚于内存泄漏。造成碎片的原因也是防不胜防。简单的如每次的 New 和 Dispose ，Create 和 Free ，隐晦一点的如 string 类型的操作。
首先对于Create和Free，尽量少用。换句话说，尽量少用封装。适当的封装是可以的，只要封装的层次不是太深。Delphi 提供了 VCL 源码，我们可以看看即使是直接继承 TObject 那也会多做多少工作！对于频繁调用的函数，不要采用虚拟函数。这些晚绑定的函数，想调用就得查找 VMT，很费时间。对于类的普通函数，由于进行了早绑定，这个和其他非类的常规一样，不会降低效率。
其次，相应的，尽量使用结构和函数来代替类。对于结构，New 和 Dispose 也要尽量少用。要集中的使用来避免内存碎片。我们应该一次性把所预料的内存都申请完，服务器就得有服务器的样，放着那么多内存干什么。早晚都得申请，为什么在服务端启动的时候不一次性申请完，在服务端关闭的时候一次性释放掉？既避免了内存碎片又避免了以后的再申请操作，一举两得，何乐而不为？要知道内存分配和释放是非常昂贵的操作。不论是从时间上还是从稳定性上而言。再具体些，怎么保存这些申请到的内存？怎么保证在必要的时候可以很方便的再申请或及时的释放一些内存？我采用的是链表。在每次为一个数据结构申请内存的时候，先查看这个链表是否为空，如果不为空，就从这个链表中取出一个内存块，不需要真正调用函数申请。如果为空，再动态分配。使用完成后，把这个数据结构不释放，而是再把它插入到链表中去，以便下一次使用。
再次，不用 string 用什么？用数组！用字符数组！就像C中的字符数组一样。就是这么简单～