php是否适合做后台长驻程序
我不知道我的这些考虑是否已经全面，是否有什么遗漏的地方。
回复内容：
我目前使用php作为后台脚本的语言，很多人说php容易内存泄漏什么的，但是现在已经跑了一个月了状况良好。而且现在php已经大大改善了内存的回收机制，再加上它的简便性，实在找不到有什么理由拒绝使用。除了它不支持多线程以外，但是在一些性能要求不高的地方完全没啥问题。
我不知道我的这些考虑是否已经全面，是否有什么遗漏的地方。
既然这个问题问的是php 是否适合 做后台常驻程序，我觉得还是应该给一个非常明确的答案，即 不适合
诚如其他答案中所说，php可以实现所有功能，内存问题也逐步变好，这是好事，但这并不是php适合做这件事的理由。要说可以实现功能，采用awk + nc也可以写一个常驻后台的web server且性能不一定比php差，但实际上绝不会有人采用这种geek的技术方案。
php不适合做这件事的理由有三：
- php的设计目的是方便的构建动态网页，并非后台服务，使用一种语言工具应当尽可能扬长避短，勉力而为之并不合适。
- php缺乏内建的线程和非阻塞机制，采用fork的非阻塞方案已经在好几年前被证明是低效的，并非现在最合适的技术方案
- php缺乏制作后台常驻程序的库、框架、成功案例，相比其他在这个领域发展了许多年的语言、或专门为制作后台程序而生的语言（如C、Java、Go等），php并不合适
不过，php就算不适合做后台常驻程序，也并不妨碍它在某些情况下使用，比如
- 没什么性能压力、对稳定性也没什么特别要求时
- 必须调用很多php写的库，不方便使用其他语言重写时
- 开发同学只会写php，又找不到更好的人来实现这个项目时
总之，能不使用php做后台程序就别用，如果用了且未来还会上量，最好早做用其他语言重写的打算吧。
5.3以前, 应该循环引用问题, 不太适合. 5.3以后, 就没什么问题了.
不过一般, 我们都是结合crontab来做.
看到有人用PHP做server的。能否后台常驻，应该是取决于代码，而不是取决于语言。
既然用着舒服，又没有出现什么问题，没必要没事找事吧
不推荐的原因酱紫的。PHP的异常处理机制是个问题哦。
朋友网的webserver就是用php写的
@Summic 对这个回答持保留态度 ... 我自己用 php 实现过 webServer 和 socketServer ...
用到了 libevent 取代死循环 ... 用到了 shmop 缓存 ... 以及都是多进程 fork 的 ...
我用到了一切我能想到的优化 ... 但性能依然很烂 ...
socketServer 还好 ... 因为要维持长连接推送即可 ...
webServer 只能用呵呵来形容 ... 做做玩具还可以 ... 没办法真正用到生产环境去 ...
至于顶楼说的问题 ... 内存泄露什么的 ... 不敢说没有也不敢说有 ...
我只知道我的 php daemon 运行几个月 ... 也没见吃内存吃得多异常 ...
我完全没有在程序里刻意的调用 gc_collect_cycles() 或者 unset() 什么的 ...
运行也一切正常 ... 以及我觉得就 php 这种语言本身的特性而言 ...
只要你不直接去操作内存 ... 只是做普通操作的话 ... 想要内存泄露也难吧 ...
唯一需要注意的事情是 ... php 在做 daemon 的时候 ...
如果你连接了外部的服务 ... 切记要在再次打开连接之前关闭之前的连接！！
我见到的很多 php 程序员已经没这个习惯了 ... 写 daemon 需要注意的其实只有这一个 ...
基本就是这样 ... 总之 ... 嘛 ... 不管什么语言 ... 写得顺手就好了 ...
毕竟没有弱爆的语言只有弱爆的程序员 ...
其实就是代码的问题，正常的代码时不会出现内存泻露的。
后台脚本首先推荐使用shell，功能强大，和操作系统深度结合。
当然php也是可选的，耗CPU或者磁盘IO的程序推荐使用C或者Java来写会提高性能，当然糟糕的C代码可能比优秀的php效果差很多，适合就好。
适合做。而且开发效率高。只有最好的程序员，没有最好的语言。 Java，C/C++程序就不内存泄露了吗？恐怕更严重。 所以PHP也会有内存泄露。这都不是问题，只要有合理的机制保证可以回收内存即可。
swoole扩展里的max_request就是为了防止内存泄露的，运行超过一定次数后结束进程，重新创建一个新进程。
用事实说话：
- 定时性任务，php完全能胜任
- 长驻后台，感觉内存回收这块是最大的问题，php的内存消耗会持续增长，非常恐怖，用过才知道。
毕竟没有弱爆的语言只有弱爆的程序员 ... 呵呵，