【PHP内部構造解説】巨大シリアライズデータの闇：`serialize()` / `unserialize()` のメモリ爆発を防ぐ極限最適化
コードレビューをしていて、数万件のモデルや巨大なDTO（Data Transfer Object）の配列をそのまま `serialize()` し、データベースのBLOBカラムに突っ込んだり、Redisへキャッシュしたりしているコードを見かけるたび、私は冷や汗が出る。
「なぜ動いているのか？」ではなく、「いつメモリ上限（`memory_limit`）にヒットしてプロセスがクラッシュするか」を考えるのが、我々バックエンドエンジニアの仕事だ。
表面上のPHPの関数リファレンスをなぞるだけならジュニアでもできる。だが、プロセスの寿命、Zend Engineのメモリ管理（EMALLOC）、そしてZend VMの挙動までを掌握していなければ、大規模トラフィックをさばくAPIやバッチ処理を書く資格はない。
今回は、PHPにおけるオブジェクトのシリアライズ・デシリアライズ処理が内部で何を引き起こし、いかにしてメモリ消費を極限まで抑えるべきか、そのアーキテクチャと実践的解法を徹底的に叩き込む。
—
1. 内部解剖：`serialize()` と `unserialize()` がZend Engineのメモリを蝕むメカニズム
まずは、PHPの内部（C言語レベル）で何が起きているのかを脳内トレースしよう。
`serialize()` のコスト
オブジェクトをシリアライズするとき、Zend Engineは対象の `zval` をスキャンし、クラス名、プロパティの可視性、名前空間、そしてすべてのプロパティの値を再帰的にトラバースして一つの巨大な文字列（ストリーム）を生成する。
この時、一時的に「元のオブジェクトグラフ」と「生成される文字列」の両方がメモリ上に存在することになる。数メガバイトのオブジェクトであれば、メモリ使用量は優に数倍へと膨れ上がる。
`unserialize()` の真の恐怖：メモリの二重確保とHashTableの暴騰
さらに凶悪なのが `unserialize()` だ。
シリアライズされた文字列を読み込む際、Zend Engineは文字列をパースし、再びヒープメモリ上に `zend_string`、`zval`、そしてプロパティを格納するための `HashTable` を構築し直す。
ここで問題になるのが、「一瞬にして巨大なオブジェクトグラフがメモリ上に復元される」という点だ。
GC（ガベージコレクション）や参照カウントが正常に機能する前の段階で、パースされたデータが一気にメモリ空間へアロケートされるため、`memory_limit` をいとも簡単に突破し、`Allowed memory size of X bytes exhausted` というお馴染みの絶望的なエラーを引き起こす。
また、`unserialize()` はデフォルトで信頼性の低い入力に対して脆弱性（Object Injection）を持つだけでなく、復元されたオブジェクトが持つ参照関係の再構築コストも無視できない。
—
2. 【アンチパターン】メモリを枯渇させる最悪の実装
以下のコードを見てほしい。一見、何の変哲もないモダンなPHPのコードに見えるかもしれない。しかし、コードレビューの現場であれば、私は即座に「Re-Write」を要求する。
/
public function saveCache(array $objects): string
{
// 危険：数万件のオブジェクトグラフ全体を一つの文字列に圧縮するため、
// Zend Engineのヒープメモリが一瞬で最大化する。
return serialize($objects);
}
public function restoreCache(string $serializedData): array
{
// 危険：一撃でメモリ上に数万個のオブジェクトとHashTableが復元され、
// FPMプロセスのメモリフットプリントが跳ね上がる。
return unserialize($serializedData, [‘allowed_classes’ => [LargeDomainObject::class]]);
}
}
この実装がなぜ危険か。1リクエストあたりのメモリ消費量が肥大化すると、PHP-FPMのプロセスがリクエスト終了後もメモリを解放しきれなかったり（フラグメンテーション）、同時リクエスト数が跳ね上がった瞬間にOOM Killer（Out of Memory Killer）の餌食になるからだ。
—
3. 実務で使える極限最適化：チャンク処理とストリームの活用
では、巨大なデータ構造を安全にハンドリングするにはどうすればいいのか。
答えは明確だ。「一括で処理せず、分割（チャンク）してシリアライズする」、あるいは「Generatorを使ってメモリ上のライフサイクルをコントロールする」ことだ。
以下に、実務の現場でそのまま使える、堅牢性とメモリ効率を極限まで高めた実装を示す。
実装例：Generatorと逐次シリアライズによるメモリ最適化アーキテクチャ
/
class SafeSerializationHandler
{
/
- 巨大なコレクションをGeneratorで1件ずつストリーム状にシリアライズし、
- 改行区切りの文字列（NDJSON風）としてファイルやバッファに出力する。
- これによりメモリ使用量をO(1)に近い状態に抑える。
- @param Generator
$generator - @return Generator
/
public function streamSerialize(Generator $generator): Generator
{
foreach ($generator as $key => $item) {
// 1件ずつシリアライズを行うことで、ヒープ上のピークメモリを最小化する
$serialized = serialize([$key => $item]);
// Base64エンコードやバイナリセーフな区切り文字で安全にラップする
yield base64_encode($serialized) . “\n”;
}
}
/
- ストリーム状にシリアライズされたデータを1件ずつ安全に復元する。
- @param iterable
$streamLines - @return Generator
/
public function streamUnserialize(iterable $streamLines): Generator
{
foreach ($streamLines as $line) {
$line = trim($line);
if ($line === ”) {
continue;
}
$decoded = base64_decode($line, true);
if ($decoded === false) {
throw new RuntimeException(‘Failed to decode serialized stream line.’);
}
// クラスホワイトリストを厳格に指定し、安全性を担保しつつ復元
$data = unserialize($decoded, [
‘allowed_classes’ => [
\App\Domain\Entity\TargetEntity::class,
// 許可するクラスを必要最小限に絞る
]
]);
if ($data === false && $decoded !== serialize(false)) {
throw new RuntimeException(‘Failed to unserialize data chunk.’);
}
// 1件ずつyieldすることで、メモリ上に全展開させない
foreach ($data as $key => $value) {
yield $key => $value;
}
}
}
}
—
4. テクニカルリードからの設計指針：プロセスの寿命を意識せよ
PHPは「リクエストごとにメモリが完全に解放される安全な言語」という神話がまことしやかに囁かれているが、それはあくまでシンプルかつ行儀の良いコードを書いている時に限る話だ。
1. `unserialize` は信頼の置けない外部入力（DBの不穏なカラム、古いキャッシュ、ユーザー入力）に対して絶対に使用してはならない。 必ず `allowed_classes` オプションを指定し、想定外のクラスインジェクション攻撃をシャットアウトせよ。
2. 巨大なオブジェクトグラフをセッションや単一のキャッシュキーに詰め込む設計自体がアーキテクチャの敗北である。 データを正規化し、必要な粒度（ドメイン単位、あるいはプリミティブな値の配列）に分解してストアする設計へリファクタリングせよ。
3. バッチ処理やCLIスクリプトで長寿命なプロセスを回す場合、不要になったオブジェクトは速やかに参照を切断し、必要に応じて `gc_collect_cycles()` を適切なタイミングで明示的にコールせよ。 循環参照によるメモリリークは、Zend Engineの標準GCが回収するまでプロセス内に残り続ける。
パフォーマンスチューニングとは、小手先のテクニックの積み重ねではない。PHPという言語が内部のC言語レイヤでメモリをどう扱い、OSにどう返却しているかという「メカニズムの理解」に裏打ちされて初めて、真の堅牢なシステムが構築できるのだ。
次のコードレビューでは、あなたがチームの誰よりも深くメモリ管理を意識し、美しいコードを導き出すことを期待している。