33

こことここの回答で示唆されているように、最近、弱い参照を使用ConditionalWeakTable<TKey,TValue>するクラスを検索しているときにこのクラスに出くわしました。IDictionary

クラスを紹介し、次のように述べている決定的なMSDNの記事があります。

クラス...は、System.Runtime.CompilerServices名前空間にあります。汎用ディクショナリタイプではないため、CompilerServicesにあります。コンパイラの作成者のみが使用することを目的としています。

そして後で再び：

...条件付きウィークテーブルは、汎用コレクションを意図したものではありません...ただし、独自の.NET言語を作成していて、プロパティをオブジェクトにアタッチする機能を公開する必要がある場合は、必ず条件付きを調べる必要があります。弱いテーブル。

これに沿って、クラスのMSDNエントリの説明は次のようになります。

コンパイラーがオブジェクトフィールドを管理対象オブジェクトに動的にアタッチできるようにします。

したがって、明らかにそれは元々非常に特定の目的のために作成されました-DLRを支援するためであり、System.Runtime.CompilerServices名前空間はこれを具体化します。しかし、CLR内でさえ、それよりもはるかに幅広い用途が見つかったようです。たとえば、ILSpyでConditionalWeakTableの参照を検索すると、MEFクラスや内部WPFクラスなどで使用されていることがわかります。CatalogExportProviderDataGridHelper

私の質問は、コンパイラの記述および言語ツールの外部でConditionalWeakTableを使用しても問題がないかどうか、および追加のオーバーヘッドが発生したり、将来の.NETバージョンで実装が大幅に変更されたりするリスクがあるかどうかです。（または、回避して、代わりにこのようなカスタム実装を使用する必要があります）。

また、 ConditionalWeakTableが（を介して）エフェメロンの非表示のCLR実装を使用して、キーと値の間のサイクルの問題を処理する方法、およびこれをカスタム方法で簡単に実行できない方法について、ここ、ここ、およびここでさらに読んでください。System.Runtime.Compiler.Services. DependentHandle

4

1 に答える 1

23

を使用しても問題はありませんConditionalWeakTable。エフェメロンが必要な場合、他に選択肢はほとんどありません。

将来の.NETバージョンが問題になることはないと思います。コンパイラだけがこのクラスを使用する場合でも、Microsoftは既存のバイナリとの互換性を損なうことなくこのクラスを変更できませんでした。

オーバーヘッドに関しては、通常の辞書と比較して確かにオーバーヘッドがあります。sが多数あると、通常の参照よりも高価なsの数DependentHandleと同様に、おそらくコストがかかります（GCは、それらをスキャンしてnullにする必要があるかどうかを確認するために、追加の作業を行う必要があります）。WeakReferenceしかし、エントリがたくさん（数百万）ない限り、それは問題ではありません。

于 2012-04-22T12:30:35.813 に答える