0x00 前言
最近在看《PHP 核心剖析》，關於 PHP 陣列方面有所得，特此撰文一篇總結記錄 (∩_∩)。因為 PHP 的陣列是很強大且很重要的資料型別，它既支援單純的陣列又支援鍵值對陣列，其中鍵值對陣列類似於 Go 語言的 map 但又保證了能夠按順序遍歷，並且由於採用了雜湊表實現能夠保證基本查詢時間複雜度為 O(1)。所以接下來讓我們瞭解一下 PHP 陣列的底層實現吧～
0x01 陣列的結構
一個陣列在 PHP 核心裡是長什麼樣的呢？我們可以從 PHP 的原始碼裡看到其結構如下：
// 定義結構體別名為 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 結構：
typedef struct _Bucket {
// 陣列元素的值
zval val;
// key 通過 Time 33 演算法計算得到的雜湊值或數字索引
zend_ulong h;
// 字元鍵名，數字索引則為 NULL
zend_string *key;
} Bucket;
複製程式碼0x01 陣列訪問
我們知道 PHP 陣列是基於雜湊表實現的，而與一般雜湊表不同的是 PHP 的陣列還實現了元素的有序性，就是插入的元素從記憶體上來看是連續的而不是亂序的，為了實現這個有序性 PHP 採用了「對映表」技術。下面就通過圖例說明我們是如何訪問 PHP 陣列的元素 :-D。
注意：因為鍵名到對映表下標經過了兩次雜湊運算，為了區分本文用雜湊特指第一次雜湊，雜湊即為第二次雜湊。
由圖可知，對映表和陣列元素在同一片連續的記憶體中，對映表是一個長度與儲存元素相同的整型陣列，它預設值為 -1 ，有效值為 Bucket 陣列的下標。而 HashTable->arData 指向的是這片記憶體中 Bucket 陣列的第一個元素。
舉個例子 $a['key'] 訪問陣列 $a 中鍵名為 key 的成員，流程介紹：首先通過 Time 33 演算法計算出 key 的雜湊值，然後通過雜湊演算法計算出該雜湊值對應的對映表下標，因為對映表中儲存的值就是 Bucket 陣列中的下標值，所以就能獲取到 Bucket 陣列中對應的元素。
現在我們來聊一下雜湊演算法，就是通過鍵名的雜湊值對映到「對映表」的下標的演算法。其實很簡單就一行程式碼：
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/…