はじめに：なぜあなたのPHPアプリケーションはメモリを喰い潰すのか
「PHPの配列は連想配列でもあり、何でも入れられるから便利だ」——もしあなたのチームのエンジニアがコードレビューでそう発言したら、テクニカルリードとして即座にその認識を正さなければなりません。
PHPの配列（Array）は、C言語の単なる連続メモリ領域としての配列とは全く異なります。その正体は、Zend Engine内部で高度に抽象化された`HashTable`（ハッシュテーブル）です。キーと値のペアを保持し、順序を保証し、動的なリサイズを許容し、$O(1)$ でのアクセスを実現する……この「魔法のような利便性」の裏には、相応のメモリオーバーヘッドと、衝突解決アルゴリズムに起因するパフォーマンストラ命題が隠されています。
本稿では、Zend Engine 3（PHP 7以降）のC言語レベルにおける `HashTable` の内部構造を解剖し、衝突解決アルゴリズムがメモリ空間とCPUキャッシュに与える影響を解説します。1リクエスト、1プロセスの重みを知り尽くしたアーキテクトとして、実務で耐えうる堅牢な設計手法とプロファイリングコードを伝授します。
—
1. Zend Engine 3における `HashTable` の内部構造とメモリレイアウト
PHP 5からPHP 7（Zend Engine 3）への進化において、最も劇的な軽量化・高速化が行われたのが `HashTable` です。まず、Zend Engine内部で配列がどのように表現されているかを理解しましょう。
1.1 `zend_array` (HashTable) 構造体の全貌
C言語レベルでのPHP配列の本体は、`zend_array` という構造体です。
// Zend/zend_types.h より抜粋・簡略化
struct _zend_array {
zend_refcounted_h gc;
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar flags,
zend_uchar _unused,
zend_uchar nIteratorsCount,
zend_uchar _unused2)
} v;
uint32_t flags;
} u;
uint32_t nTableMask; // ハッシュインデックス算出用マスク (-nTableSize)
Bucket arData; // エレメント（Bucket）配列へのポインタ
uint32_t nNumUsed; // 削除済みも含めた使用中Bucket数
uint32_t nNumOfElements; // 有効な要素数
uint32_t nTableSize; // ハッシュテーブルのサイズ（常に2の累乗）
uint32_t nInternalPointer; // 内部ポインタ
zend_long nNextFreeElement; // 次の自動インデックス ($arr[] = $val)
dtor_func_t pDestructor;
};
ここで最も重要なのは `arData` と `nTableMask` です。
1.2 メモリの局所性（Cache Locality）を追求したレイアウト
PHP 7以降の `HashTable` は、データの連続性を保ちCPUのL1/L2キャッシュヒット率を最大化するため、「Hash Index Table」と「Bucket Array」をメモリ上の1つの連続したブロックとして確保 します。
+————————————————–+————————————————–+
| Hash Index Table (負のオフセット: uint32_t[]) | Bucket Array (正のオフセット: Bucket[]) |
+————————————————–+————————————————–+
| [-nTableSize] … [-2] [-1] | [0] [1] [2] … [nTableSize – 1] |
+————————————————–+————————————————–+
^
arData ポインタが指す位置
- Bucket Array (`arData[0..N]`): 実際のデータ（`zval` とキー情報）が挿入順に隙間なく連続して格納されます。
- Hash Index Table (`arData[-N..-1]`): キーのハッシュ値から算出したインデックスが保持され、対応する `Bucket Array` の添字（インデックス）を指します。
`Bucket` 自体の構造は以下の通りです。
typedef struct _Bucket {
zval val; // 実際の値 (16 bytes)
zend_ulong h; // 文字列キーのハッシュ値、または数値キーの値 (8 bytes)
zend_string key; // 文字列キーへのポインタ (8 bytes)
} Bucket; // 合計 32 bytes
—
2. 衝突解決（Collision Resolution）のメカニズム
ハッシュテーブルである以上、異なるキーが同じハッシュインデックスにマッピングされる「ハッシュ衝突（Collision）」を回避することは不可能です。Zend Engineはこれをどのように解決しているのでしょうか。
2.1 チェイン法とオープンアドレス法のハイブリッド実装
Zend Engineの衝突解決は、概念的にはチェイン法（Chaining）ですが、伝統的なポインタによる双方向リストではありません。メモリの分散を防ぐため、`Bucket` 配列内のインデックスを用いた単方向の暗黙的リストを構築します。
キーの探索プロセスは以下のステップで行われます。
1. ハッシュ値の計算: キーからハッシュ値 `h` を算出（`zend_string` の場合は計算済みハッシュを再利用）。
2. Hash Index の特定: `nIndex = h | nTableMask;` （`nTableMask` は `-nTableSize` のビット表現）。
3. Index Table 参照: `arData[nIndex]` から、最初に見つけたい `Bucket` の添字（例: `idx`）を取得。
4. Bucket の検証とチェインの走査:
- `arData[idx]` のキーが一致すれば探索成功。
- 異なる場合（衝突）、`Bucket.val.u2.next` に格納されている「次に衝突した `Bucket` の添字」を辿る。
[Hash Index Table]
idx = h | mask —> [Index: 3]
|
v
[Bucket Array (arData)]
[0] Key: “foo” | val: … | next: INVALID
[1] Key: “bar” | val: … | next: INVALID
[2] …
[3] Key: “a” | val: … | next: 0 <--- 衝突！ Index 0 へチェイン
`zval` 構造体の内部にある未使用領域 `u2.next`（4バイト）をリンクポインタ代わりに使うことで、追加のメモリを一切消費せずに衝突チェインを構築しています。
2.2 衝突が引き起こすパフォーマンスとメモリへの牙
- 探索コストの劣化: 最良ケースでは $O(1)$ ですが、衝突が頻発するとチェインの走査が発生し、$O(N)$ に近づきます。
- Table Resizing（テーブル再構築）のコスト: 要素数が `nTableSize` に達すると、サイズは2倍に拡張されます。この際、Hash Index Tableの再構築（Rehash）が発生し、一時的にメモリアロケーションとCPUサイクルを大きく消費します。
—
3. 「Packed Array」という極限の最適化
Zend Engineには、ハッシュ衝突とメモリオーバーヘッドを完全に回避する特殊な状態が存在します。それが Packed Array（パック配列） です。
以下の条件を満たす場合、配列は Packed Array として扱われます。
- キーがすべて整数（integer）である。
- インデックスが 0 から始まり、単調増加している。
- 穴あき（要素の削除）が少ない。
Packed Array では Hash Index Table が不要になり、`arData` のインデックスが直接 `Bucket` の位置を指します。つまり、ハッシュ計算も、インデックス変換も、衝突解決チェインも一切発生しません。アクセスは純粋なCの配列と同じメモリオフセット計算のみとなり、パフォーマンスとメモリ効率が最大化されます。
しかし、文字列キーを1つでも追加したり、インデックスを飛ばしたりした瞬間、Packed Array は一般的な Hash Array へ「昇格（Promotion / Unpack）」 します。一度昇格すると、Hash Index Table 領域（`uint32_t nTableSize` バイト）が即座に確保され、元の状態には戻りません。
—
4. 実証：メモリ使用量とパフォーマンスの比較プロファイリング
理論を理解したところで、実際にコードを動かして Zend Engine 内部の挙動を確認しましょう。
以下のスクリプトは、Packed Array と Hash Array、および衝突が発生した際のメモリフットプリントと実行速度の違いを正確に可視化します。
/
declare(strict_types=1);
function getMemoryDelta(callable $fn): array
{
gc_collect_cycles(); // ガベージコレクションを強制実行してノイズを排除
$memBefore = memory_get_usage();
$timeBefore = microtime(true);
$result = $fn();
$timeAfter = microtime(true);
$memAfter = memory_get_usage();
return [
‘bytes’ => $memAfter – $memBefore,
‘time_ms’ => ($timeAfter – $timeBefore) 1000,
‘data’ => $result
];
}
$elementCount = 100_000;
echo “=== 1. Packed Array (連続する整数キー) ===\n”;
$packedPerf = getMemoryDelta(function () use ($elementCount) {
$arr = [];
for ($i = 0; $i < $elementCount; $i++) {
$arr[] = $i;
}
return $arr;
});
printf("Memory: %s bytes | Time: %.2f ms\n", number_format($packedPerf['bytes']), $packedPerf['time_ms']);
echo "\n=== 2. Hash Array (文字列キー化によるPromotion) ===\n";
$hashPerf = getMemoryDelta(function () use ($elementCount) {
$arr = [];
for ($i = 0; $i < $elementCount; $i++) {
// 文字列キーにすることで強制的にHash Array化
$arr['key_' . $i] = $i;
}
return $arr;
});
printf("Memory: %s bytes | Time: %.2f ms\n", number_format($hashPerf['bytes']), $hashPerf['time_ms']);
echo "\n=== 3. Hash Collision 模倣（同一ハッシュ値のインデックス競合） ===\n";
// Zend Engineの内部ハッシュ関数における衝突をシミュレート
// 注: PHP 7+ では 2^64 や 2^32 の倍数の数値キーは同じハッシュインデックスにマッピングされやすい
$collisionPerf = getMemoryDelta(function () use ($elementCount) {
$arr = [];
$step = 1 << 16; // 65536の間隔でキーを配置（ハッシュマスクの下位ビットが被りやすくなる）
for ($i = 0; $i < $elementCount; $i++) {
$arr[$i $step] = $i;
}
return $arr;
});
printf("Memory: %s bytes | Time: %.2f ms\n", number_format($collisionPerf['bytes']), $collisionPerf['time_ms']);
// 検索パフォーマンスのプロファイリング
echo "\n=== 4. 検索速度の比較 (10,000回ランダムアクセス) ===\n";
$packedArray = $packedPerf['data'];
$hashArray = $hashPerf['data'];
$collisionArray = $collisionPerf['data'];
$keysToSearch = array_map(fn() => rand(0, $elementCount – 1), range(1, 10_000));
// Packed 検索
$start = microtime(true);
foreach ($keysToSearch as $k) {
$v = $packedArray[$k];
}
$packedSearchTime = (microtime(true) – $start) 1000;
// Hash 検索
$start = microtime(true);
foreach ($keysToSearch as $k) {
$v = $hashArray[‘key_’ . $k];
}
$hashSearchTime = (microtime(true) – $start) 1000;
// Collision 検索
$step = 1 << 16;
$start = microtime(true);
foreach ($keysToSearch as $k) {
$v = $collisionArray[$k $step];
}
$collisionSearchTime = (microtime(true) - $start) 1000;
printf("[%s] Packed Array 検索時間: %.2f ms\n", "FAST", $packedSearchTime);
printf("[%s] Hash Array 検索時間: %.2f ms\n", "WARN", $hashSearchTime);
printf("[%s] Collision 検索時間: %.2f ms\n", "SLOW", $collisionSearchTime);
実行結果例（環境により多少前後します）
=== 1. Packed Array (連続する整数キー) ===
Memory: 2,101,312 bytes | Time: 4.12 ms
=== 2. Hash Array (文字列キー化によるPromotion) ===
Memory: 6,300,224 bytes | Time: 12.85 ms
=== 3. Hash Collision 模倣（同一ハッシュ値のインデックス競合） ===
Memory: 4,198,464 bytes | Time: 8.50 ms
=== 4. 検索速度の比較 (10,000回ランダムアクセス) ===
[FAST] Packed Array 検索時間: 0.18 ms
[WARN] Hash Array 検索時間: 0.52 ms
[SLOW] Collision 検索時間: 1.84 ms
分析
1. メモリフットプリントの違い:
Packed Arrayに比べ、文字列キーを用いた Hash Array は約3倍のメモリを消費しています。これは `zend_string` のメモリ確保と、`Hash Index Table` の領域（負のオフセット領域）が追加されるためです。
2. 検索速度の劣化:
ハッシュ衝突を意図的に発生させた配列へのアクセスは、Packed Array と比較して約10倍の実行時間を要しています。$O(1)$ であるはずのルックアップが、内部チェインのリンク走査によって $O(N)$ へ退行している動かぬ証拠です。
—
5. テクニカルリードが指示すべき実務コードの設計ルール
この内部機構を踏まえ、実務のコードレビューで直ちに適用すべき設計ルールを提示します。
Rule 1: 動的な「連想配列 DTO」を排除し、Typed Class（または `stdClass`）を使え
実務で最もよく見かけるアンチパターンは、APIのレスポンスやDBのレコードをすべて連想配列（Hash Array）として引き回す実装です。
❌ 危険なコード：巨大な連想配列のネスト
// メモリの浪費と型アクセスのオーバーヘッドが甚大
function fetchUsers(): array {
$users = [];
while ($row = $dbFetch()) {
$users[] = [
‘id’ => (int)$row[‘id’],
‘name’ => (string)$row[‘name’],
‘email’ => (string)$row[‘email’],
];
}
return $users; // 1万件で数メガバイトのHashTableオーバーヘッド
}
⭕ 改善されたコード：Readonly DTO クラスの配列
declare(strict_types=1);
final readonly class UserData
{
public function __construct(
public int $id,
public string $name,
public string $email,
) {}
}
/
- @return list
/
function fetchUsersOptimized(PDOStatement $stmt): array {
$users = [];
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
// オブジェクト化することで、連想配列キーの重複保持（zend_string）を避ける
// Packed Array（0からの連続数値インデックス）として保持可能
$users[] = new UserData(
id: (int)$row[‘id’],
name: $row[‘name’],
email: $row[‘email’],
);
}
return $users;
}
解説:
配列の中に連想配列を詰め込むと、全要素で同じ文字列キー（`’id’`, `’name’`, `’email’`）の `Bucket` が生成され、`HashTable` 構造体が大量に複製されます。
これを Class のインスタンスに置き換えると、アレイ側は Packed Array（`list
Rule 2: 巨大データ処理には Generator を適用し、HashTableの生成そのものを回避せよ
10万件のデータをDBから取得して加工・送信する場合、そもそも配列（`HashTable`）をメモリ上に構築すること自体が問題です。
declare(strict_types=1);
/
- 巨大なデータセットをメモリを圧迫せずにストリーム処理する Generator 例
- @return Generator
/
function streamLargeDataSet(PDOStatement $stmt): Generator
{
// PDOのカーソルを順次進め、1要素ずつyieldする
// メモリ上には常に1要素分の zval / Class インスタンスしか存在しない
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
yield new UserData(
id: (int)$row[‘id’],
name: $row[‘name’],
email: $row[‘email’]
);
}
}
// 利用側
$stmt = $pdo->query(“SELECT id, name, email FROM huge_table”);
foreach (streamLargeDataSet($stmt) as $user) {
// 1件ずつ処理するため、メモリ消費量は常に一定（O(1) Memory）
processUser($user);
}
—
まとめ：エンジニアリングの真価は低レイヤの理解に宿る
PHPはその柔軟性ゆえに、内部構造を意識しなくてもコードが動いてしまいます。しかし、トラフィックが急増したWebアプリケーションや、数百万件のバッチ処理においてシステムを破綻させるのは、常にこのような「低レイヤでのメモリ・CPU効率の無視」です。
1. PHPの配列は単なるメモリの塊ではなく、複雑な `HashTable` である。
2. 文字列キーや飛び飛びのインデックスは `Hash Array` を引き起こし、メモリと速度のペナルティを伴う。
3. 連続する数値インデックス（Packed Array）を意識し、可能な限りクラス（DTO）や Generator を活用する。
コードレビューにおいて「なぜこの設計にするのか」をZend Engineのメモリオフセットや `HashTable` のレベルから論理的に語れるテクニカルリードこそが、堅牢でスケールするシステムを構築できるのです。