序章：静的なコードの裏側で、Zend VMとメモリ空間は何を見ているのか
コードレビューをしていて、「なぜこのクラス設計にしたのか」と問うたとき、決まって返ってくる言葉がある。
「オブジェクト指向的に依存関係を綺麗に注入した結果です」
その美辞麗句の裏で、PHPのプロセス空間――正確にはZend Engineのメモリマネージャ（emalloc）が悲鳴を上げていることに、どれほどのエンジニアが気づいているだろうか。
PHPはリクエストライフサイクルが極めて短い「リクエスト指向」の言語であるため、かつては「メモリリークなど起きたところで、リクエスト終了時にOSがプロセスごと全回収してくれる」という甘美な免罪符が存在した。しかし、現代のPHPアーキテクチャは違う。常駐型アプリケーション（ReactPHP, Swoole, RoadRunner, あるいは長大なバッチ処理）において、メモリリークは単なるパフォーマンス低下ではなく、システムを死に至らしめる致命的な毒だ。
特に、循環参照（Circular Reference）は、Zend VMの参照カウント（Reference Counting）の網をかいくぐり、ガベージコレクション（GC）のバッファを圧迫し続ける。今回は、この循環参照を誘発する実務のアンチパターンを解剖し、Cレベルのメモリ管理の視点から「なぜそれが危険なのか」、そして静幾解析を用いてコンパイル前・実行前にどう駆逐すべきかを叩き込む。
—
1. Zend VMの参照カウントと、循環参照が「回収されない」メカニズム
PHPのすべての変数、すべてのオブジェクトは、内部で `zval`（Zend Value）という構造体として表現されている。オブジェクトはさらに `zend_object` としてヒープ上にアロケートされ、その構造体内部には `refcount` という参照カウンタが存在する。
通常、変数が別の変数に代入されたり、関数に渡されたりすると、この `refcount` がインクリメントされる。スコープを抜けるなどして変数が破棄されると `refcount` はデクリメントされ、`0` になった瞬間に `emult_free()` が走ってメモリが解放される。これが、PHPが誇る高速な自動メモリ管理の正体だ。
しかし、次のような親子関係や双方向の関連を構築した瞬間、この美しい仕組みは崩壊する。
[ Object A (refcount: 2) ] <-----> [ Object B (refcount: 1) ]
AがBを保持し、BがAを指す。お互いを指し合っているため、外部からの参照がすべて消滅したとしても、AとBの `refcount` は `1` のまま残る。
`refcount > 0` であるため、Zend VMは「まだこいつらは生きている」と判断し、通常のスコープ解放時にはメモリを解放しない。これが メモリリーク の正体である。
PHPには、この孤立した循環参照の群れを救うために「循環ガベージコレクタ（Concurrent Garbage Collector）」が搭載されている。しかし、GCはすべての代入のたびに走るわけではない。バッファ（`gc_root_buffer`）が溢れそうになったときや、明示的に `gc_collect_cycles()` が呼ばれたときにのみ、数千・数万の `zval` をスキャンして `refcount` を減算調整する重い処理（Mark and Sweepアルゴリズムの変種）が走る。
つまり、循環参照を多発させる設計は、「後からGCが掃除してくれるからいいや」という甘えではなく、「常にGCに高負荷なバックグラウンドスキャンを強要し、CPUキャッシュをヒットさせず、レスポンスタイムを悪化させる時限爆弾」を仕込んでいると同義なのだ。
—
2. 実務で頻出する「循環参照アンチパターン」
では、実際のビジネスロジックにおいて、どのようなコードがこの循環参照を誘発するのか。典型的なアンチパターンをコードで見ていこう。
アンチパターン①：双方向リレーション（Parent-Child / Peer-to-Peer）
ORMやドメインモデル（DDD）のエンティティ設計において、親が子を持ち、子が親のコンテキスト（インスタンス）を知る必要があるという名目で実装されるパターン。
/
class Project
{
/ @var Task[] /
private array $tasks = [];
public function addTask(Task $task): void
{
$this->tasks[] = $task;
// ここで自分自身（Project）の参照をTaskに渡している（循環の萌芽）
$task->setProject($this);
}
}
class Task
{
private ?Project $project = null;
public function setProject(Project $project): void
{
$this->project = $project;
}
}
何が問題か：
`Project` は複数の `Task` を配列で保持し、各 `Task` は親である `Project` のインスタンスをプロパティとして保持する。インスタンス破棄時に明示的なグラフの切断（後述するデストラクタや弱参照）を行わない限り、このインスタンス群はリクエスト中ずっとメモリ上にゾンビとして残り続ける。
アンチパターン②：クロージャ（匿名関数）による外部スコープのキャプチャ
イベントリスナーやDIコンテナ、非同期タスクのコールバックにおいて、 `$this` や巨大なオブジェクトグラフをクロージャ内に `use ($this)` やプロパティ代入で保持するケース。
eventListeners[‘process’] = function (array $data): void {
$this->logProcess($data);
};
}
private function logProcess(array $data): void
{
// ログ処理
}
}
何が問題か：
クロージャオブジェクト自体が内部に束縛された変数（この場合は `$this`）への参照を保持する。クラスのプロパティにそのクロージャを代入すると、「オブジェクト -> プロパティ(クロージャ) -> 束縛コンテキスト($this)」 という見事な自己循環参照の輪が完成する。
—
3. 弱参照（WeakReference）による現代的解決
PHP 7.4以降、我々にはこの循環参照地獄をスマートに回避する強力な武器が与えられている。それが `WeakReference`（弱参照） だ。
弱参照とは、オブジェクトへの参照を保持しつつも、そのオブジェクトの `refcount` をインクリメントしない特殊な参照形式である。オブジェクトの所有権を主張せず、「存在していればアクセスするが、他の誰も持たなくなったら勝手に消えてくれ」という、まさにリレーションの理想形である。
先ほどの「プロジェクトとタスク」の例を、`WeakReference` を使って堅牢にリファクタリングしてみよう。
tasks[] = $task;
$task->setProject($this);
}
}
class Task
{
/ @ை WeakReference
private ?\WeakReference $projectRef = null;
public function setProject(Project $project): void
{
// 弱参照として保持するため、Projectのrefcountは増えない
$this->projectRef = \WeakReference::create($project);
}
public function getProject(): ?Project
{
// 弱参照経由でインスタンスを取得。既に親が破棄されていれば null が返る
return $this->projectRef?->get();
}
}
この設計であれば、`Project` への外部からの参照が絶たれた瞬間、`Project` の `refcount` は `0` になり、即座にメモリから消え去る。同時に、`Task` 側から親を覗こうとした際も、`$projectRef?->get()` は安全に `null` を返すため、ダングリングポインタ（不正なメモリ参照）を踏むリスクもゼロになる。
—
4. 静的解析（PHPStan / Psalm）による循環参照の自動検出
コードレビューで人間の目で循環参照を見つけるのは、干し草の中から針を探すようなものだ。アーキテクトとして、属人性を排し、CI/CDパイプライン上でこれを完全に機械的に弾く仕組みを構築しなければならない。
PHPエコシステムにおける最高峰の静的解析ツール PHPStan（Level 8以上）または Psalm を用いて、メモリリークのリスクを検知・予防するアプローチを解説する。
PHPStanでのルール設定とカスタムチェック
デフォルトのPHPStanでも、デッドコードや一部の複雑な型構造は検知できるが、アーキテクチャ固有の「ドメインモデルにおける双方向参照の禁止」などを強制するには、PHPStanのカスタムルール（Custom Rules） を書くか、Architecture Testツールである deptrac を導入するのが最も効果的である。
ここでは、`deptrac` を用いてレイヤー間の依存関係を制御し、不必要な逆流（下位レイヤーから上位レイヤーへの密結合）を防ぐアプローチを推奨する。
`deptrac.yaml` の実務的な設定例：
deptrac:
paths:
- src/
exclude_files:
- src/Kernel.php
layers:
- name: Domain
collectors:
- type: className
value: #^App\\Domain\\#
- name: Infrastructure
collectors:
- type: className
value: #^App\\Infrastructure\\#
ruleset:
Domain:
# Domain層はInfrastructure層に依存してはならない（依存性逆転の原則）
# これを守ることで、ORMの都合による循環参照の多くを未然に防ぐ
Infrastructure:
- Domain
さらに、Psalmを使用している場合は、型アノテーションの厳密性と副作用の解析が優れているため、クロージャ内での `$this` キャプチャや、意図しないミュータブルな参照渡しを検出させることができる。
CI（GitHub Actionsなど）のパイプラインに以下を組み込む。
name: Static Analysis
on: [pull_request]
jobs:
phpstan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.2’
tools: phpstan, deptrac
- name: Run Deptrac
run: vendor/bin/deptrac analyze –config-file=deptrac.yaml
- name: Run PHPStan
run: vendor/bin/phpstan analyse –level=max src/
これにより、開発者がレビューに出す前に「循環参照を誘発するような危険なレイヤー結合やプロパティ代入」はすべて機械的にブロックされる。
—
5. デバッグ手法：実運用環境でのメモリリークプロファイリング
もし本番環境の常駐プロセス（SwooleやLong-running Worker）でメモリリークの兆候（プロセスごとのRSSメモリの右肩上がり）が検知された場合、どのように犯人（循環参照オブジェクト）を特定すべきか。
ここで投入すべきツールが Xdebug および Memprof（あるいはPHP 7/8向けのメモリプロファイラ）である。
memory_get_usage() と gc_status() による簡易診断ロジック
バッチ処理やAPIのエンドポイントの各処理の前後で、明示的にGCの状態とメモリ消費量をロギングするコードを挟むことで、リークの傾向を掴むことができる。
「GCが回収しきれていない、あるいはGCのバッファサイズを超えて取り残されている循環参照オブジェクト」が存在する動かぬ証拠である。
その場合は、疑わしいクラスのデストラクタ（`__destruct()`）に一時的にログを仕込み、
`error_log(__CLASS__ . ‘ destroyed’);`
が表示されないインスタンスをあぶり出す。デストラクタが呼ばれない＝参照カウントが0になっていない＝循環参照の罠にハマっている、という王道のデバッグパスを辿ることで、数千クラスあるコードベースからでも数分でリーク源を特定できる。
—
結び：コードの美しさは、メモリの美しさに直結する
「動けばいい」の精神で書かれたコードは、オブジェクトの結びつきを安易に双方向のポインタで結びたがる。しかし、真に洗練されたシステムアーキテクチャとは、データの流れる方向（Unidirectional Data Flow）が明確であり、オブジェクトのライフサイクルが単方向の階層構造に美しく支配されているものである。
PHPという言語の実行エンジン、Zend VMのメモリ管理の機微を理解した上でコードを書くこと。それこそが、ジュニアクラスのプログラマと、世界を支えるシニアアーキテクチャの決定的な違いである。
明日、あなたが書くそのクラスのプロパティは、本当に「双方向」でなければならないのだろうか？ `WeakReference` を使うべき場所を見落としていないか。今一度、コードベースのメモリ空間に思いを馳せてほしい。