Какие лучшие практики для чистки ссылок обработчика событий?

Неверно сказать, что отмена регистрации обработчиков из событий сеанса каким-то образом позволит собирать объект сеанса сборщиком мусора. Вот диаграмма, которая иллюстрирует ссылочную цепочку событий.

--------------      ------------      ----------------
|            |      |          |      |              |
|Event Source|  ==> | Delegate |  ==> | Event Target |
|            |      |          |      |              |
--------------      ------------      ----------------

Итак, в вашем случае источником события является объект Session . Но я не вижу, чтобы вы упомянули, какой класс объявил обработчики, поэтому мы еще не знаем, кто является целью события. Давайте рассмотрим две возможности. Целью события может быть тот же объект Session , который представляет источник, или это может быть совершенно отдельный класс. В любом случае и при нормальных обстоятельствах сеанс будет собираться до тех пор, пока нет другой ссылки, даже если обработчики его событий остаются зарегистрированными. Это потому, что делегат не содержит ссылки на источник события. Он содержит только ссылку на цель события.

Рассмотрим следующий код.

public static void Main()
{
  var test1 = new Source();
  test1.Event += (sender, args) => { Console.WriteLine("Hello World"); };
  test1 = null;
  GC.Collect();
  GC.WaitForPendingFinalizers();

  var test2 = new Source();
  test2.Event += test2.Handler;
  test2 = null;
  GC.Collect();
  GC.WaitForPendingFinalizers();
}

public class Source()
{
  public event EventHandler Event;

  ~Source() { Console.WriteLine("disposed"); }

  public void Handler(object sender, EventArgs args) { }
}

Вы увидите, что «disposed» дважды выводится на консоль, подтверждая, что оба экземпляра были собраны, без отмены регистрации события. Причина, по которой объект, на который ссылается test2 , собирается, заключается в том, что он остается изолированным объектом в ссылочном графе (как только test2 имеет значение null, то есть), даже если он имеет обратную ссылку на сам хоть событие.

Сложность усложняется, когда вы хотите, чтобы у цели события было время жизни, которое короче, чем у источника события. В этом случае вы должны отменить регистрацию событий.Рассмотрим следующий код, демонстрирующий это.

public static void Main()
{
  var parent = new Parent();
  parent.CreateChild();
  parent.DestroyChild();
  GC.Collect();
  GC.WaitForPendingFinalizers();
}

public class Child
{
  public Child(Parent parent)
  {
    parent.Event += this.Handler;
  }

  private void Handler(object sender, EventArgs args) { }

  ~Child() { Console.WriteLine("disposed"); }
}

public class Parent
{
  public event EventHandler Event;

  private Child m_Child;

  public void CreateChild()
  {
    m_Child = new Child(this);
  }

  public void DestroyChild()
  {
    m_Child = null;
  }
}

Вы увидите, что «disposed» никогда не выводится на консоль, демонстрируя возможную утечку памяти. Это особенно трудная проблема. Внедрение IDisposable в Child не решит проблему, потому что нет гарантии, что вызывающие абоненты будут правильно играть и фактически вызовут Dispose .

Ответ

Если ваш источник событий реализует IDisposable , то вы на самом деле не купили себе ничего нового. Это связано с тем, что, если источник события больше не является корневым, то цель события также не будет иметь root-права.

Если ваша цель события реализует IDisposable , то она может очистить себя от источника события, но нет гарантии, что Dispose будет вызван.

Я не говорю, что отмена регистрации событий из Dispose неверна. Я хочу сказать, что вам действительно нужно изучить, как определяется иерархия классов, и подумать, как лучше всего избежать проблемы с утечкой памяти, если она вообще существует.