PHP中的线程安全或非线程安全是什么？

Question

我看到了不同的 PHP 二进制文件，比如非线程还是线程安全的？

这是什么意思？

这些包有什么区别？

Answer 1

并发方法所需的背景知识：

不同的 Web 服务器采用不同的技术来并行处理传入的 HTTP 请求。 一种非常流行的技术是使用线程——也就是说，Web 服务器将为每个传入的请求创建/专用一个线程。 Apache HTTP Web 服务器支持多种处理请求的模型，其中之一（称为工作 MPM）使用线程。 但它支持另一种称为 prefork MPM 的并发模型，它使用进程——也就是说，Web 服务器将为每个请求创建/专用一个进程。

还有其他完全不同的并发模型（使用异步套接字和 I/O），以及将两个甚至三个模型混合在一起的并发模型。 为了回答这个问题，我们只关心上面的两个模型，并以Apache HTTP服务器为例。

需要有关 PHP 如何与 Web 服务器“集成”的背景知识：

PHP 本身不会响应实际的 HTTP 请求——这是 Web 服务器的工作。 所以我们配置web服务器将请求转发给PHP进行处理，然后接收结果并发回给用户。 有多种方法可以使用 PHP 链接 Web 服务器。 对于 Apache HTTP Server，最流行的是“mod_php”。 这个模块实际上是 PHP 本身，但被编译为 Web 服务器的模块，因此它被直接加载到其中。

还有其他方法可以将 PHP 与 Apache 和其他 Web 服务器链接起来，但 mod_php 是最受欢迎的一种，也可以用来回答您的问题。

您以前可能不需要了解这些细节，因为托管公司和 GNU/Linux 发行版为我们准备了一切。

现在，问你的问题！

由于使用 mod_php，PHP 会直接加载到 Apache 中，如果 Apache 将使用其 Worker MPM（即使用线程）处理并发，那么 PHP 必须能够在同一个多线程环境中运行——这意味着， PHP 必须是线程安全的，以便能够与 Apache 正确打球！

此时，您应该会想“好吧，如果我使用的是多线程 Web 服务器并且我打算将 PHP 直接嵌入其中，那么我必须使用 PHP 的线程安全版本”。 这将是正确的想法。 然而，碰巧的是，PHP 的线程安全性 备受争议。 这是一个使用如果你真的真的知道你在做什么的地方。

最后的笔记

如果您想知道，我个人的建议是，如果您有选择，请不要在多线程环境中使用 PHP！

只说基于 Unix 的环境，我想说幸运的是，如果你打算在 Apache web 服务器上使用 PHP，你只需要考虑这一点，在这种情况下，建议你使用 Apache 的 prefork MPM（它不使用线程，因此，PHP 线程安全无关紧要）和我所知道的所有 GNU/Linux 发行版都会在您通过其软件包系统安装 Apache + PHP 时为您做出决定，甚至不会提示您为了一个选择。 如果您打算使用其他网络服务器，例如nginx或lighttpd ，则无论如何您都无法选择将 PHP 嵌入其中。 您将考虑使用FastCGI或类似的东西，它们在不同的模型中工作，其中 PHP 完全在 Web 服务器之外，多个 PHP 进程用于通过例如 FastCGI 响应请求。 对于这种情况，线程安全也无关紧要。 要查看您的网站使用的是哪个版本，请放置一个包含<?php phpinfo(); ?>的文件<?php phpinfo(); ?> <?php phpinfo(); ?>在您的站点上查找Server API条目。 这可以说是CGI/FastCGI或Apache 2.0 Handler 。

如果您还查看 PHP 的命令行版本 - 线程安全无关紧要。

最后，如果线程安全无关紧要，那么您应该使用哪个版本——线程安全的还是非线程安全的？ 坦白说，我没有科学的答案！ 但我猜想非线程安全版本更快和/或错误更少，否则他们只会提供线程安全版本而不会费心给我们选择！

Answer 2

对我来说，我总是选择非线程安全版本，因为我总是使用 nginx，或者从命令行运行 PHP。

如果您将 PHP 安装为 CGI 二进制文件、命令行界面或其他仅使用单个线程的环境，则应使用非线程安全版本。

如果您将 PHP 作为 Apache 模块安装在工作 MPM（多处理模型）或多个 PHP 线程并发运行的其他环境中，则应使用线程安全版本。

Answer 3

使用带有 modphp 的 Apache MPM prefork 是因为它易于配置/安装。 在性能方面，它是相当低效的。 我首选的堆栈方式是 FastCGI/PHP-FPM。 这样你就可以使用更快的 MPM Worker。 整个 PHP 仍然是非线程的，但 Apache 服务于线程（就像它应该的那样）。

所以基本上，从下到上

Linux

Apache + MPM Worker + ModFastCGI（非 FCGI）|（或）| 切诺基|(或)| nginx

PHP-FPM + APC

ModFCGI 不能正确支持 PHP-FPM 或任何外部 FastCGI 应用程序。 它只支持非进程管理的 FastCGI 脚本。 PHP-FPM 是 PHP FastCGI 进程管理器。

Answer 4

