参数解释：

nTableSize  哈希表的大小

nTableMask  数值上等于nTableSize -1 

nNumOfElements 记录了当前HashTable中保存的记录数

nNextFreeElement  指向下一个空闲的Bucket（之后有解释）

pInternalPointer 

pListHead  指向Bucket列表头部

pListTail    指向Bucket列表尾部

arBuckets

pDestructor   一个函数指针，在HashTable发生增、删、改时自动调用，以完成某些清理工作。

persistent   是否是持久

nApplyCount

aApplyProtection 这两个参数用于放置在遍历时发生无限递归

可以看到Bucket是一个双向链表，参数解释：

h  当元素使用数字索引时使用

nKeyLength  当使用字符串索引时，该选项表示字符串索引的长度，而字符串则保存在Bucket结构体的最后一个元素arKey中。尽管arKey被声明为一个只有一个元素的数组，但是这并不妨碍我们在其中保存字符串，因为数组名可以看做指针，将arKey作为结构体的最后一个元素则Bucket结构体就成了变长结构体，而该变长结构体的长度则需要nKeyLength的辅助才能确定，这是C语言中的常见技巧。

pNext指向具有相同hash值的下一个bucket元素，无论HashTable设计的如何完美，冲突都是难免的。当采用字符串索引时，h成员变量存放的就是字符串索引的hash值。

pData指向保存的数据，如果数据本身又为指针，则用pDataPtr来保存对应的指针，而辞此时pData则指向自身结构体的pDataPtr。

接着看Zend HashTable的一些相关函数:

#define HASH_PROTECT_RECURSION(ht) \

if ((ht)->bApplyProtection) { \

if ((ht)->nApplyCount++ >= 3) { \

zend_error(E_ERROR, "Nesting level too deep - recursive dependency?"); \

} \

}

这个宏用于防止循环引用。

#define ZEND_HASH_IF_FULL_DO_RESIZE(ht) \

if ((ht)->nNumOfElements > (ht)->nTableSize) { \

zend_hash_do_resize(ht); \

}

该宏用于判断HashTable中的元素是否超过了HashTable表的大小，如果超过则扩展HashTable的大小，查看zend_hash_do_resize的代码可以看到每次扩展大小都是成倍的。

看看Zend HashTable是如何初始化的

ZEND_API int _zend_hash_init(HashTable *ht, uint nSize, hash_func_t pHashFunction, dtor_func_t pDestructor, zend_bool persistent ZEND_FILE_LINE_DC)

{

uint i = 3; //这里可以看出数组默认的初始化为8

Bucket **tmp;

SET_INCONSISTENT(HT_OK);   // 用于调试 

if (nSize >= 0×80000000) {

/* prevent overflow */

ht->nTableSize = 0×80000000;

} else {

while ((1U << i) < nSize) {

i++;

}

ht->nTableSize = 1 << i;

}

ht->nTableMask = ht->nTableSize - 1;

ht->pDestructor = pDestructor;

ht->arBuckets = NULL;

ht->pListHead = NULL;

ht->pListTail = NULL;

ht->nNumOfElements = 0;

ht->nNextFreeElement = 0;

ht->pInternalPointer = NULL;

ht->persistent = persistent;

ht->nApplyCount = 0;

ht->bApplyProtection = 1;

/* Uses ecalloc() so that Bucket* == NULL */

if (persistent) {

tmp = (Bucket **) calloc(ht->nTableSize, sizeof(Bucket *));

if (!tmp) {

return FAILURE;

}

ht->arBuckets = tmp;

} else {

tmp = (Bucket **) ecalloc_rel(ht->nTableSize, sizeof(Bucket *));

if (tmp) {

ht->arBuckets = tmp;

}

}

return SUCCESS;

}

可以看到HashTable的大小被自动的初始化为2的n次方，persistent参数用于指示是否是“永久”方式分配内存，如果是则采用系统分配内存方法，否则采用ZendMM的内存分配方式，关于ZendMM请搜索PHP内存管理的相关内容。

申请得到的bucket指针内存块都放在HashTable的arBucket中，可以把这段内存块看成一个数组，数组中的每个元素都指向一个实际的bucket。

