Cでの弱いイベント＃

翻訳者から

最近、私が働いているプロジェクトで、メモリリークの問題に遭遇しました。 .NETでのメモリ管理に関する記事から、リソースの正しいリリースに関する実用的な推奨事項まで、多くの記事を読んだ後、イベントを正しく使用する方法を説明する記事に出会いました。 彼女の翻訳を紹介したいと思います。
これはサンドボックスのトピックで、Habrでここにアクセスしました。

はじめに

C＃で通常のイベントを使用する場合、イベントにサブスクライブすると、イベントを含むオブジェクトからサブスクライブするオブジェクトへのリンクが作成されます。



ソースオブジェクトがサブスクライバオブジェクトよりも長く存続する場合、メモリリークが発生する可能性があります。サブスクライバへの他の参照がない場合、ソースオブジェクトは引き続きそれを参照します。 したがって、サブスクライブするオブジェクトによって占有されているメモリは、ガベージコレクターによって解放できません。

この問題を解決する多くのアプローチがあります。 この記事では、それらのいくつかを調べ、利点と欠点について説明します。 すべてのアプローチを2つの部分に分けました。1つでは、イベントのソースが通常のイベントを持つ既存のクラスであると想定します。 別の方法では、元のオブジェクト自体を変更して、さまざまなメソッドの動作を確認します。

イベントとは何ですか？

多くの開発者は、イベントはデリゲートのリストであると考えています。 これは真実ではありません。 ご存知のように、デリゲートはマルチキャストにすることができます-一度にいくつかの機能へのリンクが含まれます：

EventHandler eh = Method1; eh += Method2; 

では、イベントとは何ですか？ これらはプロパティに似ています。内部にはデリゲートフィールドが含まれており、アクセスは直接拒否されます。 デリゲートのパブリックフィールド（またはパブリックプロパティ）により、イベントハンドラーのリストが別のオブジェクトによってクリアされたり、イベントが外部から呼び出されることがありますが、ソースオブジェクトからのみ呼び出したい場合があります。

プロパティはget / setメソッドのペアです。 イベントはいくつかの追加/削除メソッドです。

 public event EventHandler MyEvent { add { ... } remove { ... } } 

ハンドラを追加および削除するメソッドのみがパブリックである必要があります。 この場合、残りのクラスはハンドラーのリストを取得できず、それをクリアすることも、イベントを発生させることもできません。

C＃でイベントを宣言するための短い構文は誤解を招く場合があります。

 public event EventHandler MyEvent; 

実際、このようなコンパイルエントリは次のように展開されます。

 private EventHandler _MyEvent; //    public event EventHandler MyEvent { add { lock(this) { _MyEvent += value; } } remove { lock(this) { _MyEvent -= value; } } } 

C＃では、イベントは、宣言されているオブジェクトを使用して、デフォルトで同期を使用して実装されます。 これは、逆アセンブラを使用して確認できます。追加メソッドと削除メソッドは、[MethodImpl（MethodImplOptions.Synchronized）]属性でマークされます。これは、オブジェクトの現在のインスタンスを使用した同期と同等です。

イベントのサブスクライブとサブスクライブ解除は、スレッドセーフな操作です。 ただし、スレッドセーフイベント呼び出しは開発者の裁量に任されており、非常に頻繁に誤って実行します。

 if (MyEvent != null) MyEvent(this, EventArgs.Empty); //     NullReferenceException   , //             

別の一般的なオプションは、ローカル変数にデリゲートを事前に保存することです。

 EventHandler eh = MyEvent; if (eh != null) eh(this, EventArgs.Empty); 

このコードはスレッドセーフですか？ どのように。 C＃言語仕様で説明されているメモリモデルによると、この例はスレッドセーフではありません。JITコンパイラは、コードを最適化することにより、ローカル変数を削除できます。 ただし、.NETランタイム（バージョン2.0以降）はより強力なメモリモデルを備えており、このコードではスレッドセーフです。

