StackOverflowでいくつかの質問と回答を読むこと+=で、C＃（または他の.net言語）を使用してイベントハンドラーを追加すると、一般的なメモリリークが発生する可能性があることに気づきました...
私は過去にこのようなイベントハンドラーを何度も使用しましたが、それらがアプリケーションでメモリリークを引き起こしたり、引き起こしたりしていることに気付いていませんでした。
これはどのように機能しますか（つまり、実際にメモリリークが発生するのはなぜですか）？
この問題を解決するにはどうすればよいですか？-=同じイベントハンドラを使用して十分ですか？
このような状況に対処するための一般的な設計パターンまたはベストプラクティスはありますか？
例：UIでいくつかのイベントを発生させるために多くの異なるイベントハンドラーを使用して、多くの異なるスレッドを持つアプリケーションをどのように処理するべきですか？
すでに構築された大きなアプリケーションでこれを効率的に監視するための良い簡単な方法はありますか？
回答:
原因は簡単に説明できます。イベントハンドラーがサブスクライブされている間、イベントのパブリッシャーはイベントハンドラーデリゲートを介してサブスクライバーへの参照を保持します（デリゲートがインスタンスメソッドであると想定）。
パブリッシャーがサブスクライバーよりも長く存続する場合、サブスクライバーへの参照が他にない場合でも、サブスクライバーは存続します。
イコールハンドラーを使用してイベントをサブスクライブ解除すると、はい、ハンドラーが削除され、リークの可能性があります。ただし、私の経験では、これが実際に問題になることはめったにありません。通常、パブリッシャーとサブスクライバーのライフタイムはほぼ同じであるためです。
それは考えられる原因です...しかし、私の経験では、それはかなり過剰に宣伝されています。もちろん、走行距離は異なる場合があります。注意が必要です。
はい、-=それで十分です。ただし、割り当てられたすべてのイベントを追跡することは非常に困難です。（詳細については、Jonの投稿を参照してください）。デザインパターンについては、弱いイベントパターンをご覧ください。
IDisposableイベントのサブスクライブを解除します。
この混乱については、https：//www.spicelogic.com/Blog/net-event-handler-memory-leak-16のブログで説明しています。ここにまとめて、わかりやすいようにします。
参照は、「必要」を意味します：
まず、オブジェクトAがオブジェクトBへの参照を保持している場合、オブジェクトAが機能するにはオブジェクトBが必要であることを理解する必要があります。したがって、ガベージコレクターは、オブジェクトAがメモリ内に存在している限り、オブジェクトBを収集しません。
この部分は開発者にとって明らかなはずです。
+ =右側のオブジェクトの参照を左側のオブジェクトに注入することを意味します。
しかし、混乱はC＃+ =演算子に起因します。この演算子は、この演算子の右側が実際に左側のオブジェクトへの参照を注入していることを開発者に明確に伝えていません。
そうすることで、オブジェクトAはオブジェクトBを必要とすると考えますが、あなたの視点からは、オブジェクトAはオブジェクトBが生きているかどうかを気にする必要はありません。オブジェクトAはオブジェクトBが必要であると考えるので、オブジェクトAが生きている限り、オブジェクトAはオブジェクトBをガベージコレクタから保護します。しかし、イベントサブスクライバーオブジェクトに保護を与えたくない場合は、メモリリークが発生したと言えます。
このようなリークは、イベントハンドラを切り離すことで回避できます。
どのように決定するのですか？
ただし、コードベース全体には多数のイベントとイベントハンドラーがあります。それは、イベントハンドラーをどこでも切り離し続ける必要があることを意味しますか？答えは「いいえ」です。そうしなければならなかった場合、コードベースは冗長になって非常に醜くなります。
単純なフローチャートに従って、分離イベントハンドラーが必要かどうかを判断できます。
ほとんどの場合、イベントサブスクライバーオブジェクトはイベントパブリッシャーオブジェクトと同じくらい重要であり、両方が同時に存在することになっています。
心配する必要がないシナリオの例
たとえば、ウィンドウのボタンクリックイベント。
ここで、イベントパブリッシャーはButtonで、イベントサブスクライバーはMainWindowです。そのフローチャートを適用して質問すると、メインウィンドウ（イベントサブスクライバー）はボタン（イベントパブリッシャー）の前に無効になるはずですか？明らかに違いますよね？それでも意味がありません。では、なぜクリックイベントハンドラの分離を心配するのでしょうか。
イベントハンドラの切り離しが必須の場合の例。
サブスクライバーオブジェクトがパブリッシャーオブジェクトの前に無効になるはずの1つの例を示します。たとえば、MainWindowが「SomethingHappened」という名前のイベントを発行し、ボタンクリックでメインウィンドウから子ウィンドウを表示するとします。子ウィンドウは、メインウィンドウのそのイベントをサブスクライブします。
また、子ウィンドウはメインウィンドウのイベントをサブスクライブします。
このコードから、メインウィンドウにボタンがあることを明確に理解できます。そのボタンをクリックすると、子ウィンドウが表示されます。子ウィンドウはメインウィンドウからイベントをリッスンします。何かをした後、ユーザーは子ウィンドウを閉じます。
ここで、私が提供したフローチャートに従って、「子ウィンドウ（イベントサブスクライバー）はイベントパブリッシャー（メインウィンドウ）の前にデッドになるはずですか？答えはYESであるはずです。そうです。それで、イベントハンドラーを切り離します。 。私は通常、ウィンドウのUnloadedイベントからそれを行います。
経験則：ビュー（WPF、WinForm、UWP、Xamarinフォームなど）がViewModelのイベントをサブスクライブする場合は、必ずイベントハンドラーをデタッチすることを忘れないでください。ViewModelは通常、ビューよりも長持ちするためです。そのため、ViewModelが破棄されない場合、そのViewModelのサブスクライブイベントを含むビューはメモリ内にとどまるので、好ましくありません。
メモリプロファイラーを使用した概念の証明。
メモリプロファイラーでコンセプトを検証できない場合は、それほど楽しくありません。この実験では、JetBrain dotMemoryプロファイラーを使用しました。
まず、次のように表示されるMainWindowを実行しました。
次に、メモリのスナップショットを撮りました。次に、ボタンを3回クリックしました。3つの子ウィンドウが表示されました。これらの子ウィンドウをすべて閉じ、dotMemoryプロファイラーのForce GCボタンをクリックして、ガベージコレクターが確実に呼び出されるようにしました。次に、別のメモリスナップショットを撮って比較しました。見よ！私たちの恐れは本当でした。チャイルドウィンドウは、閉じてもガベージコレクターによって収集されませんでした。それだけでなく、ChildWindowオブジェクトのリークされたオブジェクト数も「3」と表示されます（ボタンを3回クリックして3つの子ウィンドウを表示しました）。
では、次のようにイベントハンドラーを切り離しました。
次に、同じ手順を実行し、メモリプロファイラーを確認しました。今回はすごい！これ以上のメモリリークはありません。
イベントは実際にはイベントハンドラーのリンクされたリストです
イベントで+ = new EventHandlerを実行する場合、この特定の関数が以前にリスナーとして追加されているかどうかは問題ではなく、+ =ごとに1回追加されます。
イベントが発生すると、リンクリストを項目ごとに通過し、このリストに追加されたすべてのメソッド（イベントハンドラー）を呼び出します。これが、ページが実行されていない限り、イベントハンドラーが呼び出され続ける理由です。彼らは生きている（根付く）、そしてそれらが接続されている限り彼らは生きているでしょう。したがって、イベントハンドラーが-= new EventHandlerでフック解除されるまで、それらは呼び出されます。
そしてMSDNはこちら