4

他のクラス B、C などにビットマップを提供するクラス A があります。

クラス A はビットマップをリング キューに保持するため、しばらくするとビットマップへの参照が失われます。

まだキューにある間に、同じ Bitmap を複数のクラスでチェックアウトできるため、たとえば、B と C の両方がこの同じ Bitmap への参照を保持できます。しかし、そのうちの 1 つだけが Bitmap をチェックアウトしたか、または 1 つもチェックアウトしていないこともあり得ます。

A、B、または C のいずれかでビットマップが不要になったら、ビットマップを破棄したいと思います。

B と C が使用を終えたときに何らかの形で信号を送る責任を負うようにする必要があると思いますが、全体的なロジックについてはわかりません。

この例では、3 回呼び出される DisposeIfNowOrphan() のような呼び出しである必要があります。

1 - ビットマップがクラス A のキューから追い出されたとき

2 - B が使い終わったとき

3 - C が終了したとき

それが最善の戦略である場合、孤立状態をどのように評価できますか?

どんなアドバイスでも大歓迎です。

4

4 に答える 4

3

ビットマップを直接提供する代わりに、クラス A がラッパー クラスを提供するようにします。ラッパー クラスは IDisposable 自体を実装する必要があり、カウンターの維持に使用できます。各コンシューマーは、同じビットマップを参照する独自のラッパーを取得できます。クラス A は、すべてのビットマップとすべてのラッパーのトラップを保持します。クラス A で WeakReference を使用してラッパーを追跡します。これにより、コンシューマーが dispose を呼び出さない場合、GC が行われ、プロバイダーはそれが参照されなくなったことを知ることができます。

于 2010-03-26T05:38:30.733 に答える
2

BitmapImageを実装する から継承するIDisposableため、インスタンスを使い終わったら、それを呼び出す必要がありますDispose()。これにより、 の管理されていないリソースがクリーンアップされImageます。

ただし、Imageファイナライザーも実装しているため、何らかの理由で を呼び出すことができないDispose()場合、インスタンスのファイナライズ中にリソースが再利用されます。これは、インスタンスが参照されなくなった後のある時点で発生します。

于 2010-03-26T05:45:11.733 に答える
1

メモリ使用量がそれほど大きな問題ではなく、正確さと明確さがより重要な場合...

各受信者に独自のビットマップのコピーを渡し、それを使用するコードを using() ステートメントで囲みます。

管理コードは非常に簡単になり、消費コードも非常に簡単になりました。また、コンシューマーに例外やその他のコード パスがあり、参照カウンターがデクリメントされたこと (またはそのようなもの) を確認することが困難 (または不可能) であっても、すべてが機能することを確認 (証明?) するのは非常に簡単です。

共有ビットマップ用の独自の GC ソリューションを開発するために節約した時間を使用して、お金を払ってサーバー用の RAM をもう 1 つ購入します。

于 2010-03-26T05:46:01.773 に答える
0

一方、ピーク時のメモリ消費が重要な問題である場合...しかし、コンシューマ コードに関係なく、ビットマップの有効期間が適切に管理されていることを確認できる「安全な」アプローチが必要な場合は、問題を逆転させることができます。プロデューサーは、独自のスレッド (または複数のスレッド) でのイメージに対するすべての操作に対して単独で責任を負います。したがって、他のクラスに画像を渡して作業する代わりに、他のクラスにアクションを渡して画像を実行するように依頼します。保留中のアクションのキューを維持し、キューを先読みして、今後行う作業がないことに基づいて、バッファからどの画像を投げるかを決定できます。

これらのイメージは大きなオブジェクト ヒープ上にある可能性が高いため、それらの有効期間を適切に管理して、大きなオブジェクト ヒープの断片化を最小限に抑えることが重要です。

于 2010-03-26T16:16:18.137 に答える