こんにちは。普段、JavaやGo、あるいはNode.jsといった他言語の高水準な世界からやってきて、「なぜPHPはこれほどリクエストのライフサイクルがシンプルなのに、大規模になるとメモリ効率の壁にぶつかるのだろう？」と疑問に思ったことはありませんか？
フレームワークのルーティング定義、数千件におよぶORMのエンティティマッピング、あるいは巨大なJSONペイロードのデコード。これらを処理する中で、配列（HashTable）のキーや動的なプロパティ名がメモリを圧迫していく様子に直面した開発者も多いはずです。
今回は、PHPの内部エンジンである Zend VM が、文字列という最も頻繁に出現するデータ構造をどのように扱い、メモリの無駄遣いを極限まで削ぎ落としているのか、その秘密に迫ります。ここを理解すれば、あなたの書くPHPコードのメモリフットプリントは劇的に変わり、裏側のエンジンが美しく駆動している姿がクリアに見えるようになりますよ。
—
1. 文字列インターニング（Interned Strings）とは何か？
まずは、基礎概念から優しく解きほぐしていきましょう。
プログラムの世界では、同じ文字列（例えば `”user_id”` や `”status”` など）が、リクエストのライフサイクル中に何度も何度も登場しますよね。もし、コードのあちこちで登場するたびに、その文字列の長さに応じたメモリ領域をヒープ上に毎回確保していたとしたらどうでしょう？ 無駄なメモリ消費はもちろん、それらを比較するたびに一文字ずつメモリ上の値を突き合わせるオーバーヘッドが発生します。
そこでZend VMが導入しているのが 「文字列インターニング（Interned Strings）」 という仕組みです。
これは簡単に言うと、「一度登場した文字列は、プロセス（またはリクエスト）の空間内でただ一つだけマスター（実体）を保持し、以降はそのマスターへの参照（メモリ上のポインター）だけを共有して使い回す」 という最適化手法です。Javaの `String.intern()` や、Lispのシンボル、Pythonの `sys.intern()` と同じ思想ですね。
Zend VM内部での表現（`zend_string`）
PHPの内部において、文字列は単なるC言語の `char` ではありません。`zend_string` という構造体として管理されています。
struct _zend_string {
zend_refcounted_h gc;
zend_ulong h;
size_t len;
char val[1];
};
ここで重要なのは、`gc`（リファレンスカウントやフラグを保持する構造体）と、`h`（ハッシュ値のキャッシュ）です。インターニングされた文字列は、Zend Engineの起動時（またはOPcacheのロード時）専用のグローバルなバケット（ハッシュテーブル）に登録されます。
一度この「インターニング・プール」に登録された文字列は、プロセスが生存している限り破棄されず、どこから参照されても同じメモリアドレスを指し続けます。
—
2. 配列（HashTable）のキーと文字列インターニングの深い関係
さて、ここからが実務に直結する重要な話です。PHPの連想配列は、内部ではすべて `HashTable` という極めて洗練されたハッシュマップ構造で実装されています。
あなたが次のようなコードを書いたとします。
12345,
‘username’ => ‘architect’,
‘email’ => ‘architect@example.com’,
];
この配列のキーである `’user_id’`, `’username’`, `’email’` は、すべて文字列です。もしこれらがインターニングの対象外であれば、配列のエントリ（`Bucket`）が作られるたびに、文字列分のメモリが個別にallocされ、ハッシュ値が計算されていました。
しかし、PHP（正確にはZend VMとOPcache）では、ソースコード上にハードコードされた文字列リテラルは、コンパイル時に自動的にインターニングされます。
つまり、何千、何万という配列が同じキー名（例: `’id’`, `’name’` など）を持っていたとしても、それらのキー文字列の本体はメモリ上にたった1つしか存在しません。数千の配列バケットが保持しているのは、そのたった一つのインターニング済み文字列を指すポインターだけなのです。
メモリ節約効果を実証するコードと挙動
以下のコードを見てください。
$i,
‘amount’ => $i 100,
‘currency’ => ‘JPY’,
];
}
return $rows;
}
// 10万件のレコードを生成
$startTime = microtime(true);
$startMemory = memory_get_usage(true);
$records = createDataRows(100000);
$endMemory = memory_get_usage(true);
$endTime = microtime(true);
echo “メモリ使用量: ” . number_format($endMemory – $startMemory) . ” バイト\n”;
このコードでは、10万件の配列が生成され、合計30万個のキーが作られます。しかし、キー名（`’transaction_id’`, `’amount’`, `’currency’`）はすべてソースコード上のリテラルであるため、インターニングの恩恵を最大限に受けています。結果として、メモリ消費量は驚くほどコンパクトに抑えられます。
—
3. 「動的生成された文字列」の罠と、OPcacheによる救済
ここで、一歩踏み込んだアーキテクトとしての注意点をお伝えします。
「じゃあ、すべての文字列が自動でインターニングされるんだな」と思った方、実はここに大きな落とし穴があります。
実行時に動的に生成・結合された文字列は、デフォルトではインターニングされません。
例えば、以下のようなケースです。
OPcacheによる「リクエスト間インターニング」の魔術
さらにモダンなPHP（PHP 7.4以降、特にPHP 8系）では、OPcacheが有効な場合、`zend_string_alloc` 等を経由して生成された特定の動的文字列すらも、一定の条件下でインターニングプールに引き上げる高度な最適化が行われます。
しかし、動的キーの乱用は依然としてメモリ肥大化の最大の原因の一つです。大規模なデータを扱うWebアプリケーションやAPIサーバーを設計する際は、不必要に動的なキー名やプロパティ名を生成せず、可能な限り静的な文字列リテラルや定数として定義することが、PHPエンジンのメモリ効率を極限まで引き出すコツになります。
—
まとめ：裏側の仕組みを知れば、PHPはもっと速く、美しくなる
今回は、PHPの内部文字列（Interned Strings）がZend VMやHashTableの中でどのように扱われ、メモリ節約に貢献しているのかを解説しました。
- 静的な文字列リテラルはコンパイル時にインターニングされ、メモリ上で完全に共有される。
- 配列のキーはインターニングされたポインターを共有するため、数万・数百万の要素を持つHashTableでも効率的に動作する。
- 動的に生成される文字列はインターニングの対象外になりやすいため、大規模ループ内での動的キー生成には注意が必要。
「PHPはスクリプト言語だからメモリ効率を気にしなくていい」という時代はとうに過ぎ去り、現代のPHPはZend VMとOPcacheの緻密な連携によって、極めて高いパフォーマンスを発揮する洗練された仮想マシン環境へと進化しています。
この裏側のメカニズムを頭の片隅に置いておくだけで、コードレビューの精度が変わり、大規模トラフィックに耐える堅牢なWebシステムの設計ができるようになりますよ。ここを理解できたあなたなら、もうPHPのパフォーマンスで悩むことは怖くないはずです。さあ、次のアーキテクチャ設計にこの知見を存分に活かしてくださいね！