这个问题只会是你在windows开发时存在，linux下没这么个情况。
看了半天，大概了解了：
apache的mod_php+php的Thread Safe v6版本。
apache的mod_fcgid+php的None Thread Safe v6版本。[我认为这个比较接近linux环境,推荐这个,使用进程就不存在线程问题]
另外php Debug Pack是为调试php本身用的与php使用者调试器zonedebuger,xdebuger不同
php apache2安装指南
http://docs.php.net/manual/zh/install.windows.apache2.php
Windows下PHP的线程安全（Thread Safe）版本和非线程安全（None Thread Safe）版本的选择？
八月 6th, 2010 Posted by zsj4cn
今天又在本机装了一下apache+php，在下载php的时候发现windows版本已经不在php.net主站下面了，有了一个独立的子域名：windows.php.net。
还有，我以前没有发现php for windows还有Thread Safe版本和None Thread Safe本版，一时还不该盲目下载来用。
查阅了一下资料，总结一下：
windows+apache2.2+php5.3 在都默认安装的情况下，apache2.2用了mpm_winnt_module本身是多线 程，apache的mod_php方式相当于上面家属的ISAPI方式被调用，php本身是线程安全的，但是php下的第三方扩展就不一定了。在这种情况 下，php应该选Thread Safe的安装程序。
如果调整一下配置，我建议用apache的mod_fcgid+php的None Thread Safe版本。
扩展阅读：
http://www.juyo.org/juyo/original/php-Thread-Safe/
…先从字面意思上理解，None-Thread Safe就是非线程安全，在执行时不进行线程（thread）安全检查；Thread Safe就是线程安全，执行时会进行线程（thread）安全检查，以防止有新要求就启动新线程的 CGI 执行方式耗尽系统资源。
再来看PHP的两种执行方式：ISAPI和FastCGI。FastCGI执行方式是以单一线程来执行操作，所以不需要进行线程的安全检查，除去线程安全 检查的防护反而可以提高执行效率，所以，如果是以 FastCGI（无论搭配 IIS 6 或 IIS 7）执行 PHP ，都建议下载、执行 non-thread safe 的 PHP …。而线程安全检查正是为ISAPI方式的PHP准备的，因为有许多php模块都不是线程安全的，所以需要使用Thread Safe的PHP。
说到这里，大家应该知道应该如何选择哪个版本的PHP了。None-Thread Safe or Thread Safe，您会选择哪个？
http://blog.bluesky.cn/archives/472/php-thread-safe-and-non-thread-safe-version-of-the-distinction-between.html
… 从2000年10月20日发布的第一个Windows版的PHP3.0.17开始的都是线程安全的版本，这是由于与Linux/Unix系统是采用多进 程的工作方式不同的是Windows系统是采用多线程的工作方式。如果在IIS下以CGI方式运行PHP会非常慢，这是由于CGI模式是建立在多进程的基 础之上的，而非多线程。一般我们会把PHP配置成以ISAPI的方式来运行，ISAPI是多线程的方式，这样就快多了。但存在一个问题，很多常用的PHP 扩展是以Linux/Unix的多进程思想来开发的，这些扩展在ISAPI的方式运行时就会出错搞垮IIS。因此在IIS下CGI模式才是PHP运行的最 安全方式，但CGI模式对于每个HTTP请求都需要重新加载和卸载整个PHP环境，其消耗是巨大的。
为了兼顾IIS下PHP的效率和安全，微软给出了FastCGI的解决方案。FastCGI可以让PHP的进程重复利用而不是每一个新的请求就重开一个进 程。同时FastCGI也可以允许几个进程同时执行。这样既解决了CGI进程模式消耗太大的问题，又利用上了CGI进程模式不存在线程安全问题的优势。
因此，如果是使用ISAPI的方式来运行PHP就必须用Thread Safe(线程安全)的版本；而用FastCGI模式运行PHP的话就没有必要用线程安全检查了，用None Thread Safe(NTS，非线程安全)的版本能够更好的提高效率。
-------------------------------------------------------------------------------------------------------------------------

php非线程安全和线程安全版本有什么区别

• 5月 7th, 2010
• Posted in E都市吧PHP学习
• Write comment

