リモートパフォーマンスモニターを使用して、CompactFrameworkアプリケーションのメモリリークの原因を見つけようとしています。ブラシやその他のグラフィックオブジェクトに関連するいくつかのマイナーなものを削除することができましたが、主な問題の原因がまだ明確にわかりません。
この時点で、元のカウントに戻らないように見えるオブジェクトはSystem.Stringオブジェクトだけです。これらのオブジェクトが収集されないままでいるためには、それらを含むオブジェクトも残っている必要があると思っていたので、これは非常に奇妙だと思いますが、他のタイプのオブジェクトはそれに伴って増加していないようです。 System.Strings。
アプリケーションが元の状態（つまり、ログイン画面）に戻った後に残る新しいStringオブジェクトを見つけようとしています。問題は、元々、アプリケーションが約2200の文字列オブジェクトをロードし、プロセス「X」の後にさらに70程度増加し、収集されないことです。誰がそれらを保持しているのかを見つけて適切な修正を行うために、それらの70個の新しいオブジェクトを識別する方法がわかりません。
文字列が収集されなかった経験はありますか？プロセス「X」の間に作成された新しいオブジェクトを、アプリケーションが最初に必要としていたオブジェクトから分離して、どれがリークしているかを知る方法はありますか？何かアドバイスをいただければ幸いです。
ありがとう
**アップデート
わかりました...非常に奇妙なことが起こっています。漏れがあるのか疑問に思い始めています。
アプリケーションの元の開始点であるログイン画面でメモリスナップショットを作成するとします。この時点でメモリに1000個の文字列オブジェクトがあると想像してください。ここで、ログインしてメニューからオプションを選択すると、新しい画面が読み込まれたらスナップショットを撮ります。このフォームをロードすると、文字列数が50オブジェクト増えるとしましょう。ログアウトしてログイン画面で再度スナップショットを撮ると、それらのオブジェクトのうち25個だけが収集され、残りはそれ以降メモリに残ります。
奇妙なことに、このプロセスを繰り返し続けると、それ以上文字列オブジェクトが蓄積されなくなります。文字列数が50増える代わりに、この時点で25だけが追加され、ログイン画面に戻ると同じ25が収集されます。これが実際のリークである場合、その画面を開くたびに文字列数が永続的に25増加すると思いますが、これは初めての場合にのみ発生します。
これは、私が開くすべての新しい画面で発生します。最初は全体的な文字列数が永続的にわずかに増加しますが、その特定の画面をロードすると、ログイン画面に戻ると、実行中の文字列数の増加が収集されます。
これらすべてのことから、おそらくこれらの文字列はCLRの内部動作の一部であると私は信じています。ランタイムによって行われるある種のキャッシュでしょうか？おそらくそれはより速いロードのために私の文字列定数を保存していますか？そんな感じ？これがあまり混乱していなかったと思います。