经过 N 次的跳票和等待，PHP 5.2已于 11 月2 日正式发布。根据 PHP 小组不成文的开发习惯，PHP 5.0 系列更大程度上像一个技术展示版，性能低下（甚至还不如 PHP4，这主要归结与Zend中重写的更加强大也更加复杂的OO机制），稳定性也有所欠缺，目前 PHP 开发组已经放弃了对这个系列的开发。PHP 5.1 系列则侧重于对性能的改善，和 PHP 5.0 系列已经不可同日而语。但随着 PHP5.2系列的发布，PHP5.1也已经和 PHP4.4系列一样进入了维护状态，除非出现重大的BUG和安全隐患否则将不再更新。新发布的 PHP 5.2 除了修复了以往200多个BUG以外，它还将性能进一步提高，尤其是改善了在高负载情况下的表现，而且在安全性的处理上也做出了很大的改进。同时也增加了很多很实用的技术（比如 JSON、Zip等支持），另外还有一些原本定为 PHP6 的特性也已经被提前实现在这个版本当中。可以说，相对于最初的 PHP5 版本，这次的改变几乎是半革命性的（革命性这个形容词当然是留给 PHP6 的J）。下面我自己掌握的一些信息和理解，尝试向大家介绍一下 PHP 5.2的新特性，如有不当之处，还望大家斧正：

1、最明显的当属 PHP 5.2 在移除了filepro 和 hwapi 两个扩展（这两个被移动到了 PECL）的同时另外增加了4个新的扩展：Date、JOSN、Filter和ZIP。 其实从 PHP 5.1 开始，在 PHP 核心增加了一个 Date 扩展，重写了对日期/时间（主要是时区方面）的支持。所不同的是，PHP 5.2 更进一步，日期和时区则分别成为了类 DateTime 和 DateTimeZone 的一个对象。大家可以在 PHP CLI 中运行php –rc DateTime 或 php –rc DateTimeZone 来看一下这两个类的详细信息。需要注意的是如果你的程序中已经存在有名为DateTime 或 DateTimeZone 类的话，那想在 PHP 5.2 中运行就必须改名了。(著名的开源 CRM ：vtigercrm 已经有了前车之鉴)JSON 扩展实现了则实现对 JavaScript Object Notation (JSON) 这种轻量级数据交换格式的支持。在 PHP 5.2 中这个扩展是默认被启用的。

相信很多开发人员都为 PHP与 JavaScript 之间的通信发愁过，尤其是现在这个流行 Ajax 的时代。而现在，我们用JSON 就可以很轻易的解决这个问题。JSON数据能够直接为服务器端代码使用, 并且也能够让客户端的 JavaScript简单地通过 eval() 来进行读取，这就大大简化了服务器端和客户端的代码开发量。虽然以前在 PHP 里面也有一些 JSON 类来支持，但这哪有 PHP 的原生支持来得高效和快捷呢？ Filter 扩展负责校验和过滤数据，这个扩展主要是为了处理像用户的输入那样的不可靠数据而设计的。这个扩展也是默认被启用的。默认情况下的RAW 模式将不会以任何方式影响输入的数据，也就是说这不会对现有代码产生任何影响。但我们在以后的开发中应该尽可能地利用这个扩展来进行敏感字符的过滤，因为这不但简化了一些表单的验证工作，而且提高了程序的安全性和运行效率。 ZIP 扩展将允许我们对 Zip 压缩包及其包内的文件进行读写操作。也就是说，我们对 Zip文件不仅能看，而且还能摸：它提供了对 Zip 文件的完全支持。这项特性的应用是非常广泛的，具体带来的种种好处我就不再多说了。 当然，关于这些扩展的具体细节还得查阅我们无所不能的 PHP 手册。

2、改进了内存管理器，使之在高负载情况下具有更佳的表现。
按照 “Zend 二老”之一也就是 “Zend”中那个“nd”的说法，这个新的内存管理器是分层（hierarchical）的。这个管理器共有三层：存储层（storage）、堆（heap）层和emalloc/efree层。存储层通过malloc()、mmap()等函数向系统真正的申请内存，并通过 free() 函数释放所申请的内存。存储层相当于Zend 自己的“内存仓库”，通常申请的内存块都比较大。堆层（注意这里的堆并不是指操作系统所管理的堆，而是 Zend 内存管理器的所管理的内存堆）就把它们从存储层要过来并分割成一些较小的块。而 emalloc/efree层就是指通过 PHP API的emalloc()/efree() 函数所申请和释放的内存。emalloc() 并不直接同存储层打交道，同它们接头的是堆层。负责把比原来的管理器在同等条件下会分配更小的内存，但速度更快。它首先会从系统（堆）中申请一些较大的内存块，然后自己来管理这个堆。php.ini 中的memory_limit 值虽然还会被检用，但已不再是每次emalloc() 调用时都检用，而仅仅是在向系统申请那些大的内存块时被检用。

熟悉一些服务器端编程的朋友可能会马上想到一个词：内存池！没错，这基本上就是一个内存池。至少我是这么认为的。 内存池技术其实这是服务端编程中很常见。使用内存池技术可以有效地避免频繁的内存申请/释放操作，在内存池技术中，内存释放时实际上并没有通知操作系统真实的释放和回收，而仅仅是对将要释放的内存做个了标记，表示该部分内存已经不再使用。等下一次申请内存时，就从这些“可用”的内存链表中取出一个内存块，从而避免了频繁的内存申请/释放操作，大大节省了系统资源。根据测试和统计，在 PHP 4.4版本中，一个典型的较为简单的请求就有超过 20,000次的对系统堆的申请和释放操作，这花费的时间相当于整个脚本所花费时间的 20% 左右。由此可见，若能降低这种资源消耗则效果是极为可观的。
与此同时，采用内存池技术也带来一个更为重要的“副作用”：避免了大量的“内存碎片”。一般情况下，内存碎片是对系统没有多大影响的，但服务端应用明显不同于一般应用，服务端会面临很高数量级的访问请求，这些请求也伴随着更高数量级的内存申请/释放操作。内存碎片过多将导致内存利用率降低，降低内存分配速度，严重时还会触发内存分配失败，尽管此时理论上仍有可分配的物理内存。