C# の IDisposable を正しく実装する（Dispose パターンと using / ファイナライザ）

みなさんこんにちは！ヒロポンです！

SqlConnection やファイルハンドルを自前で抱えるクラスを書いてて、ふと「これ、閉じ忘れたらリークするよな？？」って手が止まったこと、ないですか。

業務系だと DB 接続を1本持つ小さなユーティリティを自作する場面、普通にありますよね。そいつを using で使えるようにしたい。要するに C# の IDisposable を実装する Dispose パターンを書きたい、という話です。

で、検索する。すると Dispose(bool disposing) だの GC.SuppressFinalize だの ~クラス名()（ファイナライザ）だのが一気に出てきて、「え、こんなに書くの?」ってなる。俺も最初これで身構えました。

先に結論。多くの業務クラスは、あの重いパターンを全部書く必要はない。抱えてるのがマネージドリソースだけなら単純版で足ります。ここでは Dispose パターンがなぜこの形なのかを、単純版 → フル版 → using の順で積み上げていきます。

忙しい人向けに最初にまとめ

• 抱えてるのがマネージドリソースだけ（SqlConnection など、それ自体 IDisposable なオブジェクト）なら → 単純な Dispose で各リソースの Dispose() を呼ぶだけ。ファイナライザも GC.SuppressFinalize も要らない
• 自分でアンマネージドリソース（ネイティブハンドル等）を確保している時だけ → Dispose(bool) パターン + ファイナライザ + GC.SuppressFinalize
• 使う側は using で包むだけ。ブロックを抜ける時に例外が出ても、自動で Dispose が呼ばれる
• ハマりどころは「マネージドだけなのにファイナライザを書いて GC 負荷を増やす」パターンと「Dispose を呼び忘れて GC 任せにし、接続プールが枯渇する」パターン

コードは記事の中盤（単純版 → フル版）に全部あります。

そもそも IDisposable は何を解決するのか

C# の IDisposable は、もう使わないリソースを、GC を待たずに「今すぐ」確定的に解放するための仕組みです。定義はたった1メソッド。

public interface IDisposable
{
    void Dispose();
}

なんでこんなものが要るのか。C# はメモリを GC（ガベージコレクタ）が自動で回収してくれる。ん？だったらメモリだけ見れば Dispose は要らないよな、って思いますよね。

引っかかるのはメモリ以外のリソースです。DB 接続、ファイルハンドル、ソケット、ロック。この手のやつは数に上限があったり、開いてる間ずっと他をブロックしたりする。GC がいつ回収するかは不定。「使い終わったら即閉じる」を GC 任せにはできないわけです。

だから .NET は約束を用意した。「後始末を持つオブジェクトは IDisposable を実装してね、使う側は責任を持って Dispose を呼んでね」。これが IDisposable の正体です。

ここまでで分かったこと: IDisposable は「メモリ以外のリソースを確定的に閉じる」ための約束。中身は Dispose() 1個だけ。

パターン1: 単純な Dispose（マネージドリソースだけ）

まずはいちばん多いケース。自分のクラスが抱えてるのが、すでに IDisposable なマネージドオブジェクトだけのとき。

たとえば「DB 接続を1本持って、それ経由で書き込むだけ」のクラス。やることは「抱えてる子の Dispose を呼ぶ」だけです。

動く形で書くと、こんな感じになります（SqlConnection の代わりに、動作確認できるよう StringWriter をマネージドリソース役にしています）。

using System;
using System.IO;

class ManagedResourceHolder : IDisposable
{
    private readonly StringWriter _writer; // マネージドリソース (それ自体 IDisposable)
    private bool _disposed;

    public ManagedResourceHolder()
    {
        _writer = new StringWriter();
        Console.WriteLine("リソースを開いた");
    }

    public void Write(string text) => _writer.Write(text);

    public void Dispose()
    {
        if (_disposed) return;   // 二重 Dispose を無害化 (冪等にする)
        _writer.Dispose();       // 抱えているマネージドリソースを閉じる
        _disposed = true;
        Console.WriteLine("リソースを閉じた");
    }
}

class Program
{
    static void Main()
    {
        using (var holder = new ManagedResourceHolder())
        {
            holder.Write("処理中...");
        } // ここを抜けると自動で Dispose される
        Console.WriteLine("using を抜けた");
    }
}

実行結果:

ポイントは3つ。

1. ファイナライザ（~ManagedResourceHolder()）は書いていない。抱えてるのがマネージドだけなら要らない
2. GC.SuppressFinalize も呼んでいない。ファイナライザが無いので、抑制する対象もないから
3. _disposed フラグで二重呼び出しを無害化している。Dispose は何回呼ばれても壊れない、が定石

「え、これだけ?」って思うでしょ。これだけです。検索で出てくる重いパターンは、次の「アンマネージドを持つ場合」の話。業務で書く自作クラスの大半は、この単純版で足ります。

継承させる予定がないなら、いっそ sealed class ManagedResourceHolder にしておく。そうすると後で出てくる Dispose(bool) の仮想メソッド版すら考えなくてよくなります。いい感じにシンプルになる。

ここまでで分かったこと: マネージドリソースだけを抱えるなら、Dispose() の中で子の Dispose() を呼び、二重呼び出しをフラグでガードするだけ。ファイナライザは不要。

パターン2: Dispose(bool) パターン（アンマネージド + ファイナライザ）

次。自分で「アンマネージドリソース」を確保している場合です。ネイティブ API から取ったハンドル、Marshal.AllocHGlobal で確保したメモリ、みたいなやつ。

