PHP 數組底層實現
0x00 前言
最近在看《PHP 內核剖析》，關於 PHP 數組方面有所得，特此撰文一篇總結記錄 (∩_∩)。由於 PHP 的數組是很強大且很重要的數據類型，它既支持單純的數組又支持鍵值對數組，其中鍵值對數組相似於 Go 語言的 map 但又保證了可以按順序遍歷，而且因爲採用了哈希表實現可以保證基本查找時間複雜度爲 O(1)。因此接下來讓咱們瞭解一下 PHP 數組的底層實現吧～php
0x01 數組的結構
一個數組在 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;
複製代碼
0x01 數組訪問
咱們知道 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 的值遍歷直到找到鍵名相同的元素或查找失敗。
0x02 插入元素
插入元素的函數 _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;
}
複製代碼
0x03 擴容
前面將數組結構的時候咱們有提到擴容，而在插入元素的代碼裏有這樣一個宏 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;
}
複製代碼
0x04 總結
嗯哼，本文就到此結束了，由於自身水平緣由不能解釋的十分詳盡清楚。這算是我寫過最難寫的內容了，寫完以後彷佛以爲這篇文章就我本身能看明白/(ㄒoㄒ)/~~由於文筆太辣雞。想起一句話「若是你不能簡單地解釋同樣東西，說明你沒真正理解它。」PHP 的源碼裏有不少細節和實現我都不算熟悉，這篇文章只是一個個人 PHP 底層學習的開篇，但願之後可以寫出真正深刻淺出的好文章。
另外這裏有篇好文章 gsmtoday.github.io/2018/03/21/…
- 1. PHP 數組底層實現原理
- 2. php底層原理之數組實現
- 3. Java實現數組底層
- 4. 數組底層實現
- 5. PHP7 數組的底層實現
- 6. php底層HashTable的實現
- 7. php變量底層實現
- 8. 詳解 PHP 數組的底層實現：HashTable
- 9. 剖析PHP底層數組是如何實現的
- 10. 數組方法底層實現原理
- 更多相關文章...
- • 現實生活中的 XML - XML 教程
- • Hibernate實現增刪改查 - Hibernate教程
- • ☆基於Java Instrument的Agent實現
- • Spring Cloud 微服務實戰(三) - 服務註冊與發現
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. PHP 數組底層實現原理
- 2. php底層原理之數組實現
- 3. Java實現數組底層
- 4. 數組底層實現
- 5. PHP7 數組的底層實現
- 6. php底層HashTable的實現
- 7. php變量底層實現
- 8. 詳解 PHP 數組的底層實現：HashTable
- 9. 剖析PHP底層數組是如何實現的
- 10. 數組方法底層實現原理