ECMA仕様によると、正しい解決策は、ロック（this）ブロックにローカル変数を割り当てるか、揮発性フィールドを使用してデリゲートへの参照を保存することです。

 EventHandler eh; lock (this) { eh = MyEvent; } if (eh != null) eh(this, EventArgs.Empty); 

パート1：サブスクライバー側の弱いイベント

この部分では、通常のイベント（ハンドラーへの参照を含む）があることを暗示し、それからのサブスクリプション解除はサブスクライバー側で行う必要があります。

解決策0：登録解除するだけ

 void RegisterEvent() { eventSource.Event += OnEvent; } void DeregisterEvent() { eventSource.Event -= OnEvent; } void OnEvent(object sender, EventArgs e) { ... } 

シンプルで効果的で、可能な限り使用する必要があります。 ただし、オブジェクトが使用されなくなった後、DeregisterEventメソッドの呼び出しを常に提供できるとは限りません。 Disposeメソッドの使用を試すことができますが、一般的にアンマネージリソースに使用されます。 この場合のファイナライザは機能しません。元のオブジェクトがサブスクライバを参照しているため、ガベージコレクタはそれを呼び出しません。

メリット
オブジェクトの使用にDisposeの呼び出しが含まれる場合に使いやすい。

短所
明示的なメモリ管理は注意が必要です。 Disposeメソッドを呼び出すのを忘れることもあります。

解決策1：呼び出された後のイベントのサブスクライブ解除

 void RegisterEvent() { eventSource.Event += OnEvent; } void OnEvent(object sender, EventArgs e) { if (!InUse) { eventSource.Event -= OnEvent; return; } ... } 

これで、サブスクライブしているオブジェクトが使用されなくなったことを誰かが教えてくれても気にする必要はありません。 イベントが呼び出された後、私たち自身がこれを確認します。 ただし、ソリューション0を使用できない場合、原則として、オブジェクト自体から使用されているかどうかを判断することはできません。 そして、あなたがこの記事を読んでいるという事実を考えると、おそらくこれらのケースの1つに出くわしたでしょう。

このソリューションはすでにソリューション0に負けていることに注意してください。イベントがトリガーされない場合、サブスクライバーが占有しているメモリリークが発生します。 静的SettingsChangedイベントにサブスクライブする多くのオブジェクトを想像してください。 これらのオブジェクトはすべて、イベントが発生するまでガベージコレクターによってクリーンアップされません-これは決して発生しない可能性があります。

メリット
いや

短所
イベントがトリガーされない場合のメモリリーク。 オブジェクトが使用中かどうかを判断することも困難です。

解決策2：弱参照でラップする

このソリューションは、イベントハンドラーのコードをラッパークラスに配置することを除いて、以前のソリューションとほぼ同じです。ラッパークラスは、 弱いリンクを介してアクセスできるサブスクライブオブジェクトに呼び出しをリダイレクトします。 弱いリンクを使用すると、サブスクライバオブジェクトがまだ存在するかどうかを簡単に確認できます。

 EventWrapper ew; void RegisterEvent() { ew = new EventWrapper(eventSource, this); } void OnEvent(object sender, EventArgs e) { ... } sealed class EventWrapper { SourceObject eventSource; WeakReference wr; public EventWrapper(SourceObject eventSource, ListenerObject obj) { this.eventSource = eventSource; this.wr = new WeakReference(obj); eventSource.Event += OnEvent; } void OnEvent(object sender, EventArgs e) { ListenerObject obj = (ListenerObject)wr.Target; if (obj != null) obj.OnEvent(sender, e); else Deregister(); } public void Deregister() { eventSource.Event -= OnEvent; } } 

メリット
ガベージコレクターがサブスクライバーメモリを解放できるようにします。

短所
イベントが失敗しない場合、ラッパーが占有するメモリリーク。 各イベントのラッパークラスを記述することは、繰り返しコードの束です。

解決策3：ファイナライザーのイベントからサブスクライブ解除する