これらは GC が中身を知らない。だから「万が一 Dispose を呼び忘れられても、最後に GC のタイミングで解放したい」という保険がほしくなる。その保険がファイナライザです。

しかも、Dispose から呼ばれた時とファイナライザから呼ばれた時で、やっていい後始末が違う。この2経路を1メソッドにまとめたのが Dispose(bool disposing) です。

using System;
using System.IO;

class FullResource : IDisposable
{
    private IntPtr _handle;          // アンマネージドリソースの代役 (ネイティブハンドル等)
    private StringWriter _managed;   // マネージドリソース
    private bool _disposed;

    public FullResource()
    {
        _handle = new IntPtr(1);     // 「ハンドルを確保した」体
        _managed = new StringWriter();
    }

    // 使う側から呼ばれる公開 Dispose
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);   // 後始末は済んだ。ファイナライザは走らせなくていい
    }

    // 実体。disposing で「誰から呼ばれたか」を分岐する
    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;

        if (disposing)
        {
            // Dispose() 経由のときだけ、マネージドリソースに触ってよい
            _managed?.Dispose();
            Console.WriteLine("マネージド + アンマネージドを解放");
        }
        else
        {
            Console.WriteLine("アンマネージドだけ解放 (ファイナライザ経由)");
        }

        // アンマネージドは、どちらの経路でも必ず解放する
        if (_handle != IntPtr.Zero) _handle = IntPtr.Zero;

        _disposed = true;
    }

    // ファイナライザ。Dispose 呼び忘れの保険
    ~FullResource() => Dispose(false);
}

disposing の真偽で何が変わるのか。ここが一番の勘所です。

• Dispose(true)（Dispose() から）→ 呼び出し元がまだ生きてる普通の後始末。マネージドもアンマネージドも両方閉じてよい
• Dispose(false)（ファイナライザから）→ GC が回してる最中。マネージドオブジェクトはもう回収済みかもしれないので触らない。アンマネージドだけ解放する

なんでファイナライザからマネージドに触っちゃダメなのか？？ ファイナライザが走る順番は保証されないからです。自分が抱えてる _managed が、自分より先にファイナライズされている可能性がある。そこに触ると未定義の挙動。だから disposing == false の側では、マネージドに一切手を出さない。

動かして両方の経路を見るとこうなります。

class Program
{
    static void Main()
    {
        // (1) using 経由: Dispose(true) が走る
        using (var r = new FullResource())
        {
            Console.WriteLine("using ブロック内");
        }

        // (2) わざと Dispose せず GC に回収させる: ファイナライザ = Dispose(false) が走る
        MakeGarbage();
        GC.Collect();
        GC.WaitForPendingFinalizers();
        Console.WriteLine("完了");
    }

    static void MakeGarbage()
    {
        var leaked = new FullResource(); // Dispose を呼ばずに捨てる
    }
}

実行結果:

(1) は Dispose() から Dispose(true)、(2) は閉じ忘れをファイナライザが Dispose(false) で拾ってる。ちゃんと経路が分かれてる！！

ここまでで分かったこと: アンマネージドを持つ時だけ、ファイナライザで保険をかける。disposing フラグで「マネージドに触っていいか」を分岐する。

GC.SuppressFinalize は何をしているのか

Dispose() の中に1行だけ出てきた GC.SuppressFinalize(this)。これをサラッと飛ばす記事が多いんだけど、業務SEがいちばん「?」ってなる行なので、ちゃんと言います。

ファイナライザを持つオブジェクトは、GC が1回では回収できない。いったんファイナライズ用のキュー（finalization queue）に載せ、専用スレッドでファイナライザを走らせ、その次の GC でようやく本体を回収する。つまり回収に GC が2回かかり、世代も1つ上がる。地味にコストです。

でも Dispose() を呼んだ時点で後始末はもう終わってる。だったらファイナライザを走らせる意味はない。そこで GC.SuppressFinalize(this) を呼んで、「こいつのファイナライザはもう要らないから、キューに載せないで」と GC に伝える。これで2回コレクションのコストが消える。

まとめるとこういう対応関係です。

だから理想は「毎回ちゃんと Dispose を呼んで、ファイナライザは一度も走らせない」。ファイナライザはあくまで最後の保険であって、常用ルートじゃない。ここを勘違いして「ファイナライザがあるから閉じ忘れても大丈夫」と思い込むと、後で出てくるハマりに直行します。

あと、パターン1（単純版）では GC.SuppressFinalize は呼ばなくていい。抑制すべきファイナライザがそもそも無いから。「Dispose には必ず SuppressFinalize を書く」と機械的に覚えると、単純版で無駄な1行を足すことになる。要るのはフルパターンの時だけです。

パターン3: using で自動的に閉じる（使う側の話）

ここまではクラスを作る側の話でした。作ったクラスを使う側は、using で包むだけです。

using はコンパイル時に try / finally へ展開されます。手で書くと抜け漏れるやつを、コンパイラが確実にやってくれる。

after 側が裏でやってることを図にすると、こう。

例外が飛んでも finally で必ず Dispose される。これが using の効きどころです。手動の try / catch だと、途中で return したり別の例外が重なったりで閉じ忘れる。あなたも早期 return で finally を素通りさせた経験、ありませんか。using ならそこを気にしなくていい。

ちなみに C# 8.0 からは、ブロックすら書かない using 宣言も使えます。

using var conn = new SqlConnection(connStr);
conn.Open();
// ... 処理 ...
// メソッド (スコープ) を抜ける時に自動で Dispose