ZEND_API int _zend_hash_add_or_update(HashTable *ht, char *arKey, uint nKeyLength, void *pData, uint nDataSize, void **pDest, int flag ZEND_FILE_LINE_DC)

{

ulong h;

uint nIndex;

Bucket *p;

IS_CONSISTENT(ht);

if (nKeyLength <= 0) {

#if ZEND_DEBUG

ZEND_PUTS("zend_hash_update: Can’t put in empty key\n");

#endif

return FAILURE;

}

//根据索引值和索引长度生成hash值

h = zend_inline_hash_func(arKey, nKeyLength);

//用hash值和nTableMask进行按位于运算，用于索引的快速定位

//按位于后的结果不可能大于nTableMask的值

//结合下面的代码，可以看出这段代码的巧妙

nIndex = h & ht->nTableMask;

p = ht->arBuckets[nIndex];

//如果p不为NULL，则产生了hash冲突

while (p != NULL) {

if ((p->h == h) && (p->nKeyLength == nKeyLength)) {

if (!memcmp(p->arKey, arKey, nKeyLength)) {

if (flag & HASH_ADD) {

return FAILURE;

}

HANDLE_BLOCK_INTERRUPTIONS();

#if ZEND_DEBUG

if (p->pData == pData) {

ZEND_PUTS("Fatal error in zend_hash_update: p->pData == pData\n");

HANDLE_UNBLOCK_INTERRUPTIONS();

return FAILURE;

}

#endif

//到了这里就说明是更新操作

//先调用原来的析构函数执行清理

if (ht->pDestructor) {

ht->pDestructor(p->pData);

}

UPDATE_DATA(ht, p, pData, nDataSize);

if (pDest) {

*pDest = p->pData;

}

HANDLE_UNBLOCK_INTERRUPTIONS();

return SUCCESS;

}

}

p = p->pNext;

}

//来到这里说明是增加元素操作

p = (Bucket *) pemalloc(sizeof(Bucket) - 1 + nKeyLength, ht->persistent);

if (!p) {

return FAILURE;

}

memcpy(p->arKey, arKey, nKeyLength);

p->nKeyLength = nKeyLength;

INIT_DATA(ht, p, pData, nDataSize);

p->h = h;

CONNECT_TO_BUCKET_DLLIST(p, ht->arBuckets[nIndex]);

if (pDest) {

*pDest = p->pData;

}

HANDLE_BLOCK_INTERRUPTIONS();

CONNECT_TO_GLOBAL_DLLIST(p, ht);

ht->arBuckets[nIndex] = p;

HANDLE_UNBLOCK_INTERRUPTIONS();

ht->nNumOfElements++;

ZEND_HASH_IF_FULL_DO_RESIZE(ht); /* If the Hash table is full, resize it */

return SUCCESS;

}

看到这里就可以发现多数代码都是类似的了，

#define CONNECT_TO_BUCKET_DLLIST(element, list_head) \

(element)->pNext = (list_head); \

(element)->pLast = NULL; \

if ((element)->pNext) { \

(element)->pNext->pLast = (element); \

}

这个宏用于将一个bucket加入到bucket链表中

#define CONNECT_TO_GLOBAL_DLLIST(element, ht) \

(element)->pListLast = (ht)->pListTail; \

(ht)->pListTail = (element); \

(element)->pListNext = NULL; \

if ((element)->pListLast != NULL) { \

(element)->pListLast->pListNext = (element); \

} \

if (!(ht)->pListHead) { \

(ht)->pListHead = (element); \

} \

if ((ht)->pInternalPointer == NULL) { \

(ht)->pInternalPointer = (element); \

}

该宏用于将一个bucket加入到HashTable的链表中

在PHP中可以使用函数 debug_zval_dump($var); 查看变量的引用信息。

 相对于PHP的内核而已，我们编写的PHP代码都属于“用户空间”(user space)，用户空间中的任何PHP变量都是由两部分组成：变量名(label)和变量值，从上面已经看到变量值存放在zval结构体中，那么变量名是放在哪里的呢？ 下篇将继续分析PHP的HashTable结构体。