php5.3 版本有线程安全和非线程安全两种二进制for windows，我不明白这两种有什么区别，从网上没找到合适的答案，我用apache2.2+php5.2，一开始用非线程安全的apache启动不起 来，后换成线程安全的就可以了，不明白其中的原因？下面是一些相关解释可以看看。
看到zend debuger有非线程安全的版本，才知道PHP推出了非线程安全的版本。而此前我对非线程安全一无所知：
另一篇文章好像说这个跟 FASTCGI有点关系。
这是一段文字，不过我没看明白：
php本身是线程安全的。一个服务进程可以安全地提供多请求线程的支持
一些扩展并不遵守
例如：线程安全的扩展中，全局变量的定义不是像普通C程序那样直接定义在函数之外，而是定义在宏 ZEND_BEGIN_MODULE_GLOBALS和 ZEND_END_MODULE_GLOBALS之间。需要ZTS（Zend Thread Safe）支持的扩展需要包含TSRM.h头文件，并定义TSRMG宏值
在不支持线程安全的扩展中，仅是简单地认为一个服务进程同时只有一个请求在激活状态，不会出现冲突，那么全局变量可以简单地在RINIT函数中初始化（RINIT表示请求开始）并在RSHUTDOWN中注销：
CODE:[Copy to clipboard]PHP_RINIT_FUNCTION(ext)
{
counter = 0;
}
PHP_FUNCTION(ext)
{
RETURN_LONG(counter++);
}
…这就是一个很简单的计数器。只要请求没有结束，每次调用ext，都会触发 counter自增。
当在多线程环境中时，这个程序会发生严重的混乱，counter会变得飘忽不定，因为没有办法预测线程的触发和结束顺序及时间。这说明这个扩展并非线程级安全。
多线程，Apache 1.3 和 Apache 2.0
如 果您已经使用了 Apache 和 PHP 一段时间了，那么您很可能见到过安装文档中的一个警告信息，它说“不要在生产环境中使用 Apache 2.0.x 和 PHP，在 Unix 和 Windows 上都不行”。在 Windows 系统上的 PHP 5.0.2 包中，这个警告信息可以在 install.txt 文件中的第 745 行找到。我们需要理解此处的这个问题是什么，这样就可以决定是否要使用 Apache 2.0 或 IBM HTTP Server 2.0。
Apache 2.0 可以配置为以两种方法运行：采用线程的和不采用线程的。当作为一个采用线程的服务器运行时，服务器中可以同时有多个线程都处于活动状态在执行，一次可以为 多个用户生成响应信息。通常，这样可以提高服务器的响应能力，使其更好地利用具有多个处理器的大型硬件。但是它同时也引入了一种风险。服务器调用的各个软 件层次必须在同时为多个用户调用时都能保证是安全的。尽管 Web 服务器本身、PHP 解释器以及 PHP 扩展以这样调用都是安全的，但是有些 PHP 扩展会使用其他语言（例如 C 语言）编写的库，这些库并不全都是线程安全的。
在 Apache Web 页面上您可以找到一个有关这个问题的讨论，其中给出了一些建议，以及一种用来发现您的 PHP 扩展可能正在使用哪些 C 库以及哪些是线程安全的方法，请参阅参考资料部分。
在 实践中，很多人都会选择回避这个问题，而是采用下面的两种方法：要么以单线程模式使用 Apache 2.0，要么使用 Apache 1.3，它总是以单线程模式运行。虽然 Apache 1.3 和 2.0 也有其他一些区别，例如 Apache 2.0 可以支持 IPv6，但是到目前为止，二者之间最大的区别就是线程的问题，因此保留使用 Apache 1.3 服务器并不像听起来一样是一种退化。
这 个问题在 IBM HTTP Server 中是怎样的呢？IBM 采用线程模式从 Apache 2.0 中编译出了 IBM HTTP Server：这样速度更快，但却可能在使用非线程安全的扩展时是不安全的。由于 IBM 并没有同时发行源代码，而且选择采用线程和不采用线程的模式都是在编译时进行选择的，因此作为一个终端用户来说，您无法选择采用不使用线程的模式重新编译 IBM HTTP Server 2.0。不过在编写本文时，IBM 正在同时发行基于 2.0 和 1.3 版本的 IBM HTTP Server，这样您就可以选择使用单线程的基于 1.3 版本的服务器了。
----------------------------------------------------------------------------------------------------------------------------
关于Apache的MPM【转自apache模块开发指南】
2010年03月16日 星期二 14:23

2.3.1 为什么需要MPM

老版本的NCSA server和Apache 1是在UNIX系统中成长起来的。当时Apache是一个多进程服务器，一个服务进程处理一个用户请求，如果当前并发客户访问数量大于服务进程 数，Apache便会增加新的服务进程来处理当前请求。在正常情况下，Apache会维护一定数量的服务进程来处理用户的请求。

