现在用Delphi的人越来越少了，不过没关系，编程的经验应该是可以相通的，并不限于某种语言工具。我最开始也只是用C/C++，但后来我发现Delphi也挺好，在日常的信息系统开发中更具优势，因此就更偏向于用Delphi了。
相信很多人跟我一样，有这么一种感觉：Delphi只适合开发前端界面程序，开发后台服务则会不稳定，后台还是用Java或VC比较好。这种感觉一定程度上是有道理的，毕竟Delphi容易入门，其编程模式又使得入门后的程序员偏向于以界面为中心，重UI而轻结构，这些显然都不适用于后台服务开发。
但其实这些都是程序员的问题。Delphi只是一个编程工具，不能因为它的界面功能强就否定它生成的程序稳定性。其实用它来写*面的程序也是完全OK的，只是需要注意一些细节。这里我按自己的经验做个小结，如下：
1.最重要的，是要自己接管内存分配，开辟内存缓冲池。
原因很简单，WIN32下一个进程只有2G内存空间，服务程序要长期运行，就会不断地申请和释放内存，而且不但会申请小块的零碎内存，经常也会需要申请连续的大片内存，如果任由系统无限制的循环分配释放内存，那么很快你的程序空间就会充满零碎的内存，这时再要申请连续的大片内存就会失败，导致程序崩溃了。这些都是我们有过的惨痛经历得来的教训，服务死掉的最常见原因，就是猛占内存，直到系统资源不足。
所以，除非你能自己搞一个内存碎片整理功能，否则你一定要接管内存分配，把所分配的内存记下来，重复使用。不然的话，想要长时间运行，除非你的服务线程什么都不干。
从这一点来看，Java适合做后台服务也是有道理的，最起码它的垃圾回收机制，为我们解决了内存的问题。
2.对象缓冲池，对于经常要重复创建、释放的对象，一律用缓冲池管理。
原因类似上面，但不限于内存。如线程对象、位图对象、数据连接、查询组件等等，只要服务中经常用到的东西，一律放入缓冲池中。缓冲池一般都会设置最大值，达到上限时就需要排队等待了；不然的话，连接用户一多，再多的资源也顶不住。
3.日志功能。
对于没有界面的后台服务来说，日志的重要性是不言而喻的。日志需要记录服务的运行状态、用户操作、错误异常堆栈、内存性能警报等。服务程序中的CPU内存资源非常宝贵，因此日志中需要对占用CPU和内存资源多的操作进行重点记录。开发阶段如果有出现运行时间长的情况，应在代码中加上运行时间的检测日志，供分析排查。
4.负载均衡与容错处理。
服务程序要想长时间运行，就得支持多实例分摊负载。当其中一个服务出现问题时，可转到其它服务，这样最多只影响当时未保存的少量操作，不影响整体使用。
5.拷机测试。
服务上线前，一般都需要进行长时间的大负荷运行测试，这时一般都需要有客户端请求来配合。可用现成的测试工具，如LoadRunner、QTP之类的。我比较倾向于自己写随机模拟测试程序，比较接近现实情况。
6.运行监控。
需要另外再有一个程序对服务进行监控，一旦发现异常，立即发送邮件和短信通知相关负责人。这种程序不难，可自己写一个；不想写的话也有现成的，网上搜索一下就能找到。
7.远程管理，可对异常进行处理。
人力毕竟有限，谁也难以保证永远不出问题。因此远程管理是非常必要的。如对于异常的侍服线程，可远程强制结束；可远程查看日志，采取相应措施；实在不行，还可以远程控制服务重启。
8.其它没想到的...（此处略去128K个字，呵呵）
写了这么多，发现似乎跟Delphi没什么关系。其实，只要是写服务程序，都会遇到类似的问题。使用的工具不同，但做事的方式和结果是一样的。只要能注意这些细节，用什么写都一样，都可以放心地7x24小时长时间稳定运行。只是...呃...要全做到太不容易了，估计只有大公司才行吧，我自己也只能做到其中一部分而已。