Блог

Нужно ли мне установить для MyAction значение null, чтобы сборка мусора могла продолжаться с любым из этих классов?

Меня меньше беспокоит, когда оба класса должны иметь почти одинаковый срок службы. Мой вопрос более уместен, когда срок службы Class1 намного больше, чем Class2, или когда срок службы Class2 намного больше, чем Class1.

Код здесь сокращен. Предположим, что и Class1, и Class2 содержат другие члены и методы, которые могут повлиять на их срок службы.

 public class Class1 : IDisposable
{
    public Action<string> MyAction { get; set; }

    // Is this necessary?
    public void Dispose()
    {
        MyAction = null;
    }
}

public class Class2
{
    string _result = string.Empty;

    public void DoSomething()
    {
        Class1 myClass1 = new Class1();
        myClass1.MyAction = s => _result = s;
        myClass1.Dispose();
    }
}
 

Нужно ли мне установить для MyAction значение null, чтобы сборка мусора могла продолжаться с любым из этих классов?

Нет. Каждый раз, когда вы «утилизируете» управляемый ресурс, велика вероятность, что вы делаете это неправильно. Пусть сборщик мусора выполняет свою работу.

Меня меньше беспокоит, когда оба класса должны иметь почти одинаковый срок службы. Мой вопрос более уместен, когда срок службы Class1 намного больше, чем Class2, или когда срок службы Class2 намного больше, чем Class1.

Вопрос не имеет никакого смысла; у классов нет времени жизни. Хранилища имеют время жизни. О каких именно хранилищах вы беспокоитесь? Можете ли вы прояснить вопрос?

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

 class Expensive
{
    public byte[] huge = MakeHugeByteArray();
}

class Cheap
{
    public int tiny;
}

class C
{
    public static Func<Cheap> longLived;
    public static void M()
    { 
        Expensive expensiveLocal = new Expensive();
        Cheap cheapLocal = new Cheap();
        Func<Expensive> shortLived = ()=>expensiveLocal ;
        C.longLived = ()=>cheapLocal;
    }
}
 

Каково время жизни локальной переменной expensiveLocal ?Время жизни локальной переменной обычно короткое; обычно локальные переменные живут не дольше, чем активация метода. Однако нахождение в замыкании увеличивает время жизни локальной переменной произвольно долго, до времени жизни замыкания. В данном конкретном случае оба лямбда-выражения разделяют замыкание, а это означает, что время жизни локальной переменной expensiveLocal по крайней мере столько же, сколько время жизни локальной переменной cheapLocal , которая имеетбесконечно долгое время жизни, потому что ссылка на закрытие только что была сохранена в статическом поле, которое живет вечно. Этот большой массив байтов может никогда не быть восстановлен, даже если единственное, что, кажется, ссылается на него, было собрано давно; закрытие — это скрытая ссылка.

Многие языки имеют эту проблему; C #, VB, JScript и так далее имеют лексические замыкания, которые не разделены на группы переменных по времени жизни. Мы рассматриваем возможность изменения C # и VB, чтобы улучшить управление жизненным циклом для замыканий, но на данный момент это работа далекого будущего, поэтому никаких гарантий.