最近在看《PHP 内核剖析》,关于 PHP 数组方面有所得,特此撰文一篇总结记录 (∩_∩)。由于 PHP 的数组是很强大且很重要的数据类型,它既支持单纯的数组又支持键值对数组,其中键值对数组相似于 Go 语言的 map
但又保证了可以按顺序遍历,而且因为采用了哈希表实现可以保证基本查找时间复杂度为 O(1)。因此接下来让咱们了解一下 PHP 数组的底层实现吧~php
一个数组在 PHP 内核里是长什么样的呢?咱们能够从 PHP 的源码里看到其结构以下:html
// 定义结构体别名为 HashTable
typedef struct _zend_array HashTable;
struct _zend_array {
// gc 保存引用计数,内存管理相关;本文不涉及
zend_refcounted_h gc;
// u 储存辅助信息;本文不涉及
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar flags,
zend_uchar nApplyCount,
zend_uchar nIteratorsCount,
zend_uchar consistency)
} v;
uint32_t flags;
} u;
// 用于散列函数
uint32_t nTableMask;
// arData 指向储存元素的数组第一个 Bucket,Bucket 为统一的数组元素类型
Bucket *arData;
// 已使用 Bucket 数
uint32_t nNumUsed;
// 数组内有效元素个数
uint32_t nNumOfElements;
// 数组总容量
uint32_t nTableSize;
// 内部指针,用于遍历
uint32_t nInternalPointer;
// 下一个可用数字索引
zend_long nNextFreeElement;
// 析构函数
dtor_func_t pDestructor;
};
复制代码
nNumUsed
和 nNumOfElements
的区别:nNumUsed
指的是 arData
数组中已使用的 Bucket
数,由于数组在删除元素后只是将该元素 Bucket
对应值的类型设置为 IS_UNDEF
(由于若是每次删除元素都要将数组移动并从新索引太浪费时间),而 nNumOfElements
对应的是数组中真正的元素个数。nTableSize
数组的容量,该值为 2 的幂次方。PHP 的数组是不定长度但 C 语言的数组定长的,为了实现 PHP 的不定长数组的功能,采用了「扩容」的机制,就是在每次插入元素的时候判断 nTableSize
是否足以储存。若是不足则从新申请 2 倍 nTableSize
大小的新数组,并将原数组复制过来(此时正是清除原数组中类型为 IS_UNDEF
元素的时机)而且从新索引。nNextFreeElement
保存下一个可用数字索引,例如在 PHP 中 $a[] = 1;
这种用法将插入一个索引为 nNextFreeElement
的元素,而后 nNextFreeElement
自增 1。_zend_array
这个结构先讲到这里,有些结构体成员的做用在下文会解释,不用紧张O(∩_∩)O哈哈~。下面来看看做为数组成员的 Bucket
结构:git
typedef struct _Bucket {
// 数组元素的值
zval val;
// key 经过 Time 33 算法计算获得的哈希值或数字索引
zend_ulong h;
// 字符键名,数字索引则为 NULL
zend_string *key;
} Bucket;
复制代码
咱们知道 PHP 数组是基于哈希表实现的,而与通常哈希表不一样的是 PHP 的数组还实现了元素的有序性,就是插入的元素从内存上来看是连续的而不是乱序的,为了实现这个有序性 PHP 采用了「映射表」技术。下面就经过图例说明咱们是如何访问 PHP 数组的元素 :-D。github
注意:由于键名到映射表下标通过了两次散列运算,为了区分本文用哈希特指第一次散列,散列即为第二次散列。算法
由图可知,映射表和数组元素在同一片连续的内存中,映射表是一个长度与存储元素相同的整型数组,它默认值为 -1 ,有效值为 Bucket
数组的下标。而 HashTable->arData
指向的是这片内存中 Bucket
数组的第一个元素。数组
举个例子 $a['key']
访问数组 $a
中键名为 key
的成员,流程介绍:首先经过 Time 33 算法计算出 key
的哈希值,而后经过散列算法计算出该哈希值对应的映射表下标,由于映射表中保存的值就是 Bucket
数组中的下标值,因此就能获取到 Bucket
数组中对应的元素。函数
如今咱们来聊一下散列算法,就是经过键名的哈希值映射到「映射表」的下标的算法。其实很简单就一行代码:post
nIndex = h | ht->nTableMask;
复制代码
将哈希值和 nTableMask
进行或运算便可得出映射表的下标,其中 nTableMask
数值为 nTableSize
的负数。而且因为 nTableSize
的值为 2 的幂次方,因此 h | ht->nTableMask
的取值范围在 [-nTableSize, -1]
之间,正好在映射表的下标范围内。至于为什么不用简单的「取余」运算而是费尽周折的采用「按位或」运算?由于「按位或」运算的速度要比「取余」运算要快不少,我以为对于这种频繁使用的操做来讲,复杂一点的实现带来的时间上的优化是值得的。学习
不一样键名的哈希值经过散列计算获得的「映射表」下标有可能相同,此时便发生了散列冲突。对于这种状况 PHP 使用了「链地址法」解决。下图是访问发生散列冲突的元素的状况:优化
这看似与第一张图差很少,但咱们一样访问 $a['key']
的过程多了一些步骤。首先经过散列运算得出映射表下标为 -2 ,而后访问映射表发现其内容指向 arData
数组下标为 1 的元素。此时咱们将该元素的 key
和要访问的键名相比较,发现二者并不相等,则该元素并不是咱们所想访问的元素,而元素的 val.u2.next
保存的值正是下一个具备相同散列值的元素对应 arData
数组的下标,因此咱们能够不断经过 next
的值遍历直到找到键名相同的元素或查找失败。
插入元素的函数 _zend_hash_add_or_update_i
,基于 PHP 7.2.9 的代码以下:
static zend_always_inline zval *_zend_hash_add_or_update_i(HashTable *ht, zend_string *key, zval *pData, uint32_t flag ZEND_FILE_LINE_DC)
{
zend_ulong h;
uint32_t nIndex;
uint32_t idx;
Bucket *p;
IS_CONSISTENT(ht);
HT_ASSERT_RC1(ht);
if (UNEXPECTED(!(ht->u.flags & HASH_FLAG_INITIALIZED))) { // 数组未初始化
// 初始化数组
CHECK_INIT(ht, 0);
// 跳转至插入元素段
goto add_to_hash;
} else if (ht->u.flags & HASH_FLAG_PACKED) { // 数组为连续数字索引数组
// 转换为关联数组
zend_hash_packed_to_hash(ht);
} else if ((flag & HASH_ADD_NEW) == 0) { // 添加新元素
// 查找键名对应的元素
p = zend_hash_find_bucket(ht, key);
if (p) { // 若相同键名元素存在
zval *data;
/* 内部 _zend_hash_add API 的逻辑,能够忽略 */
if (flag & HASH_ADD) { // 指定 add 操做
if (!(flag & HASH_UPDATE_INDIRECT)) { // 若不容许更新间接类型变量则直接返回
return NULL;
}
// 肯定当前值和新值不一样
ZEND_ASSERT(&p->val != pData);
// data 指向原数组成员值
data = &p->val;
if (Z_TYPE_P(data) == IS_INDIRECT) { // 原数组元素变量类型为间接类型
// 取间接变量对应的变量
data = Z_INDIRECT_P(data);
if (Z_TYPE_P(data) != IS_UNDEF) { // 该对应变量存在则直接返回
return NULL;
}
} else { // 非间接类型直接返回
return NULL;
}
/* 通常 PHP 数组更新逻辑 */
} else { // 没有指定 add 操做
// 肯定当前值和新值不一样
ZEND_ASSERT(&p->val != pData);
// data 指向原数组元素值
data = &p->val;
// 容许更新间接类型变量则 data 指向对应的变量
if ((flag & HASH_UPDATE_INDIRECT) && Z_TYPE_P(data) == IS_INDIRECT) {
data = Z_INDIRECT_P(data);
}
}
if (ht->pDestructor) { // 析构函数存在
// 执行析构函数
ht->pDestructor(data);
}
// 将 pData 的值复制给 data
ZVAL_COPY_VALUE(data, pData);
return data;
}
}
// 若是哈希表已满,则进行扩容
ZEND_HASH_IF_FULL_DO_RESIZE(ht);
add_to_hash:
// 数组已使用 Bucket 数 +1
idx = ht->nNumUsed++;
// 数组有效元素数目 +1
ht->nNumOfElements++;
// 若内部指针无效则指向当前下标
if (ht->nInternalPointer == HT_INVALID_IDX) {
ht->nInternalPointer = idx;
}
zend_hash_iterators_update(ht, HT_INVALID_IDX, idx);
// p 为新元素对应的 Bucket
p = ht->arData + idx;
// 设置键名
p->key = key;
if (!ZSTR_IS_INTERNED(key)) {
zend_string_addref(key);
ht->u.flags &= ~HASH_FLAG_STATIC_KEYS;
zend_string_hash_val(key);
}
// 计算键名的哈希值并赋值给 p
p->h = h = ZSTR_H(key);
// 将 pData 赋值该 Bucket 的 val
ZVAL_COPY_VALUE(&p->val, pData);
// 计算映射表下标
nIndex = h | ht->nTableMask;
// 解决冲突,将原映射表中的内容赋值给新元素变量值的 u2.next 成员
Z_NEXT(p->val) = HT_HASH(ht, nIndex);
// 将映射表中的值设为 idx
HT_HASH(ht, nIndex) = HT_IDX_TO_HASH(idx);
return &p->val;
}
复制代码
前面将数组结构的时候咱们有提到扩容,而在插入元素的代码里有这样一个宏 ZEND_HASH_IF_FULL_DO_RESIZE
,这个宏其实就是调用了 zend_hash_do_resize
函数,对数组进行扩容并从新索引。注意:并不是每次 Bucket
数组满了都须要扩容,若是 Bucket
数组中 IS_UNDEF
元素的数量占较大比例,就直接将 IS_UNDEF
元素删除并从新索引,以此节省内存。下面咱们看看 zend_hash_do_resize
函数:
static void ZEND_FASTCALL zend_hash_do_resize(HashTable *ht) {
IS_CONSISTENT(ht);
HT_ASSERT_RC1(ht);
if (ht->nNumUsed > ht->nNumOfElements + (ht->nNumOfElements >> 5)) { // IS_UNDEF 元素超过 Bucket 数组的 1/33
// 直接从新索引
zend_hash_rehash(ht);
} else if (ht->nTableSize < HT_MAX_SIZE) { // 数组大小 < 最大限制
void *new_data, *old_data = HT_GET_DATA_ADDR(ht);
// 新的内存大小为原来的两倍,采用加法是由于加法快于乘法
uint32_t nSize = ht->nTableSize + ht->nTableSize;
Bucket *old_buckets = ht->arData;
// 申请新数组内存
new_data = pemalloc(HT_SIZE_EX(nSize, -nSize), ht->u.flags & HASH_FLAG_PERSISTENT);
// 更新数组结构体成员值
ht->nTableSize = nSize;
ht->nTableMask = -ht->nTableSize;
HT_SET_DATA_ADDR(ht, new_data);
// 复制原数组到新数组
memcpy(ht->arData, old_buckets, sizeof(Bucket) * ht->nNumUsed);
// 释放原数组内存
pefree(old_data, ht->u.flags & HASH_FLAG_PERSISTENT);
// 从新索引
zend_hash_rehash(ht);
} else { // 数组大小超出内存限制
zend_error_noreturn(E_ERROR, "Possible integer overflow in memory allocation (%u * %zu + %zu)", ht->nTableSize * 2, sizeof(Bucket) + sizeof(uint32_t), sizeof(Bucket));
}
}
复制代码
从新索引的逻辑在 zend_hash_rehash
函数中,代码以下:
ZEND_API int ZEND_FASTCALL zend_hash_rehash(HashTable *ht) {
Bucket *p;
uint32_t nIndex, i;
IS_CONSISTENT(ht);
if (UNEXPECTED(ht->nNumOfElements == 0)) { // 数组为空
if (ht->u.flags & HASH_FLAG_INITIALIZED) { // 已初始化
// 已使用 Bucket 数置 0
ht->nNumUsed = 0;
// 映射表重置
HT_HASH_RESET(ht);
}
// 返回成功
return SUCCESS;
}
// 映射表重置
HT_HASH_RESET(ht);
i = 0;
p = ht->arData;
if (HT_IS_WITHOUT_HOLES(ht)) { // Bucket 数组所有为有效值,没有 IS_UNDEF
// ----------------------------
// 遍历数组,从新设置映射表的值
do {
nIndex = p->h | ht->nTableMask;
Z_NEXT(p->val) = HT_HASH(ht, nIndex);
HT_HASH(ht, nIndex) = HT_IDX_TO_HASH(i);
p++;
} while (++i < ht->nNumUsed);
// ----------------------------
} else {
do {
if (UNEXPECTED(Z_TYPE(p->val) == IS_UNDEF)) { // 当前 Bucket 类型为 IS_UNDEF
uint32_t j = i;
Bucket *q = p;
if (EXPECTED(ht->u.v.nIteratorsCount == 0)) {
// 移动数组覆盖 IS_UNDEF 元素
while (++i < ht->nNumUsed) {
p++;
if (EXPECTED(Z_TYPE_INFO(p->val) != IS_UNDEF)) {
ZVAL_COPY_VALUE(&q->val, &p->val);
q->h = p->h;
nIndex = q->h | ht->nTableMask;
q->key = p->key;
Z_NEXT(q->val) = HT_HASH(ht, nIndex);
HT_HASH(ht, nIndex) = HT_IDX_TO_HASH(j);
if (UNEXPECTED(ht->nInternalPointer == i)) {
ht->nInternalPointer = j;
}
q++;
j++;
}
}
} else {
uint32_t iter_pos = zend_hash_iterators_lower_pos(ht, 0);
// 移动数组覆盖 IS_UNDEF 元素
while (++i < ht->nNumUsed) {
p++;
if (EXPECTED(Z_TYPE_INFO(p->val) != IS_UNDEF)) {
ZVAL_COPY_VALUE(&q->val, &p->val);
q->h = p->h;
nIndex = q->h | ht->nTableMask;
q->key = p->key;
Z_NEXT(q->val) = HT_HASH(ht, nIndex);
HT_HASH(ht, nIndex) = HT_IDX_TO_HASH(j);
if (UNEXPECTED(ht->nInternalPointer == i)) {
ht->nInternalPointer = j;
}
if (UNEXPECTED(i == iter_pos)) {
zend_hash_iterators_update(ht, i, j);
iter_pos = zend_hash_iterators_lower_pos(ht, iter_pos + 1);
}
q++;
j++;
}
}
}
ht->nNumUsed = j;
break;
}
nIndex = p->h | ht->nTableMask;
Z_NEXT(p->val) = HT_HASH(ht, nIndex);
HT_HASH(ht, nIndex) = HT_IDX_TO_HASH(i);
p++;
} while (++i < ht->nNumUsed);
}
return SUCCESS;
}
复制代码
嗯哼,本文就到此结束了,由于自身水平缘由不能解释的十分详尽清楚。这算是我写过最难写的内容了,写完以后彷佛以为这篇文章就我本身能看明白/(ㄒoㄒ)/~~由于文笔太辣鸡。想起一句话「若是你不能简单地解释同样东西,说明你没真正理解它。」PHP 的源码里有不少细节和实现我都不算熟悉,这篇文章只是一个个人 PHP 底层学习的开篇,但愿之后可以写出真正深刻浅出的好文章。
另外这里有篇好文章 gsmtoday.github.io/2018/03/21/…