说明：本文中的图片均截自Marcus BörgerWez， FurlongSara， Golemon 三人的PHP ENTENSION WRITING （OSCON 2007）

在PHP 5.2.6中源码稍有不同，不过含义一样，无关大雅。

refcount用来表示有多少个变量指向本结构体，is_ref用来标示是否是引用。看两个例子：

$a = 5;

$b = $a;

$b = 10;

$a = 5   =>  value.lval = 5, refcount = 1, type = IS_LONG, is_ref = 0

$b = $a  =>  value.lval = 5, refcount = 2, type = IS_LONG, is_ref = 0

$b = 10  =>  1  value.lval = 5, refcount = 1, type = IS_LONG, is_ref = 0   $a

             2  value.lval = 10, refcount = 1, type = IS_LONG, is_ref = 0   $b

在第三步时，PHP又产生了一个新的结构体用于保存变量$b， 原因在于原来$b指向的结构体的is_ref 成员的值为0. 这就是PHP的Copy on Write机制。

再看下一种情况：

$a = 123;

$b = &$a;

$b = 456;

则按下图保存

1.进程初始化

在模块的MINIT过程中可以添加你自定义的常量、变量、类、资源、流以及Filter句柄等等。

2.接受请求

3.解析编译运行代码

Zend Engine首先将代码编译成Zend Opcode，然后再使用Zend虚拟机来解释执行。

4.请求结束

5.进程退出

使用php的memcache扩展时，如果给set/get方法传递一个空值（NULL），则会导致memcached服务端主动关闭连接，见如下的代码示范：
 

$mem = new Memcache();

$mem->connect(’192.168.64.12′, ’11211′);

$mem->set(‘aaa’, array(‘aaa’)); //成功

$mem->set($aaaa, ‘aaaa’); //失败，并导致到memcached服务器的连接丢失，所以之后的方法都失败了（返回false）

$mem->set(‘bbb’, array(‘bbb’));//失败

$mem->get(‘aaa’);//失败

没有测试memcached扩展是否有过这样的bug。
顺便提一下在PHP中memcached和memcache是两个不同的扩展，区别是memcached基于libmemcached库封装的API接口。见PHP手册
This extension uses libmemcached library to provide API for communicating with memcached servers. It also provides a session handler (memcached).

而通常所说的memcached就是指memcached服务器端。

另外如果key过长（250以上），value过大（1M以上）或者过期时间过长（大于2592000）都会导致set失败。

整理一下两个月的收获和问题，说的不全，完全以这段时间的实践为主线。

一 面向对象 VS 面向过程
1.我们的选择
项目开始时，技术经理那边决定使用面向过程作为我们的主要开发方式，当时主要的考虑点是效率和项目人员对OO和面向过程的熟悉程度。
我们的项目是一个交易平台，预计并发、高负载、快速响应会是项目最重要的问题，再结合PHP本身的特点，我们觉得面向过程应该是我们的更好选择。
另外，项目中，除了我本人接触的OO较多外，其他人对于OO的理解还仅仅位于“对象”上， 对OOA/OOD/Design Pattern等基本无概念，而由于我们的时间和现有资源的问题，我们也不可能进行这方面的入职培训。 所以最终我们决定使用面向过程。