前の例では、EventWrapperへのリンクを保存し、パブリックのDeregisterメソッドがありました。 ファイナライザ（デストラクタ）をサブスクライバに追加し、それを使用してイベントのサブスクリプションを解除できます。

 ~ListenerObject() { ew.Deregister(); } 

このメソッドはメモリリークから私たちを救いますが、あなたはそれにお金を払わなければなりません：ガベージコレクタはファイナライザでオブジェクトを削除するのにより多くの時間を費やします。 サブスクライバオブジェクトが参照されなくなると（弱いリンクを除く）、最初のガベージコレクションを生き残り、より高い世代に転送されます。 その後、ガベージコレクタはファイナライザを呼び出します。その後、次のガベージコレクションでオブジェクトを削除できます（新しい世代で既に）。

ファイナライザは別のスレッドで呼び出されることにも注意してください。 これにより、イベントサブスクリプション/サブスクリプション解除がスレッドセーフでない方法で実装されている場合、エラーが発生する可能性があります。 C＃のイベントのデフォルト実装はスレッドセーフではないことに注意してください！

メリット
ガベージコレクターがサブスクライバーメモリを解放できるようにします。 ラッパーが占有するメモリリークはありません。

短所
ファイナライザを使用すると、未使用のオブジェクトが削除される前にメモリに残る時間が長くなります。 イベントのスレッドセーフな実装が必要です。 重複コードがたくさん。

解決策4：ラッパーを再利用する

