【ITニュース解説】Memory Leaks em JavaScript: Diagnóstico, Causas Reais e Correção

JavaScriptで開発されたNode.jsアプリケーションが、特定の時間、例えば40分おきに自動で再起動してしまう場合、これは単なるロジック上のバグではなく、「メモリリーク」という深刻な問題が潜んでいる可能性が高い。メモリリークとは、プログラムが本来不要になったはずのメモリ領域を解放せず、誤って保持し続けてしまう現象を指す。このような状態が続くと、アプリケーションが使用できるメモリが徐々に減少し、最終的にはメモリ不足でプロセスが強制終了してしまう。この現象は「OOMKilled」と呼ばれ、アプリケーションの安定性やパフォーマンスを著しく低下させる原因となる。一時的にメモリ使用量を増やす設定変更は根本的な解決にはならず、問題の原因を特定し修正することが不可欠となる。

JavaScriptのメモリ管理は、V8エンジンと呼ばれる仕組みが自動的に行っている。この役割を担うのが「ガベージコレクタ（GC）」だ。しかし、ガベージコレクタの仕組みについてはしばしば誤解がある。よく言われる「参照カウント方式」というのはV8エンジンでは採用されていない。参照カウント方式では、オブジェクトがどれだけの他のオブジェクトから参照されているかを数え、その数がゼロになったらメモリを解放する。しかしこの方式には「循環参照」、つまりAがBを参照し、BがAを参照しているような場合に、どちらも参照カウントがゼロにならず、永遠にメモリが解放されないという欠点がある。

V8エンジンのガベージコレクタは「マーク＆スイープ」という方式を採用している。この方式の鍵となるのは「到達可能性（reachability）」という考え方だ。V8はまず、「ガベージコレクションの根っこ（GC roots）」と呼ばれる特別なオブジェクトの集合からスタートする。これらの根っこには、JavaScriptのグローバルオブジェクト（ブラウザならwindow、Node.jsならglobal）、現在実行中の関数の実行スタックにある変数、アクティブな「クロージャ」（外部変数を参照している関数）、そしてブラウザ環境ならDOMツリー上の生きている要素などが含まれる。V8はこれらの根っこから辿れるすべてのオブジェクトを「生きている（到達可能）」とマークする。そして、マークされなかったオブジェクト、つまりGCルートからたどり着くことのできないオブジェクトは、たとえ他のオブジェクトから参照されていても「不要なゴミ」と判断し、メモリから解放する。したがって、先ほどの循環参照の例のように、オブジェクトAとBが互いを参照し合っていても、GCルートからAにもBにも到達できなければ、両方とも正しくメモリから解放される。これは、不要な「コード防御」を書く必要がないことを意味している。

V8エンジンのヒープメモリ（JavaScriptオブジェクトが格納される領域）は、効率的なガベージコレクションのために「世代」に分かれている。新しく作成されたオブジェクトはまず「New Space（新規領域）」に配置される。この領域は比較的小さく、非常に頻繁に「Scavenger（スカベンジャー）」と呼ばれる高速なガベージコレクションが行われる。ScavengerによるGCを複数回生き延びたオブジェクト（つまり、比較的長期間にわたって使用されると判断されたオブジェクト）は、「Old Space（旧領域）」に昇格して移動する。Old SpaceはNew Spaceよりもはるかに大きく、ここでのガベージコレクションは「Mark-Compact（マークコンパクション）」と呼ばれ、Scavengerよりもコストがかかる（処理に時間がかかる）。メモリリークのほとんどは、本来不要になるはずのオブジェクトがOld Spaceに昇格し、そこから解放されずに残り続けることで発生する。

重要なのは、「割り当て圧力（allocation pressure）」と「実際のメモリリーク」を区別することだ。アプリケーションが短期間に大量のオブジェクトを生成し、すぐにそれらが不要になる場合、New SpaceでのGCの頻度やコストは増加するが、全体的なメモリ使用量（ヒープ使用量）は安定する傾向にある。これはメモリリークではなく、単にGCが頻繁に働く「割り当て圧力」の状態である。しかし、強制的にガベージコレクションを実行した後でも、アプリケーションのヒープ使用量が時間とともに単調に増え続ける場合は、間違いなくメモリリークが発生していると判断できる。

メモリリークを正確に診断するためには、Node.jsアプリケーションをnode --expose-gcというオプション付きで実行する必要がある。このオプションを使うと、JavaScriptコード内からglobal.gc()という関数を呼び出し、いつでもメジャーGC（Old SpaceのGC）を強制的に実行できるようになる。これにより、一時的な「ゴミ」やGC待ちのオブジェクトによる見かけ上のメモリ使用量増加ではなく、本当にメモリから解放されずに残っているオブジェクトがどれだけあるかを正確に測定できる。process.memoryUsage()関数を使えば、現在のメモリ使用状況の詳細を取得できる。この関数が返す情報のうち、heapUsedはV8エンジンがJavaScriptオブジェクトのために使用しているメモリ量、externalはV8エンジンが管理するがJavaScriptヒープ外にあるメモリ（例えばNode.jsのBufferオブジェクトやネイティブアドオンが使用するメモリ）、arrayBuffersはArrayBufferオブジェクトが使用するメモリ量を示す。heapUsedが継続的に上昇するならJavaScriptヒープ内のリーク、heapUsedは安定しているのにプロセス全体のメモリ使用量（RSS: Resident Set Size）が上昇するなら、V8ヒープ外のメモリリーク（Bufferの使いすぎ、ネイティブアドオンの問題、メモリ確保システムの断片化など）が原因である可能性が高い。この区別は、メモリリークの根本原因を探る上で非常に重要となる。

Node.jsやシングルページアプリケーション（SPA）におけるメモリリークの最も一般的な原因の一つに、「イベントリスナーの未削除」が挙げられる。addEventListener()や.on()といったメソッドを使ってイベントリスナーを登録すると、イベントを発行する側のオブジェクト（イベントエミッター）は、そのリスナー関数に対して「強い参照」を持つことになる。さらに、そのリスナー関数が「クロージャ」として定義されている場合、関数が定義されたスコープ内の変数も解放されずにメモリに残り続ける可能性がある。例えば、特定のUIコンポーネントがイベントリスナーを登録し、そのコンポーネントが画面から削除されても、登録したリスナーが明示的にremoveEventListener()や.off()で削除されないままだと、イベントエミッターはリスナー関数への参照を持ち続け、結果としてそのリスナー関数とそれが参照するすべてのオブジェクトがメモリから解放されず、リークが発生する。このようなケースでは、コンポーネントのライフサイクルに合わせて、不要になったリスナーを必ず削除する処理を組み込むことがメモリリークを防ぐ上で極めて重要となる。