2.如何选择
很多人大谈OO或者面向过程的好处，互相攻击对方的方法缺陷。就讨论本身而言，辩论有利于更好的交流以及对知识更深层次的理解。但也容易带来一些偏见，这些往往是由于个人的阅历经验、对新事物的心态以及是否辩证看待事物有关。每个人的工作环境、项目要求等等都不尽相同，而OO和面向过程都不是万能的解决方案，他们有各自的优缺点，有各自的适应环境（所以不能一概而论， 不能断定哪种方式绝对的好），同时也有重叠的部分（既然有重叠，那么在某些情况下使用OO和面向过程皆可，具体使用哪一种，主要取决于个人的偏好）。
因而我们讨论两种方法，重点在于分析他们各自的利弊、适应环境，而不是打败对方。我们的目的在于赢得真理， 而不是赢得讨论。无论枪有多好，刀也不会淘汰；同时枪也的确比刀强大很多—某些情况下。
以下我的一些粗浅的个人理解，用于快速的判断实际应该如何选择。限于经验和个人水平，如有不妥甚至错误的地方，欢迎指出来。
* 面向对象有利于直接将现实中的“对象”移植过来，而面向过程则有利于直接应用我们生活中最常见的“过程式”思想。但是希望大家明白，现实世界并非完全“对象”，也并非完全的“过程”。当你的项目比较简单，业务逻辑也比较简单的情况下，面向过程可能是更加快速的选择，因为在这种情况下，你不必考虑太多的类设计，简单的“一步步来”即可。如果你的业务逻辑相当的复杂，在很多地方可能会大量的重用某些逻辑处理，你们的团队相当的庞大，你们需要紧密的合作等等，此时OO的优势将会非常明显。
* 项目要求和项目环境。如果你的PHP版本过低（如PHP4甚至PHP3），由于语言本身对面向对象的支持不够好，某些本来是面向对象的优点也会变成缺点，同时很多面向对象的特性也不能应用，这个时候再坚持OO就不是个好的选择了。 或者更干脆你用的是想C语言这样的完全不支持OO的编程语言，那么什么也别想了 —–  你想煮饭，首先得要有米才行。
* 应用某方式的成本。就像我们的团队一样，并非每个人都能理解OO，即使理解，理解程度也不尽相同，这可能会为大家的合作、项目的维护等带来不便。所以很多公司都有入职培训，不管你水平如何，大家一起培训，争取将大家调整到一个相近的水平线上。这需要时间、资金以及人力的投入，有时候最优的技术选择并不见得是最好的选择。
这里只能简单的列出几点判断要点，详细说的话，几本书也说不完，欢迎大家继续和我交流论坛。

PHP面向过程项目的一些细节
模板
对于一个稍有规模的网站（如何判断是没有标准的），页面显示和业务逻辑分离是一个非常重要的问题，可以说它在一定程度上决定了我们的项目的工作效率。对于很多程序员来说，编写程序的同时还要处理HTML，css，js等是一个嫉妒可怕的噩梦。可悲的是，目前为止并没有一种很好的解决方案能使得PHP程序员完全摆脱这种局面；可喜的是，我们已经有比较折中的方案：模板。
模板可以说是无数PHP程序员甚至是美工的救世主，它很方便的分离了页面显示和业务逻辑 —- 当然它不可能完全分离的开来，不过总归是比之前好太多了。比较有名如Smarty，PHPLib Template等等，前者属于编译型，后者则属解释型，各有优点，有兴趣可以搜索下。

  在我们的项目中，网站有公共的头部和尾部，准确的来说，有两个公共的头部和一个尾部，如果头部和尾部都唯一的话相对来说就简单一些了。
还是考虑到我们的网站对性能上的要求，我们决定不采用任何模板技术，或者说我们决定采用内嵌PHP代码方式的模板。大家先来看下面的代码：
 

Smarty方式：

<{foreach name=results from=$results item=result}>

<b><{$result.name}></b>

<b><{$result.id}></b>

<{/foreach}>

使用HereDoc：

<!–

EOT;

foreach($results as $value){print<<<EOT

–>

<b>{$value['name']}</b>

<b>{$value['id']}</b>

<!–

EOT;

}

–>嵌入html代码：

<?php

foreach($results as $value){

?>

<b><?php echo $value['name'];?></b>

<b><?php echo $value[id];?></b>

<?php

}

?>