以下のコードには、再利用可能なラッパークラスが含まれています。 ラムダ式を使用して、別のコードを渡します。イベントをサブスクライブし、イベントからサブスクライブを解除し、イベントをプライベートメソッドに転送します。

 eventWrapper = WeakEventHandler.Register( eventSource, (s, eh) => s.Event += eh, //   (s, eh) => s.Event -= eh, //   this, //  (me, sender, args) => me.OnEvent(sender, args) //   ); 

返されるeventWrapperインスタンスには、パブリックメソッドが1つだけあります-登録解除。 ラムダ式を記述するときは注意が必要です。ラムダ式はデリゲートにコンパイルされるため、オブジェクトへの参照を含めることもできます。 それが、加入者が私として戻ってくる理由です。 （me、sender、args）=> this.OnEvent（sender、args）と書いた場合、ラムダ式がthis変数にアタッチされ、クロージャーが作成されます。 また、WeakEventHandlerにはイベントを発生させるデリゲートへのリンクが含まれているため、ラッパーからサブスクライバーへの「強力な」（通常の）リンクになります。 幸いなことに、デリゲートが変数をキャプチャしたかどうかを確認する機会があります。そのようなラムダ式の場合、コンパイラはインスタンスメソッドを作成します。 それ以外の場合、メソッドは静的になります。 WeakEventHandlerは、Delegate.Method.IsStaticフラグを使用してこれをチェックし、ラムダ式のスペルが正しくない場合は例外をスローします。

このアプローチにより、ラッパーを再利用できますが、デリゲートのタイプごとに独自のラッパークラスが必要です。 System.EventHandlerとSystem.EventHandlerを積極的に使用できるため、さまざまな種類のデリゲートがある場合は、これらすべてを自動化する必要があります。 これには、コード生成またはSystem.Reflection.Emitスペースタイプを使用できます。

メリット
ガベージコレクターがサブスクライバーメモリを解放できるようにします。 追加コードのサイズはそれほど大きくありません。

短所
イベントが失敗しない場合、ラッパーが占有するメモリリーク。

解決策5：WeakEventManager

WPFには、WeakEventManagerクラスを介したサブスクライバ側の弱いイベントの組み込みサポートがあります。 ラッパーを使用する以前のソリューションと同様に機能しますが、WeakEventManagerの単一インスタンスが複数のイベントソースと複数のサブスクライバー間のラッパーとして機能する点が異なります。 オブジェクトのインスタンスが1つしかないため、WeakEventManagerは、イベントがトリガーされない場合でもメモリリークを回避します。別のイベントにサブスクライブすると、古いサブスクリプションのリストがクリアされる場合があります。 これらのクリーンアップは、WPFメッセージループが実行されているスレッドでWPFマネージャーによって実行されます。

WeakEventManagerには追加の制限もあります。senderパラメーターの正しい設定が必要です。 button.Clickイベントに使用すると、sender == buttonのイベントのみがサブスクライバーに渡されます。 一部のイベント実装では、ハンドラーを他のイベントに添付できます。

 public event EventHandler Event { add { anotherObject.Event += value; } remove { anotherObject.Event -= value; } } 

このようなイベントは、WeakEventManagerでは使用できません。

イベントごとに1つのWeakEventManager、スレッドごとに1つのインスタンス。 このようなイベントをコードブランクで決定するための推奨テンプレートは、MSDNの記事「WeakEvent Templates」にあります。

幸いなことに、ジェネリックを使用してこれを簡素化できます。

 public sealed class ButtonClickEventManager : WeakEventManagerBase<ButtonClickEventManager, Button> { protected override void StartListening(Button source) { source.Click += DeliverEvent; } protected override void StopListening(Button source) { source.Click -= DeliverEvent; } } 

DeliverEventは引数として（オブジェクト、EventArgs）を受け入れ、Clickイベントは引数（オブジェクト、RoutedEventArgs）を提供することに注意してください。 C＃では、デリゲートのタイプ間の変換はサポートされていませんが、メソッドのグループからデリゲートを作成する際の避妊はサポートされています 。

メリット
ガベージコレクターがサブスクライバーメモリを解放できるようにします。 ラッパーが占有していたメモリも解放できます。

短所
この方法は、実装がWPFに関連付けられているため、グラフィカルインターフェイスがないアプリケーションにはあまり適していません。

パート2：ソース側の弱いイベント

このパートでは、イベントを含む元のオブジェクトを変更して、弱いイベントを実装する方法を見ていきます。 以下に提案するすべてのソリューションは、サブスクライバー側の弱いイベントの実装よりも利点があります。スレッドセーフなサブスクリプション/サブスクリプション解除を簡単に行うことができます。

解決策0：インターフェース

WeakEventManagerは、このパートで言及する価値があります。 ラッパーとして、通常のイベント（サブスクライバー側）を結合しますが、クライアント（ソースオブジェクト側）に弱いイベントを提供することもできます。

IWeakEventListenerインターフェイスがあります。 このインターフェイスを実装するサブスクライバの場合、ソースオブジェクトはウィークリンクを使用して参照され、実装されたReceiveWeakEventメソッドが呼び出されます。

メリット
シンプルで効果的。

短所
オブジェクトが多くのイベントにサブスクライブされる場合、ReceiveWeakEventの実装では、イベントのタイプとソースに関する一連のチェックを記述する必要があります。

解決策1：弱い委任参照

これはWPFで使用される別のアプローチです。CommandManager.InvalidateRequeryは通常のイベントのように見えますが、そうではありません。 デリゲートへの弱い参照が含まれているため、静的イベントにサブスクライブしてもメモリリークは発生しません。



これは簡単なソリューションですが、イベントサブスクライバーは簡単にそれを忘れたり、誤解したりする可能性があります。

 CommandManager.InvalidateRequery += OnInvalidateRequery; //  CommandManager.InvalidateRequery += new EventHandler(OnInvalidateRequery); 

問題は、CommandManagerには弱いデリゲートリンクのみが含まれ、サブスクライバにはデリゲートリンクがまったく含まれていないことです。 したがって、次のガベージコレクションでデリゲートが削除され、サブスクライブしているオブジェクトがまだ使用中であっても、OnInvalidateRequeryは機能しなくなります。 デリゲートがメモリ内にあるためには、サブスクライバーが応答する必要があります。

 class Listener { EventHandler strongReferenceToDelegate; public void RegisterForEvent() { strongReferenceToDelegate = new EventHandler(OnInvalidateRequery); CommandManager.InvalidateRequery += strongReferenceToDelegate; } void OnInvalidateRequery(...) {...} } 

メリット
デリゲートによって占有されていたメモリは解放されます。

短所
デリゲートへの「強力な」リンクの付加を忘れると、最初のガベージコレクションまでイベントが発生します。 これにより、エラーを見つけるのが難しくなります。

解決策2：オブジェクト+フォワーダー

WeakEventManagerはソリューション0に適合しましたが、WeakEventHandlerラッパーはこのソリューションに適合します。<object、ForwarderDelegate>ペアを登録します。

 eventSource.AddHandler(this, (me, sender, args) => ((ListenerObject)me).OnEvent(sender, args)); 

メリット
シンプルで効果的。

短所
イベントを記録する珍しい方法。 リダイレクトラムダ式には型変換が必要です。

解決策3：SmartWeakEvent

以下に示すSmartWeakEventは、通常の.NETイベントのように見えるが、弱いサブスクライバーリンクを格納するイベントを提供します。 T.O. デリゲートへの「強力な」リンクを維持する必要はありません。

 void RegisterEvent() { eventSource.Event += OnEvent; } void OnEvent(object sender, EventArgs e) { ... } 

イベントを定義します。

 SmartWeakEvent<EventHandler> _event = new SmartWeakEvent<EventHandler>(); public event EventHandler Event { add { _event.Add(value); } remove { _event.Remove(value); } } public void RaiseEvent() { _event.Raise(this, EventArgs.Empty); } 

どのように機能しますか？ Delegate.TargetおよびDelegate.Methodのプロパティを使用して、各デリゲートはターゲットオブジェクト（弱参照を使用して格納）とMethodInfoに分割されます。 イベントが発生すると、リフレクションを使用してメソッドが呼び出されます。



このメソッドの脆弱性は、誰かが匿名メソッドをイベントハンドラとしてアタッチできることです。

 int localVariable = 42; eventSource.Event += delegate { Console.WriteLine(localVariable); }; 

この場合、ターゲットは、コレクターによってすぐに削除できるクロージャーです。 それへのリンクはありません。 ただし、SmartWeakEventはこのような場合を検出して例外をスローできるため、イベントハンドラーは予想よりも早くアンタイドされるため、デバッグに問題はないはずです。

 if (d.Method.DeclaringType.GetCustomAttributes(typeof(CompilerGeneratedAttribute), false).Length != 0) throw new ArgumentException(...); 

メリット
それは本当に弱い出来事のように見えます。 冗長コードはほとんどありません。

短所
リフレクションによるメソッドの実行はかなり遅いです。 プライベートメソッドを実装するため、部分的な権限では機能しません。

解決策4：FastSmartWeakEvent

機能と使用方法はSmartWeakEventを使用したソリューションと似ていますが、パフォーマンスははるかに高くなっています。

次に、2つのデリゲートを持つイベントのテスト結果を示します（1つはインスタンスメソッドを参照し、もう1つは静的メソッドを参照します）。

通常（「強い」）イベント... 16 948 785 1秒あたりの呼び出し
スマートウィークイベント... 91,960コール/秒
高速スマートウィークイベント... 4,901,840コール/秒

どのように機能しますか？ メソッドの実行にリフレクションを使用しなくなりました。 代わりに、System.Reflection.Emit.DynamicMethodを使用してプログラムの実行中にメソッド（以前のソリューションのメソッドと同様）をコンパイルします。

メリット
本当に弱いイベントのように見えます。 冗長コードはほとんどありません。

短所
プライベートメソッドを実装するため、部分的な権限では機能しません。

申し出

• WeakEventManagerは、WPFアプリケーションのGUIスレッドで機能するすべてのものに使用します（たとえば、モデルオブジェクトイベントにサブスクライブするユーザーコントロール用）
• 弱いイベントを提供する場合は、FastSmartWeakEventを使用します
• イベントをサブスクライブする場合は、WeakEventHandlerを使用します。