PHP内部文字列（Interned Strings）の管理メカニズムとメモリ節約の極限最適化
PHPは「動的言語だからメモリを食うのは仕方がない」という神話は、Zend Engineの内部構造を理解していない怠惰の言い訳に過ぎない。Webの1リクエスト、FPMの1プロセスが消費するメモリの数バイトを切り詰めることこそ、数千万リクエストを捌く超高負荷基盤を支えるアーキテクトの矜持である。
今回は、Zend VMの根幹を支える「インターンド・ストリング（Interned Strings）」のメモリ管理メカニズムにメスを入れる。同一文字列の共有がZendヒープ上でどのように行われ、大規模な配列キーやOPcacheプリローディングにおいて如何なる挙動を示すのか。その物理構造と限界を、低レイヤの視点から徹底的に解剖する。
—
1. Zend Engineにおける文字列の内部表現：`zend_string`構造体
PHPの文字列は、単なるC言語の `char` ではない。Zend VMのメモリ空間において、すべての文字列は `zend_string` という構造体として管理されている。
struct _zend_string {
zend_refcounted_h gc;
zend_ulong h;
size_t len;
char val[1];
};
ここで注目すべきは、`gc`（参照カウンタとフラグを持つヘッダ）と、文字列自体のハッシュ値 `h`、そして長さ `len` である。通常の文字列であれば、スクリプトの実行に伴ってこの構造体がヒープ上に乱立し、リクエスト終了と共にガベージコレクションの対象となる。
しかし、文字列インターニング（Interning）が有効な場合、この挙動は根本から覆る。
—
2. インターンド・ストリングの物理構造と共有メカニズム
インターンニングとは、アプリケーションのライフサイクル（またはリクエストライフサイクル）において、「不変であるべき文字列」をプロセス全体で一意に共有し、メモリの重複割当とハッシュ計算コストを完全に排除する仕組みだ。
Zendエージェントによるハッシュテーブル管理
Zend Engineは、起動時にグローバルなインターンド・ストリング用の `HashTable` を確保する。ソースコード中の識別子（関数名、クラス名、メソッド名、プロパティ名、そして定数や配列のキーとなるリテラル文字列）は、コンパイル時にこのインターンドプールに登録される。
1. 一意性の保証: 同一の文字列（例: `”user_id”`）が何度登場しようとも、メモリ上に存在する `zend_string` はプロセス空間内でただ一つである。
2. 高速な比較（O(1) pointer comparison）: 通常の文字列比較は `memcmp()` によるバイト比較（O(N)）だが、インターンド・ストリング同士であれば、アドレスポインタの比較（`==`）だけで同一性を判定できる。これはZend VMのオペコード実行速度において凄まじいアドバンテージとなる。
/
$data = [
‘user_id’ => 1042,
‘role’ => ‘architect’,
];
このコードにおける `’user_id’` や `’role’` は、リクエストごとにヒープへアロケートされることはない。すでに共有メモリ上のインターンドプールを指すポインタとしてコンパイルされている。
—
3. 大規模な動的キーとインターンニングの罠
問題は、「動的に生成された文字列」を配列のキーとして大量に扱う場合だ。
外部APIのレスポンスやデータベースから取得した動的な文字列を配列のキーにする際、PHPはそれがすでにインターンドプールに存在するかどうかをグローバルなハッシュテーブルで線形/ハッシュ検索する。
/
$cache = [];
for ($i = 0; $i < 1_000_000; $i++) {
// 毎回動的に生成される文字列は、インターンドプールに登録を試みるか、
// あるいは通常ヒープにアロケートされ、HashTableのバケツを圧迫する。
$dynamicKey = 'key_' . md5(random_bytes(8));
$cache[$dynamicKey] = $i;
}
メモリ消費のメカニズムとバグの温床
動的文字列がインターンドプールに登録される条件は、PHPのバージョンやOPcacheの設定（`opcache.interned_strings_buffer`）に依存する。もしバッファサイズを超過した場合、新しい文字列はインターンされずに通常ヒープに落ちるが、登録を試みる過程のハッシュルックアップコストがCPUキャッシュを汚染する。
さらに、これがセキュリティハイスペックな文脈においてHash DoS攻撃のベクトルになり得る。Zend Engineの内部ハッシュ関数（Zend Hash Function）の挙動を狙った悪意あるキーの群れがインターンドプールやローカルのHashTableに投入されると、チェイン長が爆発し、CPU使用率が100%に張り付く。
—
4. OPcacheプリローディングとインターンド・ストリングの極限最適化
PHP 7.4以降で導入されたOPcacheプリローディング（Preloading）は、このインターンド・ストリングの概念をプロセス境界を超えて永続化させる究極の武器である。
`php.ini` での適切なサイジングが、プロダクション環境の生死を分ける。
[opcache]
opcache.enable=1
opcache.memory_consumption=512
; インターンド・ストリング専用バッファの割り当て（単位: メガバイト）
; デフォルト（通常8MB〜16MB）では、大規模フレームワークや多数のクラス定義を持つ環境では瞬殺で枯渇する。
opcache.interned_strings_buffer=64
opcache.preload=/var/www/html/config/preload.php
プリロード時のメモリレイアウト
プリローディングが有効な場合、`preload.php` で指定されたスクリプト群は、Apache/Nginxのワーカープロセスがフォークされる前の親プロセス（Master Process）のメモリ空間に読み込まれる。
ここで生成されたすべてのクラス名、メソッド名、そしてコード中の文字列リテラルは、完全にインターン化され、すべてのFPMワーカー間で共有（Copy-on-Write）される。
// preload.php の実例
getExtension() === ‘php’) {
opcache_compile_file($file->getRealPath());
}
}
このアプローチにより、各子リクエストが起動するたびに発生していた文字列のパース・アロケーション・ハッシュ計算のオーバーヘッドが完全に消滅する。
—
5. 脆弱性メカニズム：文字列の共有が生むオブジェクトインジェクションの脅威
低レイヤのメモリ共有メカニズムは、パフォーマンスを劇的に向上させる一方で、セキュリティ上の致命的な脆弱性（オブジェクトインジェクション等）において予期せぬ挙動を引き起こすことがある。
PHPオブジェクトインジェクション（`unserialize()` の悪用）において、攻撃者はシリアライズされたストリーム内に任意のクラス名やプロパティ名を注入する。
インターンド・ストリングとの関係
Zend Engineは、アンシリアライズ時に復元されるクラス名やプロパティ名を解決する際、内部のインターンドプールを参照する。もし攻撃者が既存のシステムに存在する安全なクラス名や、メモリ上に存在する意図せぬクラスの文字列を巧みに誘発・構築した場合、Zend Engineのポインタ解決の仕組みやマジックメソッド（`__destruct`, `__toString` 等）の呼び出し順序が狂い、メモリ破壊やRCE（Remote Code Execution）へのガジェットチェーン（Gadget Chain）が完成する。
特に、シェアードメモリ空間内で文字列が厳密に一意であるという特性は、メモリリークや不正な型キャストを引き起こすエクスプロイトにおいて、アタッカーにとって予測可能なアドレスや識別子の足場となり得るのだ。
—
結びにかえて
PHPの高速化は、フレームワークの薄さやアルゴリズムの選択だけで語ることはできない。Zend VMがどのようにメモリを確保し、`zend_string` がインターンドプールでどう振る舞い、OPcacheがどの領域にそれを焼き付けているのか。その物理構造を脳内に描ける者だけが、真にスケーラブルなWebシステムを構築できる。
コードの1行、配列の1つのキー、そして `php.ini` の1つの数値。それらすべてがZend Engineの心臓部と直結していることを忘れてはならない。