PHP框架的繁荣是正确的发展方向吗？

谢谢, 我一直在找PHP的线程模型方面的资料.今天看这个帖子才知道PHP的处理这么"省事".

另外, 还想问下:
1.java(单进程运行)是不是所有请求都用一个进程处理, 每个请求用这个进程中的一个线程处理?

2. Ruby(多进程运行)是不是类似进程池? 没有空闲进程则创建, 有就重用?

3. PHP的多进程运行方式最好理解, 但有没有办法实现"定时执行后台任务"?  以及"异步调用"?

Ruby 也可以跟 Java 一样：“controll whole world模型 单进程运行，进程内部多线程调度，所有的资源都自己提供”。

“controll process模型 多进程运行，进程内部可以持有资源，带有GC，部分依赖外部资源实现（例如Cache）功能”不是 Ruby，而是 rails 的运行方式。

这篇文章写漏了一个关键的 fastcgi。fastcgi 模式下，php 不需要对每个请求都建立进程。

这和框架有什么关系？莫名其妙



你用 php 框架实际做过项目再来说这话不迟。处男说做爱没意思，不是扯淡么。

你的话我也不想回了，纯粹是在抬杠。

第三个我可以回答：如果是虚拟主机，只能模仿 cron。如果是自己的服务器，写个 php 脚本从 cron 调用就行了。至于异步调用确实做不到，只能用 ajax 或者队列+cron脚本来模拟。

PHP 框架不是问题。关键是要找到一条“建设有 PHP 特色的框架开发之路”，而不是“照搬资本主义”。社会体质的不同造成了中国与大部分欧美国家发展之路的差异，中国经历了几代领导人才找到真正的出路，这点跟 PHP 目前的情况类似：PHP 的实现本质上就跟 Python/Ruby 的实现不同。

运行机制上的例子，随便举几个吧：你可以用 Python 脚本操纵线程，可以实现跨请求存在的变量，实现真正的对象（进程内对象，而非请求内对象，PHP 的类实际上只是一个跟请求有着相同生命期的瞬态对象，PHP 的对象就更不用说了），实现真正的工作单元模式（严肃的 ORM 都需要这个），实现真正的对象池、连接池、线程池，实现真正的异步I/O、非阻塞I/O，等等等等，你可以想象一下你用 C 写 HTTP Server 时需要考虑哪些，你就可以用 Python 去实现。

然而……你能单纯用 PHP 脚本实现这些么？PHP 解释器的实现注定了它只适合 HTTP 这种请求、响应的运行方式，你的全部表演已经被套牢在 PHP 解释器设计的运行环境里。你没法控制 PHP 工作进程。当然，从工业开发来说，这种做法非常好，因为它限定了程序员只能做什么，即使程序猿本身并不知道它已经被限死了。不过大部分程序猿也非常乐于被限制住，因此实际上还是皆大欢喜的，不然也不会有这么多 PHP 程序员，PHP 也不会这么流行。

反之，Python/Ruby 是做为通用的应用程序开发语言而设计的，它没有为 HTTP 这种请求、响应式运行模型做设计，因此你必须考虑很多东西，比如 PHP 解释器已经实现了 mod_php、FastCGI 的 SAPI，实现了 HTTP 这种请求、响应模型，你只需选择一个即可快速开发 Web 应用程序，然而换成 Python 则不行，即使你有了 Python 解释器及其标准库，在应用到 Web 平台上时你要做 Web 开发还需要做很多其它东西，比如你可能没有 FastCGI 协议的实现，你得去实现它；你可能没有 HTTP 请求的 parser，你得去实现它；没有模板渲染器，你也得去渲染它；你希望你的 Python 应用程序可以在多种 Web 服务器平台上部署，你得实现 WSGI 协议；你希望你的程序跑一段时间后不会挂，你得考虑资源的分配和释放…… 当然，现在已经有很多人完成了这些工作，所以现在用 Python 开发 Web 应用程序已经相当容易了。然而如果你决定开发一个严肃的 Python Web 框架，那难度相比起 PHP 就要高不少，没有系统的计算机科学知识体系较难做到，因为类比开来，就是你需要去实现 PHP 解释器已经帮你实现好的很多东西。

当然，两者都有优、缺点，我目前也是两者都用。

不错，PHP 的优势在于其设计目标就是“Web”，所以开发 Web 应用需要的大部分基础功能，PHP 都已经做好了。

以上传文件来说，PHP 是内置的，绝大部分情况已经够用了。而其他语言的 Web 框架都得自己去实现这些，就连 ASP 也得自己做。

所以 PHP 的开发框架其实着重点是如何简化业务功能的开发，不用去考虑那么多基础性工作。当然正如你所说，由于 PHP 运行模式的限制，工作单元、对象池、连接池、线程池，实现真正的异步I/O、非阻塞I/O等在 PHP 框架中都没法做。

不过就因为这几点就认为 PHP 框架是误入歧途，毫无疑问是太片面了。PHP 框架虽然有模仿其他语言的开发框架，但本质上 PHP 框架还是以发挥 PHP 自身优势为主。

事实上，在今天看来，CakePHP 这样的 PHP 框架不管是设计还是实现，都已经过时了。相信会有更具备“PHP 特色的开发框架”出现。

FastCGI 的行为跟 mod_php 没有什么差异，除了 mod_php 还可以选择线程模式来运行。PHP 的 FastCGI SAPI 目前我还没看到以多线程模式来运行的，常用的 php-fpm 也是以多进程单线程来运行的。

嵌入 mod_php 的 httpd 子进程同样是持久的，不是一个请求过来就建立进程，那是 CGI 的做法。

那篇博文说 PHP 类似 CGI 的意思是说 PHP 脚本的行为类似 CGI，因为 CGI 进程的生命周期也是一次请求，这点跟 PHP 脚本的一次执行是一致的。实现上，PHP 解释器实现了一个“CGI进程运行环境”，只是在其中运行的角色是 PHP 脚本。

PHP 脚本里没有线程的概念，只有 PHP 解释器的实现有线程与否的概念。PHP 解释器通过 TSRM 层来实现对 PHP 脚本屏蔽线程。

另外，PHP 解释器未必使用多进程的运行方式。在 Apache 下，它还可以嵌入多线程方式的 httpd 子进程，以多线程的方式来运行，一个线程对应一个 HTTP 请求的处理。当然此时如果 PHP 解释器的部分代码没有做到线程安全，那可能就会出问题（据称 PHP 解释器的核心部分都是线程安全的，不过可能有些扩展代码的质量不高，存在线程不安全的问题）。

关于 PHP 部分，robbin的说法基本是错误的。PHP 解释器进程持有它需要的所有资源，它也带 GC。 PHP 解释器进程有两层面的 GC，一层是在请求结束时必须释放所有该次请求内申请的资源，并清扫该次环境；另一层是在请求执行内，它也存在 GC，这就是通常所说的 GC，比如变量的引用计数实现。