C# の yield return で大量データを遅延評価で返す（メモリを食わないイテレータ）

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

大量のデータをメソッドから返したい時、みなさんどうしてますか？？ とりあえず List に全部詰めて return。これが多いんじゃないでしょうか。

私も長いことそうでした。

でも件数が数十万、数百万と増えてくると話が変わる。その List がまるっとメモリに乗って、地味に重いんですよね。

C# には、これを「1件ずつ、必要な分だけ」返す yield return という書き方があります。今回はこの yield return の使い方を、仕組みから落とし穴まで積み上げて理解していきましょう。

そもそも: List に全部詰めると何が起きるか

まずは、ふつうに List で返すコードから。

public static List<int> GetEvens(int max)
{
    var result = new List<int>();
    for (int i = 0; i <= max; i++)
        if (i % 2 == 0) result.Add(i);
    return result;
}

これ、GetEvens(1000000) を呼ぶと、その瞬間に50万件を全部作って List に載せます。

呼び出し側が最初の10件しか要らなくても、です。全部。え、10件でよくない？？ってなりますよね。

件数が少なければ何も困りません。でも大量データになると、この「全部作ってから返す」がメモリを圧迫してくる。

ここまでのポイント: List で返すと、呼んだ瞬間に全件がメモリに乗る。

yield return とは何か

yield return は、メソッドを「1件返すたびに一時停止できる」イテレータに変える キーワードです。

ふつうのメソッドは return で値を1回返したら終わり。でも yield return は違う。値を1件返してその場で中断し、呼び出し側が次を要求したら続きから再開します。

この「呼ばれた分だけ動く」性質を 遅延評価（lazy evaluation）と呼びます。

全部先に作らず、必要になった時に初めて1件作る。そういうイメージです。

ここまでのポイント: yield return は「1件返して中断・次で再開」するイテレータを作る。

yield return はどう動くのか

もう少し仕組みを見ていきます。foreach で回すと、裏では MoveNext() が繰り返し呼ばれていて、その1回1回が yield return の1件に対応する。

言葉だけだと分かりにくいので、実際に動かして確かめます。

public static IEnumerable<int> ReadNumbers()
{
    Console.WriteLine("開始");
    for (int i = 1; i <= 3; i++)
    {
        Console.WriteLine($"  {i} を返す直前");
        yield return i;
    }
    Console.WriteLine("終了");
}

// 呼び出し側
var seq = ReadNumbers();                 // ここでは "開始" はまだ出ない
Console.WriteLine("メソッドは呼んだ。でもまだ回してない");
foreach (var n in seq)                   // ここで初めて中身が動き出す
{
    Console.WriteLine($"受け取った: {n}");
}

出力はこうなります。

メソッドは呼んだ。でもまだ回してない
開始
  1 を返す直前
受け取った: 1
  2 を返す直前
受け取った: 2
  3 を返す直前
受け取った: 3
終了

実際に .NET で動かした結果がこれです。

ReadNumbers() を呼んだだけでは "開始" が出てない。foreach で回して初めて中身が動いてます。

遅延評価っていうのは、こういうことです。いい感じに1件ずつ処理が進んでますね。

ここまでのポイント: 中身が動くのは呼んだ時じゃなく、回し始めた時。

List で返す版 → yield で返す版

さっきの偶数を返すコードを yield return に書き換えると、こんな感じ。

戻り値の型が List<int> から IEnumerable<int> に変わって、result の詰め込みが消えました。

呼び出し側は foreach (var n in GetEvens(1000000)) で同じように回せます。書き方は変わらない。

違うのは、回した分しかメモリに乗らないこと。最初の10件で break すれば、残りの50万件近くは作られすらしません。

ここまでのポイント: yield 版は必要な分だけ作る。使う側の書き方は変わらない。

遅延評価だから注意: DB 接続を開いたまま回すと

ここが、業務でいちばん踏みやすい落とし穴です。

遅延評価ということは、中身が動くのは呼び出し側が回している間。DB 接続やファイルを開いて yield return すると、その接続は「回し終わるまで開きっぱなし」になります。

たとえば、こんな感じのコード。

public static IEnumerable<string> ReadFromDb()
{
    using (var conn = OpenConnection())   // 接続を開く
    {
        // reader を回して1行ずつ返す
        foreach (var row in ReadRows(conn))
            yield return row;
    }   // ← 閉じるのは「呼び出し側が回し終わった時」
}

何が起きるか。呼び出し側が1件ごとに重い処理をしてゆっくり回すと、その間ずっと接続が握られたまま。接続プールを長時間占有して、他の処理を待たせる。そういう事故につながります。

誤解しがちなので補足します。foreach で回してる限りは大丈夫です。

途中で break しても例外で抜けても、C# が裏でイテレータの Dispose を呼んでくれるので、using の接続はちゃんと閉じる。

危ないのは、foreach を使わず自分で GetEnumerator() して MoveNext() を回し、Dispose を呼ばずに放置した時。ここだと接続が閉じ切らないことがあります。ん？ 自分で回すコード書いてない？って一回立ち止まる価値があるやつです。

ここまでのポイント: yield は「開きっぱなしのリソースを、回し終わるまで握り続ける」。

全部まとめて欲しい時は ToList() で確定させる

遅延評価が向かない場面もあります。「結果を何度も使い回す」「接続を早く閉じたい」「件数がそもそも少ない」。

こういう時は ToList() で確定させます。

// その場で全件読み切って List に確定させる
var rows = ReadFromDb().ToList();   // ここで全件評価 → 接続もすぐ閉じる
// 以降は rows を何度でも使い回せる