尽管这种多进程服务机 制在Unix类系统中能够很好地工作，但是在其他的平台上效率却很低，如在Windows中产生一个进程是非常费时的。因此，让Apache真正实现跨平 台还需要其他的方法。Apache 2采用的方法是把核心任务处理作为一个可插拔的模块，即MPM，使其能针对不同的环境进行优化。MPM架构允许不同的Apache模块在一个操作系统平台 下共存，能够为用户根据不同应用做出选择。

在实际应用中，只 有UNIX类操作系统有其他的选择，而其他系统平台（Windows、Netware、OS/2、BeOS）则只有唯一的根据操作系统优化的MPM。在 UNIX平台上，Apache 2.2目前已经有两种高质量的、作为标准的MPM（Prefork和Worker），第三种（Eevent方式）在不使用SSL的情况下也是稳定可靠的。 另外还有一些MPM可以实验应用，暂时不适合产品应用。其他第三方的MPM模块也是可用的。

2.3.2 UNIX类的MPM模块

Prefork MPM基于非线程模型，和Apache 1.x版本中的MPM很相似。Prefork MPM在所有情况下都很安全，对运行非线程安全（non-thread-safe）模式的软件如PHP，它是唯一的安全选择。对于某些应用程序，包括在 Apache 1.3上非常流行的程序（如简单静态页面、CGI脚本等），Prefork MPM是最好的选择。
Worker MPM基于线程模式，具有内存消耗低（对繁忙的服务很重要）、扩展性在某些特定应用情况下比Prefork更好等优点。在稍后介绍SQL数据库支持和mod_dbd模块时我们会讨论其中一些内容。
以上两种稳定的MPM方式在非常繁忙的服务器应用下都有些不足。尽管 HTTP的Keepalive方式能减少TCP连接数量和网络负载，但是Keepalive需要和服务进程或者线程绑定，这就导致一个繁忙的服务器会耗光 所有的线程。Event MPM是解决这个问题的一种新模型，它把服务进程从连接中分离出来。在服务器处理速度很快，同时具有非常高的点击率时，可用的线程数量就是关键的资源限 制，此时Event MPM方式是最有效的。一个以Worker MPM方式工作的繁忙服务器能够承受每秒好几万次的访问量（例如在大型新闻服务站点的高峰时），而Event MPM可以用来处理更高负载。值得注意的是，Event MPM不能在安全HTTP（HTTPS）访问下工作。
还有一些针对UNIX系统的、处于实验中的MPM，在本书编写过程 中，它们在继续开发，有的可能已经实现了。Perchild MPM具有一个非常好的特性：以不用的用户ID为不同的虚拟主机运行Apache服务器。其他的一些MPM也提供类似的功能，包括第三方的Metux和 Peruser，以及mod_ruid（只支持Linux）。为了运行外部程序，还可选择fastcgi/mod_fcgid和suexec（CGI）。 作者对第三方的解决方案没有相应的了解，因此不能作出相应的评价。

2.3.3 MPM模块和操作系统

一言以蔽之：对应用程序来说，MPM方式很少见，应该忽略!

既然MPM内部机制不是应用程序接口的一部 分，Apache的应用开发者不需要知道MPM的细节。这里就简单带过。一些为应用开发者提供的最佳实践的基本规则（命名机制、编写安全线程、交叉进程安 全、代码重入）将会在第4章中简单介绍。这里主要介绍开发平台无关代码。事实上，有时应用程序的开发平台更要考虑MPM而不是操作系统。

有时一个应用程序更加适应于某个MPM。例如，数据库驱动或者 负载均衡应用程序得益于thread MPM方式的连接池（在本书稍后讨论）。反之，产生子进程（原始的CGI实现或者mod_ext_filter）在一个基于线程的程序中会产生巨大开销， 因此在Prefork MPM方式下工作得更好。然而，除非某些特殊限制，应用程序应该考虑如何适应在非首选的MPM下工作。

如果你想让Apache运行在现在还不支持Apache的操作系统上，那么首要的任务是在APR库中增加对目标平台的支持。APR库用来提供操作系统层的支持。一个定制的MPM不是必需的，但是它很可能比已有的MPM提供更好的性能。从Apache的角度出发，这

是一个系统编程的任务，因此它已经超出一本应用程序开发书籍的介绍范围。