1

短時間で多くのビットマップを処理する必要があり、スレッドを使用して実行します。今、私はそれらすべてを処分したことを覚えています。メモリリークはありません。通常、私のアプリはいくつかのスレッドを開き (私はそれらの数を制御します - 今は同時に 4 つしか実行しません)、それぞれが 1 つの大きなビットマップを処理し、追加のグラフィック処理を行います。

プロセスが完了するまで、すべてが正常に機能します-最大100ビットマップが連続して。私のアプリは opendialog を使用しているため、最初の 100 個のビットマップを開くと、アプリがそれらを自動的に処理します。終了後、次の 100 個のビットマップのバッチを開きます (そのため、これらのバッチの間にかなりの一時停止があります)。これはうまくいきます。そして、アプリは常に開いています。メモリリークは見られません。最後のバッチの処理後も安定しており、さらに処理できます。

1 つのバッチでより多くのビットマップ (300 以上) を選択すると問題が発生するため、アプリは一時停止することなくすべてのビットマップを処理します。終わり近くで、GDI+ のメモリ不足エラーが発生し、アプリが 1.7 GB のメモリを消費してハングします。

私の推測では、システムは非常に短い時間でメモリを解放できません (そして、私のアプリはより多くを予約しています)。出来ますか?これに対処する方法は?プロセスにばかげた遅延を追加したくありません。私はそれを管理したいと思います。

更新: 理由は簡単です。アプリが誤って 32 ビットとしてコンパイルされたため、使用可能なメモリが ~2GB しかありませんでした。アプリがより多くのビットマップ用にまだ多くを予約している間、GC がメモリを解放するのに時間がかかりますが、アプリは制限に達してハングします。

アプリを 64 ビットにコンパイルしましたが、問題なく動作します。さらに、私はメモリ使用量を制御するので、今のように無人で動作していません。改善するためのすべてのヒントと興味深い点に感謝します!

4

2 に答える 2

1

あなたが言った「短い時間」の長さにもよりますが、間違いなくMemory Mapped Filesを見ることができます。それらを使用すると、RAM メモリの負荷が大幅に軽減され、速度が大幅に低下することはありません。ただし、最初に述べたように、それは処理に必要な速度によって異なります。

したがって、このオプションも検討し、測定して、ニーズに合っているかどうかを確認することをお勧めします.

于 2013-03-19T09:49:54.637 に答える
1

アプリケーションは 32 ビット プロセスとしてコンパイルされていますか? その場合、マシンの RAM の量に関係なく、2Gb でメモリが不足します。64 ビットとしてコンパイルすると、すべてのシステム メモリをフルに活用でき、RAM が不足し始めるとスワップ スペースが使用されます (これはもちろんアプリケーションの速度を低下させますが、メモリ例外)。

于 2013-03-19T10:05:45.910 に答える