データが大きく、プロセスが 32 ビットの場合、.Net MemoryStream を使用するとメモリ不足の例外が発生します。
System.IO.Packaging API は、データ ボリュームが増加するにつれて、メモリからファイルにバックアップされたストレージにサイレントに切り替えられると信じています。一見すると、まったく同じことを行う MemoryStream のサブクラスを実装することが可能であるように見えます。もの。
誰もそのような実装を知っていますか? フレームワーク自体には何もないと確信しています。
これは を使用して発生することが予想されるMemoryStreamため、独自のロジックを実装するか、外部クラスを使用する必要があります。MemoryStreamこれはビッグデータの問題を説明する投稿であり、投稿はMemoryStream MemoryStreamの代替に代わるものを提供します
私のチームでも同様の障害に遭遇しました。一部のコメンターは、開発者はファイルの使用にもっと慣れる必要があると示唆しています。ファイルシステムを直接使用するオプションがある場合は、それを行いますが、常にオプションであるとは限りません。
必要に応じて、ファイルから読み取ったデータをアプリケーションに渡したい場合、データの読み取りが完了する前に破棄される可能性があるため、FileStream オブジェクトを渡すことはできません。私たちは当初、データを簡単に受け渡せるようにするために MemoryStreams に頼っていましたが、同じ問題に遭遇しました。
問題を軽減するために、いくつかの異なる回避策を使用しました。
使用したオプションは次のとおりです。
int.MaxValueエントリの数に制限されているため) byte[] オブジェクトと、それらをほとんどストリームのように扱うことができるメソッドを公開します。私たちは今でもこれを何としても避けようとしています。このプロジェクトをチェックすることをお勧めします。
http://www.codeproject.com/Articles/348590/A-replacement-for-MemoryStream
メモリストリームの問題は、その下にあるすべてが単一のバイト[]の派手なラッパーであり、64ビットプログラムでもすべてのオブジェクトが2GB未満でなければならないという.netの要件によって依然として制約されているという事実に起因すると思います。上記の実装は、byte[] をいくつかの異なる byte[] に分割します。