---
title: "メモリリークとは？原因の特定方法と直し方を言語・環境別に解説"
url: "https://www.issoh.co.jp/tech/details/3621/"
published: 2024-09-20
updated: 2026-09-27
categories: ["開発"]
publisher: "株式会社一創"
---

# メモリリークとは？原因の特定方法と直し方を言語・環境別に解説

メモリリークは、不要になったメモリ領域が解放されずに残り続け、時間とともに使用量が増えていく不具合です。短時間しか動かないプログラムでは表面化しませんが、サーバーや常駐アプリのように長く動くものでは、最終的に動作が重くなり、強制終了やクラッシュにつながります。この記事では、定義と仕組み、起こる原因、発生を確認・特定する手順、検出ツール、対処と予防までを整理し、最後にJava/JVM・JavaScript/Node.js・C/C++・ブラウザといった環境別の典型原因と直し方をまとめます。

メモリ不足の症状がリークなのかスワップの往復なのかを切り分ける手順は[スワッピングとは？ページングとの違いとスラッシングの判定手順](https://www.issoh.co.jp/tech/details/17561/)で扱っています。

## まとめ：メモリリークの要点

メモリリークの全体像は、次の5点に集約できます。

- メモリリークは「使い終わったメモリへの参照が残り、ガベージコレクタ（GC）が回収できない」状態。CやC++のように手動管理する言語だけでなく、JavaScriptやJavaなど自動管理の言語でも起こる。
- 実務でまず疑うのは、解除し忘れたイベントリスナー・タイマー、グローバル変数やキャッシュへの溜め込み、循環参照の3つ。
- 確認は「メモリ使用量が右肩上がりに増え、操作を戻しても下がらない」かどうか。原因特定はヒープスナップショットを2点取って差分を見るのが基本。
- 直し方の核は「不要になった参照を確実に切る」こと。リスナーやタイマーの解除、非同期処理の中断（AbortController）、キャッシュの上限化が定番。
- 環境によって出方が違う。Javaは`OutOfMemoryError: Java heap space`、ブラウザはタブの肥大化、C/C++は`malloc`と`free`の非対称として現れる。

## メモリリークの仕組みと回収されない理由

メモリリークとは、プログラムが確保したメモリのうち、もう使わない領域を解放しないまま保持し続ける現象を指します。通常、オブジェクトが不要になればメモリは回収されますが、どこかから参照が残っていると「まだ使う」と判断され、回収対象から外れます。これが積み重なると、使用可能なメモリが少しずつ削られていきます。

自動メモリ管理の言語では、ガベージコレクタが「どこからも参照されていないオブジェクト」を不要とみなして回収します。逆に言えば、参照が1つでも残っていれば回収されません。メモリリークの正体は、多くの場合「意図せず残ってしまった参照」です。ガベージコレクタの役割と限界については[ガベージコレクションとは何か、その基本的な概念と目的について解説](/tech/details/3084/)で詳しく扱っています。

### メモリリーク・リソースリーク・メモリ不足の違い

似た言葉が混同されがちなので、先に整理します。リソースリークはファイルハンドルやソケット、データベース接続など、メモリ以外の資源を解放し忘れる広い概念で、メモリリークはそのうちメモリに限ったものです。ハンドルリークはOSが管理するハンドルが解放されないケースを指します。一方、メモリ不足（out of memory）は結果の状態であり、原因はメモリリークのこともあれば、単に必要量が物理メモリを超えただけのこともあります。

| 用語      | 対象            | 性質            |
| ------- | ------------- | ------------- |
| メモリリーク  | メモリ領域         | 解放漏れ（原因）      |
| リソースリーク | ファイル・接続など資源全般 | 解放漏れ（原因・上位概念） |
| ハンドルリーク | OSのハンドル       | 解放漏れ（原因）      |
| メモリ不足   | システム全体        | 枯渇した状態（結果）    |

「メモリは余っているのに不足と言われる」場合、リークだけでなく、断片化や1プロセスあたりの上限設定が絡むこともあります。原因（リーク）と結果（不足）を切り分けて考えると、調査の方向を誤りません。

## メモリリークが起こる主な原因

原因は言語をまたいで共通するものが多く、突き詰めれば「切れていない参照」に行き着きます。実務での遭遇頻度が高い順に並べます。

| 原因              | 仕組み             | 典型例                          |
| --------------- | --------------- | ---------------------------- |
| リスナー・タイマー解除漏れ   | 登録先が参照を保持し続ける   | addEventListener、setInterval |
| グローバル・キャッシュ溜め込み | 長命なオブジェクトが参照を握る | グローバル変数、上限なしキャッシュ            |
| 循環参照            | 互いに参照し合い回収されない  | 親子オブジェクトの相互参照                |
| クロージャの保持        | 関数が外側の変数を抱え込む   | コールバック内の巨大変数                 |
| デタッチDOM（ブラウザ）   | 画面から外れた要素を変数が握る | 削除済みノードへの参照                  |

まず疑うべきはリスナーとタイマーの解除漏れです。これは登録した側が処理関数を覚え続けるため、対象を削除しても処理関数経由でメモリが残ります。次に多いのが、グローバル変数や上限のないキャッシュへの溜め込みです。「とりあえず保存」が積み重なると、いつまでも回収されません。循環参照は、近年の主要なガベージコレクタなら多くは回収できますが、外部資源やネイティブ層が絡むと残ることがあります。

## メモリリークの確認方法と原因特定の手順

「リークしているかどうか」と「どこが原因か」は別の問いです。前者は使用量の推移、後者はヒープの中身で判断します。

### リークの兆候を見分ける

判定の軸はシンプルで、同じ操作を繰り返したときにメモリ使用量が右肩上がりに増え、操作を元に戻しても下がらないかどうかです。一時的な増加はキャッシュやバッファのことも多いため、「増えたまま戻らない」点が見極めの鍵になります。サーバーなら数時間〜数日の連続稼働で監視し、ブラウザならタブを開閉しながら使用量を観察します。最終的に応答が遅くなり、Javaなら`OutOfMemoryError`、ネイティブなら確保失敗やクラッシュに至ります。

### 原因を特定する手順

原因特定の定番は、ヒープスナップショットの2点比較です。リークが疑われる操作の前後でスナップショットを取り、差分として増え続けているオブジェクトを洗い出します。次に、そのオブジェクトを「誰が保持しているか」を参照チェーンでたどります。Java向けのEclipse Memory Analyzer（MAT）では、メモリを大きく占有する対象を示すDominator Tree、回収されない理由を示すPath to GC Rootsを使い、保持元まで一直線にたどれます。ブラウザのヒープスナップショットでも、Retainers（保持元）を見れば同じ判断ができます。増えているオブジェクトの「型」と「保持元」の2つが分かれば、原因コードはほぼ絞り込めます。

## メモリリークの検出ツール

言語・環境ごとに定番ツールが分かれます。まずは標準で使えるものから始め、自動化や深掘りが必要になったら専用ツールを足すのが現実的です。

| 環境         | ツール                                  | 主な用途                 |
| ---------- | ------------------------------------ | -------------------- |
| ブラウザ（JS）   | Chrome DevTools / Edge DevTools      | ヒープスナップショット・Memoryタブ |
| JS/Node.js | memlab                               | スナップショット自動取得・差分検出    |
| Java/JVM   | VisualVM / Eclipse MAT / jcmd・jmap   | ヒープダンプ取得・解析          |
| C/C++      | Valgrind（Memcheck）/ AddressSanitizer | 解放漏れ・不正アクセス検出        |

JavaScriptは、まずChrome DevToolsの「Memory」タブでヒープスナップショットを取るのが出発点です。手作業を自動化したいときは、Metaが2022年9月にオープンソース公開したmemlabが有効です。memlabはヘッドレスブラウザの操作にPuppeteerを使うため、スナップショット取得から差分抽出までを自動化できます（PuppeteerとDevToolsプロトコルの関係は[Puppeteerとは何か？DevToolsプロトコルとNodeライブラリの役割](/tech/details/3844/)を参照）。Javaは、JDKに同梱されるVisualVMでヒープダンプを取得し、Eclipse MATで深く解析する組み合わせが定番です。C/C++では、ソースが手元になくても動くValgrindのMemcheckと、コンパイル時に`-fsanitize=address`を付けて高速に検出するAddressSanitizerを使い分けます。AddressSanitizerはValgrindより大幅に高速ですが、専用にビルドし直す必要があります。

## メモリリークの対処・解消と予防

直し方の原則は1つで、不要になった参照を確実に切ることです。個別のテクニックはこの原則の具体化にすぎません。

第一に、登録したものは必ず解除します。`addEventListener`には対応する`removeEventListener`を、`setTimeout`や`setInterval`には`clearTimeout`・`clearInterval`を必ず対にします。Reactなど、コンポーネントの破棄タイミングが明確なフレームワークでは、後始末用の関数にこれらの解除をまとめます。第二に、完了前に不要になる非同期処理は中断します。fetchなら`AbortController`で取り消すのが標準的です（非同期処理の基礎は[JavaScriptの非同期処理: async/awaitの基礎とその利便性について](/tech/details/3691/)が参考になります）。第三に、キャッシュは必ず上限や有効期限を設け、無制限に溜めない設計にします。キーにオブジェクトを使う場合、参照が残ってほしくないなら`WeakMap`や`WeakRef`を選ぶと、不要時に自動で回収されます。

予防は、設計と運用の両輪で考えます。設計面では、長命なオブジェクトに短命なオブジェクトの参照を持たせないこと、参照の向きを一方向に保ち循環を作らないことが効きます。運用面では、本番に近い環境で連続稼働させてメモリ推移を監視し、リークの兆候を早期に拾います。memlabのような検出をCIに組み込めば、リークを生むコードがマージされる前に気づけます。

## 言語・環境別のメモリリークの原因と対処

原則は共通でも、現れ方と直し方は環境で異なります。自分の環境の節だけ拾い読みしても構いません。

### Java・JVM：staticコレクションとClassLoaderリーク

JavaはGCがある一方で、長命なオブジェクトが短命なオブジェクトを抱え込むタイプのリークが起きます。代表例は、staticなコレクション（ListやMap）に要素を入れ続けて消さないケース、独自ClassLoaderが解放されないケースです。Tomcatのようなアプリケーションサーバーでは、アプリの再デプロイを繰り返すうちにClassLoaderリークが蓄積し、`OutOfMemoryError: Java heap space`や`Metaspace`不足として表面化します。対処は、`jcmd`や`jmap`でヒープダンプを取得し、Eclipse MATのDominator Treeで保持元を特定して、不要な参照をstaticから外すのが基本です。なお`OutOfMemoryError`は必ずしもリークが原因とは限らず、単純にヒープ上限（`-Xmx`）が小さすぎる場合もあるため、ダンプで中身を確認してから判断します。

### JavaScript・Node.js：クロージャとリスナー解除漏れ

JavaScriptでは、グローバル変数への溜め込み、解除し忘れたイベントリスナーやタイマー、外側の大きな変数を抱えたクロージャが主因です。Node.jsの常駐プロセスでは少量のリークでも長時間で蓄積するため、上限のないキャッシュや、イベントエミッタへのリスナー追加超過に注意します。検出はブラウザならChrome DevTools、サーバーやSPAの自動検出ならmemlabが向きます。直し方は前章の原則どおりで、非同期処理の中断には`AbortController`、参照を残したくないキャッシュには`WeakMap`を使います。Reactのレンダリングとメモリの関係に踏み込みたい場合は[フロントエンド開発者が理解すべきAsync Reactの技術的背景と全体像](/tech/details/11005/)も参考になります。

### C・C++：解放漏れとValgrindでの検出

手動管理のC/C++では、`malloc`や`new`で確保したメモリを`free`や`delete`で解放し忘れることがそのままリークになります。例外発生時に解放処理を飛ばしてしまうケースも多く見られます。検出にはValgrindのMemcheckが定番で、`valgrind --leak-check=full`のように実行すると、未解放のブロックと確保箇所を報告します。より高速に回したいときは、GCCやClangに組み込まれたAddressSanitizerを`-fsanitize=address`付きでビルドして使います。根本的な予防策は、C++ならスマートポインタ（`std::unique_ptr`・`std::shared_ptr`）でRAIIに任せ、生ポインタでの手動管理を減らすことです。

### ブラウザ：デタッチDOMとタブの肥大化

ブラウザでは、画面から削除されたのに変数やリスナーから参照され続ける「デタッチDOM」が典型です。タブを長時間開いたまま操作を繰り返すとメモリが膨らみ、動作が重くなります。Webアプリ側の対処は、DOM要素への参照を保持しすぎないことと、イベントリスナーを確実に解除することです。利用者側で一時的にメモリを軽くしたいだけなら、該当タブの再読み込みや、不要なタブ・拡張機能を閉じるのが手早い方法です。ただしこれは対症療法であり、特定のサイトで毎回増えるなら、そのページ自体にリークがある可能性が高いと考えてください。

## よくある質問

### メモリリークは放置するとどうなりますか？

使用量が増え続け、最終的にアプリの応答が遅くなり、強制終了やクラッシュに至ります。長時間稼働するサーバーやモバイルアプリほど影響が大きく、クラウド環境では余分なリソースを使うことでコスト増にもつながります。リーク自体が自然に直ることはないため、原因を特定して参照を切る必要があります。

### メモリリークとメモリ不足は同じですか？

違います。メモリリークは「解放漏れ」という原因、メモリ不足（out of memory）は「枯渇した」という結果です。メモリ不足の原因はリークのこともあれば、単に必要量が上限を超えただけのこともあります。「メモリは余っているのに不足と出る」場合は、断片化やプロセスごとの上限設定も疑います。

### Chromeのメモリリークはどう解消しますか？

その場しのぎなら、対象タブの再読み込みと、不要なタブ・拡張機能を閉じることで解放できます。特定のサイトで毎回増えるなら、ページ側のデタッチDOMやリスナー解除漏れが原因の可能性が高いため、Chrome DevToolsの「Memory」タブでヒープスナップショットを取り、増え続けるオブジェクトの保持元を確認します。

### 「OutOfMemoryError: Java heap space」はメモリリークですか？

必ずしもそうとは限りません。リークが原因のこともあれば、ヒープ上限（`-Xmx`）が処理量に対して小さすぎるだけのこともあります。切り分けには、`jcmd`や`jmap`でヒープダンプを取り、Eclipse MATで「何が大量に残っているか」を確認します。意図せず残っているオブジェクトが見つかればリーク、正当な使用量が上限を超えているだけなら設定の見直しです。

### メモリリークの原因特定は何から始めればよいですか？

まず、リークしているかを使用量の推移で確認し、次にヒープスナップショットを操作の前後で2点取って差分を見ます。増え続けているオブジェクトの「型」と「保持元（参照チェーン）」が分かれば、原因コードはほぼ絞り込めます。最初から細部を追わず、この2点比較から入るのが遠回りしないコツです。

## 関連記事

- [ガベージコレクションとは何か、その基本的な概念と目的について解説](/tech/details/3084/)
- [JavaScriptの非同期処理: async/awaitの基礎とその利便性について](/tech/details/3691/)
- [フロントエンド開発者が理解すべきAsync Reactの技術的背景と全体像](/tech/details/11005/)
- [Puppeteerとは何か？DevToolsプロトコルとNodeライブラリの役割](/tech/details/3844/)

---

出典: [メモリリークとは？原因の特定方法と直し方を言語・環境別に解説](<https://www.issoh.co.jp/tech/details/3621/>)（株式会社一創）