私の C# プログラムでは、メモリを消費するさまざまな操作を行っています。現在利用可能なメモリの量とさまざまな一定でない状況に応じて、プログラムはさまざまな段階で OutOfMemoryException で失敗します。
近い将来、プログラムが OOM で失敗することが多かれ少なかれ明らかな時点で、処理を停止したいと考えています。
ただし、これには固定のしきい値はありません。他のユーザーは、より多くの (またはより少ない) メモリを持っている場合や、別の OS とそのメモリ仕様などを持っている場合があります。
ソフトウェアがたとえば 500MB を超えて消費していることを確認したくありません。これは、制限が高すぎるか低すぎる可能性があるためです。
.NET で今後の OOM を予測する信頼できる方法はありますか?
MemoryFailPointはあなたが望むことをするはずです。
http://msdn.microsoft.com/en-us/library/system.runtime.memoryfailpoint.aspx
並べ替えの答えは、おそらく最善の解決策ではないということです。メモリが不足する時期を予測して何かをしようとするのではなく、アプリケーションのメモリ消費量を減らすか、次のようになるまで待つ必要があります。OutOfMemoryException例外がスローされ、クリーンアップされます。
.Netランタイムが要求されたばかりのメモリの割り当てに失敗すると、メモリ不足の例外がスローされます。これは、マシンの物理メモリが不足し、スワップファイルが無効になっている（またはマシンのディスク容量が不足している）ことが原因である可能性があります。 ）、またはプロセスの仮想メモリスペースが断片化されすぎて、目的のメモリブロックを割り当てることができないことが原因である可能性があります（これは、大きなオブジェクトを操作しているときに発生する可能性があります）。これがいつになるかを予測することはかなり困難です。
MemoryFailPointクラスを使用して、大量のメモリを消費する操作を開始する前に、特定の量のメモリが使用可能になるかどうかを確認できますが、このクラスは、メモリがその期間中使用可能であることを保証しません。操作など、アプリケーションはOOM例外で失敗する可能性があります。このクラスは、一部のシナリオでOOM例外を減らして（そしてアプリケーションの状態を壊さないように）試みるのに役立ちますが、おそらく問題の「特効薬」の解決策にはなりません。
私がこれまでに観察したOOM例外の多くは、メモリリークまたはサードパーティコンポーネントを使用した不適切に記述されたアプリケーションが原因でした。操作に最適化されたデータ構造の使用を検討してください。
ランダムにスローされるため、OOMの検出は非常に困難です。たぶん、MemoryFailPointとパフォーマンスカウンター（使用可能なメモリ）を使用して、十分な使用可能なメモリがあることを確認できます。