File.ReadLines() で開いた Stream を確実に閉じる方法

巨大なテキストファイルでも1行ずつなら処理可能!

.NET Core 3.x 上の C# でのプログラミングにおける話。

改行で区切られた行指向のテキストファイルを、1行ずつ読み取っては何か処理をする、といった場合、自分がよくお世話になるのは、System.IO 名前空間の File クラスに備わっている ReadLines() 静的メソッドだ。

このメソッドに目的のテキストファイルのパスを渡して呼び出してやれば、そのテキストファイルの1行1行を文字列に読み込んで列挙する IEnumerabe<string> が返る。

あとはその返された IEnumerabe<string> を使って、foreach で列挙を回したり、LINQ で加工したりというように、1行1行の処理を実装すればよい。

この File.ReadLines() メソッドは、対象のファイルすべてをメモリに読み込むのではない。  

1行ずつ読み取っては結果の文字列をその都度返すので、未使用となった文字列は適宜ガベージコレクターに回収されるに任せられる。  

その結果、このメソッドは省メモリで動作し、大量の行から成る巨大なテキストファイルも一定の消費メモリだけで安定して処理が行える。

列挙を途中で抜けたらどうなるの?

そんな便利な File.ReadLines() であるが、あるとき、ちょっと困ったことになった。

あんまり遭遇することはないシチュエーションと思われるのだが、File.ReadLines() で行読み取りを開始したあと、最終行まで列挙せずに、途中で列挙を中断する要件に遭遇したのだ。

中断する実装自体は別に問題ではない。  

そうではなく心配なのは、列挙を中断したことで、File.ReadLines() が開いたテキストファイル読み取りの Stream が、開きっぱなしになってしまわないだろうか、という点だった。

もちろん、いずれガベージコレクターに回収されることで、最終的には Stream は閉じられる。  

しかしそれでは、Stream が閉じられるタイミングに予測性がない。

今回自分が遭遇したシチュエーションでは、列挙中断後、即座に Stream が閉じられている必要があったのだ。

ふーむどうしたものかと思いつつ、ちょっと試しに下記のような実験コードを書いて試してみた。

var lines = File.ReadLines(path);

foreach (var line in lines)

{

  Console.WriteLine($"line: {line}");

  break;

}

File.Delete(path);

すなわち、File.ReadLines() でテキストファイル中の行の列挙を開始し最初の1行をコンソールに表示するも、それだけで列挙を中断している。

で、その直後に当該ファイルの削除を試行している。

上記のように、foreach による列挙ループを break で中断したことによって、File.ReadLines() が開いた Stream が開きっぱなしになっているとしたら、続くファイル削除で IOException 例外が発生するはずだ。

実行したところ...

で、実行したところ...

なんと例外も発生せずに、正常にファイルの削除まで実行されたのだ。

自分の予測と違った振る舞いになったため、もう少し調べてみることに。

次は foreach で列挙ではなく、生の列挙子を自分で MoveNext() しながら while ループで列挙する実装を試してみた。

var lines = File.ReadLines(path);

var enumerator = lines.GetEnumerator();

while (enumerator.MoveNext())

{

  var line = enumerator.Current;

  Console.WriteLine($"line: {line}");

  break;

}

File.Delete(path);

するとこちらの実験コードでは、期待どおり (?) に、ファイルの削除で IOException 例外が発生した。  

例外メッセージはもちろん。他のプロセスで対象ファイルが使用中である、というものだ。

なにが起きているのかよくわからなくなってきたので、先の foreach 方式の実験コードをビルドした結果である .dll ファイルを ILSpy で見てみた。

すると、foreach って、using で囲ったコードに展開されているのであった...!  

(知らなかった...)

var lines = File.ReadLines(path);

using (var enumerator = lines.GetEnumerator())

{

  if (enumerator.MoveNext())

  {

    var line = enumerator.Current;

    Console.WriteLine("line: " + line);

  }

}

File.Delete(path);

とはいえ、IDisposable ではなく IEnumerator<string> を using するとは何事だろうか。

さらに ILSpy でコードをたどってようやくわかった。

File.ReadLines() が返す列挙オブジェクト、及び、それが返す列挙子であるが、ちゃんと IDisposable インターフェースを実装していたのだ。

言い換えると、File.ReadLines() が返す列挙オブジェクト、及び、それが返す列挙子を IDisposable インターフェースでキャストすると、ちゃんと IDisposable インターフェースとしての参照が手に入るのであった。

var lines = File.ReadLines(path);

var enumerator = lines.GetEnumerator();

var disposable = enumerator as IDisposable; // <- 非nullになる

それで列挙子を using 節で囲うことで、ちゃんと Stream を閉じる動作につながるのであった。

まとめ

これまで自分はまったく理解していなかったが、列挙子に適宜 IDisposable インターフェースを実装しつつ IEnumerator<T> として公開するのは、定番のイディオムなのであろう。

なので、C# の foreach は、上記のとおり、using で列挙子を囲いつつ MoveNext() で列挙を進めるというコードに展開される仕様なのであろうと理解した。

たぶん、公式を含め、ちゃんとそこかしこのドキュメントに明記されていることなのだろうが、お恥ずかしい、今の今までこの foreach の仕組みをわかっていなかった。

[2019/11/08 追記]

公式ドキュメントについてお知らせ頂いた。

教えて頂いた公式ドキュメントへのリンクはこちら。

たしかに、Dispose する仕様について明記されている。

[― 追記ここまで ―]

さておき、ということで、File.ReadLines() が返す列挙オブジェクトは、foreach で回したり、LINQ で使うぶんには、列挙が途中で中断しても、スコープを抜ける限りはちゃんと Dispose される、ということがわかった。

とはいえ、生の列挙子を自分で while ループで回すときなどは、もし列挙を中断する場合は自分で責任をもって Dispose する必要はある。  

そんな実装が必要になるケースはかなり希だとも思うが...。

なお、MoveNext() が false を返すまですべて列挙し終えた場合は、自前で Dispose しなくても、列挙完了時点で Dispose されるので安心して大丈夫だ。

(File.ReadLines() が返す列挙オブジェクトがそのように実装されているため)。