こんにちは。日々、巨大なトラフィックをさばくWebシステムの設計や、パフォーマンスのチューニングに向き合っていらっしゃることと思います。
他の高水準言語、例えばRubyやPython、あるいはGoなどを深く触ってきた優秀なエンジニアほど、PHPの配列（Array）に触れたとき、少し不思議な感覚を覚えるのではないでしょうか。「この言語の配列は、順序付きマップであり、リストであり、セットでもある。なのに、どうしてこれほど高速に動くのだろう？」と。
実は、PHP（Zend Engine）のあらゆる変数の背後には、`HashTable`（ハッシュテーブル）という極限まで最適化されたデータ構造が鎮座しています。
今回は、このPHPの心臓部であるHashTableが、メモリ上でどのように衝突（ハッシュコリジョン）を解決し、なぜあんなにも省メモリで高速なのか、その内部のメカニズムを低レイヤの視点から紐解いていきます。ここを理解すると、PHPのコードを書くときの「メモリの呼吸」が感じられるようになりますよ。
—
1. PHPの配列は「配列」ではなく「連想型HashTable」である
私たちが普段何気なく書いている `$arr = [];` というコード。Zend Engineの内部（C言語の世界）において、これは純粋なCの配列（連続したメモリ領域）ではありません。実体は `zend_array` 構造体であり、その本質は「双方向連結リスト（Linked List）の機能を内包したハッシュテーブル」です。
PHPの配列が優れているのは、以下の特徴を同時に満たしている点です。
1. O(1) の高速なキー検索（ハッシュによる直接アクセス）
2. 要素の挿入順序の完全な保持（foreachで追加順に取れる）
3. 数値添字も文字列キーも同一の構造で扱える
これを実現するために、Zend Engineはメモリ上で巧妙なデータ構造を構築しています。しかし、ここで避けて通れないのが「ハッシュ衝突（Collision）」の問題です。
—
2. 衝突解決アルゴリズムの二大巨頭：チェイン法 vs オープンアドレス法
異なるキーがハッシュ関数によって同じインデックス（スロット）を指し示されてしまったとき、エンジンはどう処理するでしょうか。
一般的に、ハッシュテーブルの衝突解決には大きく分けて2つのアプローチがあります。
チェイン法（Chaining）
- 仕組み: 衝突が発生した場合、同じスロットにポインタ（またはリスト）をぶら下げて、線形または木構造で繋いでいく方式。
- 特徴: メモリが断片的になりやすく、ポインタを辿るためのキャッシュミス（CPUキャッシュのヒット率低下）が起きやすい。その代わり、要素の削除や動的な拡張がエレガントに行える。
オープンアドレス法（Open Addressing）
- 仕組み: 衝突が起きたら、ハッシュテーブル内の「次の空いている別のスロット」を規則的に探して（プロービング）、そこにデータをねじ込む方式。
- 特徴: メモリが連続した一つの巨大な領域に収まるため、CPUのL1/L2キャッシュ効率が爆発的に良くなり、検索が非常に高速になる。ただし、削除処理が複雑化し、テーブルが埋まってくるとパフォーマンスが急激に劣化する。
さて、現代のPHP（PHP 7以降、およびPHP 8系）は、どちらの方式を採用しているでしょうか？
実は、PHPは純粋なオープンアドレス法でもチェイン法でもありません。
PHPのHashTableは、これらとは一線を画す「インダイレクト・テーブル（間接参照テーブル）方式」という、極めてユニークで洗練されたアプローチを採用しています。
—
3. PHP内部のHashTable構造：なぜ「間接参照」なのか
PHPの内部実装を覗いてみましょう。PHPのHashTableは、大別して以下の2つのメモリブロックで構成されています。
1. データ実体の配列（`Bucket`の連続領域）
- 実際に値やキー、ハッシュ値を持つ構造体（`Bucket`）が、メモリ上で美しく連続して並んでいます。
2. ハッシュ用インデックスの配列（`arData`の逆側に生えているマッピングテーブル）
- ハッシュ値から、上記の「データの配列」の何番目を指すべきかを解決するためのテーブルです。
ここで衝突が起きたとき、PHPはどのように解決しているか。
PHPは、各`Bucket`の中に「次の衝突した要素のインデックス（`nNext`）」を持たせています。つまり、データの配置自体はメモリ上で美しく連続させつつ、衝突した要素同士はインデックスの連鎖（チェイン）で結ぶという、いいとこ取りの構造を取っているのです。
メモリ使用量の観点から見た美しさ
この設計がなぜ素晴らしいかというと、「メモリの無駄な断片化を防ぎながら、CPUキャッシュに優しい連続アクセスを実現できるから」です。
もし純粋なチェイン法をとると、要素一つ追加するたびに `malloc` が走り、メモリがあちこちに散らばって、CPUがメインメモリへアクセス（キャッシュミス）する回数が増えてしまいます。FPMの1リクエストのライフサイクルにおいて、CPUキャッシュのヒット率はスループットに直結する死活問題です。
PHPは、データを一つの巨大な塊（`arData`）として一気に確保します。そのため、配列をイテレート（`foreach`）する際、CPUはキャッシュラインに乗ったデータを次々と高速に読み込んでいくことができます。
—
4. 実際のコードとメモリ挙動を脳内トレースする
百聞は一見に如かず。実際にPHPで連想配列を操作したとき、内部で何が起きているのかをコードと共に対比してみましょう。
‘localhost’,
‘port’ => 3306,
‘user’ => ‘root’,
];
// 新しい要素を追加する
// キーの文字列からDJBX33Aなどのハッシュアルゴリズムでハッシュ値を算出します。
// arDataの連続領域に新しいBucketが「末尾」に追加され、
// ハッシュインデックスとのマッピングが結ばれます。
$config[‘password’] = ‘secret_pass’;
// 要素を削除する
// PHPのHashTableでは、削除時はBucketを即座に物理削除せず、
// 「DELETEDマーク」を付与するか、インデックスの結び目をつなぎ直します。
// これにより、O(1)の高速な削除と、メモリの再利用性を担保しています。
unset($config[‘port’]);
foreach ($config as $key => $value) {
// このループは、arDataの連続したメモリ領域を先頭から順に走査します。
// ポインタがあちこちに飛ばないため、CPUキャッシュ効率が極めて高い状態で行われます。
echo “{$key}: {$value}\n”;
}
このコードを実行するとき、PHPのプロセス（php-fpm）はZendMemoryManager（ZMM）を介してOSからメモリを効率よく取得・解放しています。配列の要素数が動的に増え、あらかじめ用意されたスロット数を超過（リハッシュ）すると、PHPは「現在の2倍のサイズを持つ新しいメモリ領域を確保し、既存のデータを全コピーして、古い領域を破棄する」というコストの高い処理（Rehash）を行います。
そのため、大量の要素を追加することが分かっている場合は、あらかじめ大まかなサイズ感を意識したコード設計や、メモリ制限（`memory_limit`）への配慮がプロフェッショナルには求められるのです。
—
5. アーキテクトからのメッセージ
いかがでしたでしょうか？
普段私たちが何気なく使う `$array[‘key’] = ‘value’;` というシンプルな構文の裏側には、CPUのキャッシュ効率、メモリの連続性、そしてハッシュ衝突を防ぐためのエンジニアたちの知恵がこれでもかと詰め込まれています。
「なぜPHPは他の言語に比べて配列操作がこんなにも直感的で速いのか？」
その答えは、言語の表面的な文法ではなく、Zend Engineが底辺で支える美しいHashTableのメモリレイアウトにありました。
この低レイヤの構造を頭の片隅に置いておくだけで、巨大なデータを扱う際のボトルネックの予測精度が劇的に変わります。「なんとなく動くコード」から「内部の挙動が手に取るようにわかる洗練されたコード」へ。ぜひ、今日のデバッグや設計の現場でこの視点を活かしてみてください。
あなたの書くコードが、今日も美しく、軽快に実行されることを願っています。