根据PHP 文档，

下载 PHP 时线程安全意味着什么？

线程安全意味着二进制文件可以在多线程网络服务器上下文中工作，例如 Windows 上的 Apache 2。 线程安全的工作原理是在每个线程中创建一个本地存储副本，这样数据就不会与另一个线程发生冲突。

那我选择什么？ 如果您选择将 PHP 作为 CGI 二进制文件运行，那么您将不需要线程安全，因为在每个请求时都会调用该二进制文件。 对于多线程 Web 服务器，例如 IIS5 和 IIS6，您应该使用 PHP 的线程版本。

以下库不是线程安全的。 不建议在多线程环境中使用它们。

• SNMP (Unix)
• mSQL (Unix)
• IMAP (Win/Unix)
• Sybase-CT (Linux, libc5)

Answer 5

其他答案涉及 SAPI 实现，虽然这是相关的，但问题询问线程安全与非线程安全分布之间的区别。

首先，PHP 被编译为可嵌入库，例如 *NIX 上的 libphp.so 和 Windows 上的 php.dll。 这个库可以嵌入到任何 C/CPP 应用程序中，但显然它主要用于 Web 服务器。 在它的核心 PHP 在两个主要阶段启动，模块初始化阶段和请求初始化阶段。 模块 init 初始化 PHP 核心和所有扩展，其中 request init 初始化 PHP 用户空间 - 本地用户空间功能以及 PHP 代码本身。

PHP 库设置为只需要调用一次模块阶段，但必须为每个 HTTP 请求重新初始化请求阶段。 请注意，CLI 链接到与 mod_php 等相同的库，并且仍然必须在内部经历这些阶段，即使它可能不会在处理 HTTP 请求的上下文中使用。 此外，需要注意的是，PHP 并不是为处理 HTTP 请求而设计的——最准确地说，它是为处理 CGI 事件而设计的。 同样，这不仅仅是 php-cgi，而是所有 SAPI/应用程序，包括 php-fpm、mod_php、CLI，甚至是极其罕见的 PHP 桌面应用程序。

链接到 libphp 的 Web 服务器（或更典型的 SAPI）倾向于遵循以下四种模式之一：

• 为每个请求创建一个全新的 PHP 实例（旧的 CGI 模式，不常见，显然不推荐）
• 创建一个 PHP 实例，但在单独的分叉子进程中完成两个初始化阶段（一起）
• 创建一个 PHP 实例，在父进程 pre-fork 中执行一次模块初始化，然后在每个 HTTP 请求的单个请求阶段 post-fork

请注意，在示例 2 和 3 中，子进程通常在每次请求后终止。 在示例 2 中，子进程必须在每个请求结束时终止。

第四个示例与线程实现有关

• 在主线程中调用一次模块初始化，然后在其他线程中调用请求初始化。

在线程的情况下，请求处理线程倾向于利用线程池，每个线程在循环中运行，在开始时初始化请求阶段，而不是在结束时销毁请求阶段，这比每个请求产生一个新线程更优化

不管线程实现如何利用 libphp，如果模块阶段在一个线程中初始化并且请求阶段在不同的线程中调用（这是 PHP 设计的情况），它需要大量的同步，而不仅仅是在 PHP核心，但也在所有原生 PHP 扩展中。 请注意，此时这不仅仅是“请求”的问题，而是根据 PHP OPCODE 调用它的同步问题，这依赖于存在于不同线程中的 PHP 核心（或任何 PHP 扩展）中的任何形式的资源作为 PHP 用户空间。

这对线程安全的 PHP 发行版中的同步提出了巨大的要求，这就是为什么 PHP 倾向于遵循“不共享”规则以帮助最小化影响的原因，但是在这种模式中没有真正的“不共享”这样的东西，除非每个线程都包含一个完全独立的 PHP 上下文，其中模块阶段和请求阶段都在每个请求的同一线程中完成，这是不建议或不支持的。 如果在模块初始化阶段构建的上下文与请求初始化阶段一样位于单独的线程中，那么线程之间肯定会共享。

如果在这一点上不明显，线程安全与非线程安全不仅仅是 PHP 如何在 SAPI 实现中作为“请求处理程序”在内部工作的问题，而是 PHP 作为嵌入式虚拟机在内部如何工作的问题一种编程语言。

这一切都是由 TSRM 或线程安全资源管理器实现的，它制作精良，可以处理大量同步而几乎没有感知开销，但开销肯定存在，并且不仅会根据每个请求的数量增加其次，服务器必须处理（决定 SAPI 需要多少线程的决定因素），还有每个请求（或每次执行）使用多少 PHP 代码。 换句话说，大型臃肿的框架可以在 TSRM 开销方面产生真正的影响。 这并不是说线程安全 PHP 中的整体 PHP 性能和资源要求，而只是说线程安全 PHP 中 TSRM 本身的额外开销。

因此，预编译的 PHP 以两种形式分发，一种是在 TSRM 在 libphp 中处于活动状态（线程安全）中构建的，另一种是 libphp 不使用任何 TSRM 功能（非线程安全），因此没有 TSRM 的开销.