上面的代码很简单，从一个表中取出用户列表，然后循环显示。代码一和代码二的功能实际上时一样的，不同的是代码1采用了模板（smarty语法），代码2采用了PHP原生语法（heredoc）。我们可以看到我们用原生的语法完成了模板所对应的功能，并且代码也同样的简单。可能有人说，smarty可以编译，可以缓存，有很多辅助函数，这些你通过简单的代码能够实现吗？
对于上面的问题，我的看法如下：
* 我认为smarty这种编译型模板提供的诸多额外函数做了过多的事情。在MVC模式下，这些函数所做的事情已经超出了V层的职责，会导致更换V层时，重复的编写一些代码，例如将V层从HTML换成WAP或者XML。当然这一点并不能使得我们做出放弃smarty的决定，因为项目不见得采用MVC模式开发，同时你也可以避免使用Smarty的某些函数。
* 几乎所有模板都使用自己的一套语法，学习代价高。smarty3已经使用PHP的原生语法了。
* 很多项目实时性要求相当高（我们的项目就是如此），采用编译型模板会导致数据不能及时显示，而且因为更新快，它的编译功能将变成鸡肋。而解释型模板由于不缓存结果（如果你给解释型模板提供缓存功能的话，那另当别论），每次请求都重新解释，效率不高、资源消耗相对较多。
*根据前面三点，我们发现PHP本身就能够完成我们要求的功能。

我的看法带有片面性，因为我主要是就着我当前的项目来讨论的。

对于模块下公共文件的重复利用的问题，我们使用ob系列的函数来替换即可，PHP中字符串替换的效率是相当高的（尽量不要用正则）。

纯粹的面向过程吗？
我们的项目属于大中型的项目，实际编码中发现有大量的重复代码，我们的业务逻辑相当的复杂（特别是在线支付模块），这个时候我们简单了考虑了一下便决定适当的使用一些对象（当然，这还称不上OO）。我们不是纯粹的面向对象狂热者，同样也不是面向过程狂热者，只有最合适的，没有最好的。

项目成功≠技术先进
其实这不属于面向过程的专属内容，它应该是超越开发方法的。不管你采用哪种方法开始，项目的完成才是最重要的，技术不能代表和决定一切，现实和理想总是有所相隔。代码可以重构，而项目可能没有机会进行第二次。大家要把握平衡点。
 

1.
php的应用主要在于数据库应用, 所以一个应用中会存在大量的数据库操作, 在使用面向对象的方式开发时(废话), 如果使用单例模式, 则可以避免大量的new 操作消耗的资源.

2.
如果系统中需要有一个类来全局控制某些配置信息, 那么使用单例模式可以很方便的实现. 这个可以参看zend Framework的FrontController部分.

3.
在一次页面请求中, 便于进行调试, 因为所有的代码(例如数据库操作类db)都集中在一个类中, 我们可以在类中设置钩子, 输出日志.避免到处var_dump, echo.

*优化了结果信息提示
*更改了默认构造函数的实现，方便参数传递
+增加文件保存路径统计，文件上传数目统计

代码下载

更新日志：
2007-04-11 20:40 , v 1.0.1
*改进了文件类型识别方式

代码下载

系统环境：Windows XP SP2 + php 5.2.1 + mysql 5.0 + Apache 2.2.24
开发环境：Zend Studio 5.5
参数： safe_mode = Off
error_reporting = E_ALL & ~E_NOTICE
register_globals =Off
magic_quotes_runtime = Off

——————————————————————————–

nd_formheader = '
';
   $this->nd_formmaxFileSize = $maxfilesize;
   $this->nd_formend = '

';
 }

 function appendInput($type, $name, $value)
 {
   $tmp = '
';
   echo $tmp."\n";
 }

 function formHeader()
 {
   echo $this->nd_formheader."\n";
 }

 function formMaxSize()
 {
   $size = '
';
   echo $size."\n";
 }

 function formEnd()
 {
   echo $this->nd_formend."\n";
 }
}
?>

可以和之前发的php上传类配合使用，我一起发上来。

 Demo代码：

setDir('./upload/');
 $upfile->copyFile();
 $upfile->showError();
}

?>







formHeader();
$form->appendInput("file", "file", "浏览");
$form->appendInput("hidden", "upfile", "upfile");
$form->formMaxSize();
$form->appendInput("submit", "submit", "上传");
$form->formEnd();
?>

NdForm

这段代码相信熟悉php的朋友大概都比较熟悉，但是我使用的时候却发现这段代码并没有被执行而是直接打印出来了，检查了一下其他地方没有错误。实在郁闷。去网上找资料，呵呵，看到一句话：EOT 自定义分界符，结束时必须位于行首 。呵呵，原来要求一定要在一行的开始，没想到保持代码风格反而引出了一个小问题。 最后更新: 2009-05-07