Откуда переменная = null как «уничтожение объекта»?

Question

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

public void FooBar()
{
    object foo = null;
    object bar = null;

    try
    {
       foo = new object();
       bar = new object();

       // Code which throws exception.
    }
    finally
    {
       // Destroying objects
       foo = null;
       bar = null;
    }

}

Любому, кто знает, как работает управление памятью.NET, этот вид кода крайне не нужен;сборщику мусора не требуется, чтобы вы вручную назначали null, чтобы сообщить, что старый объект может быть собран, а также назначение null не инструктирует GC немедленно собрать объект.

Этот шаблон - просто шум, усложняющий понимание того, чего пытается достичь код.

Почему же я продолжаю искать этот шаблон?Есть ли школа, которая учит этой практике?Существует ли язык, на котором для правильного управления памятью требуется присвоение значений null локальным переменным?Есть ли какое-то дополнительное значение в явном присвоении null, которое я не воспринял?

Answer 1

Я видел это в некотором коде Java раньше. Он был использован для статической переменной, чтобы сигнализировать, что объект должен быть уничтожен.

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

Answer 2

Это происходит из кода C ++, особенно умных указателей . В этом случае это примерно эквивалентно .Dispose() в C #.

Это не очень хорошая практика, по большей части инстинкт разработчика. Нет никакого реального значения, присваивая null в C #, за исключением того, что может помочь ГХ разбить циклическую ссылку.

Answer 3

Я вижу, что это происходит из-за неправильного понимания того, как работает сборщик мусора, или из-за попытки заставить GC немедленно начать работу - возможно, потому, что объекты foo и bar довольно велики.

Answer 4

Разработчики VB должны были утилизировать все свои объекты, чтобы попытаться уменьшить вероятность утечки памяти.Я могу себе представить, что это произошло из-за того, что разработчики VB перешли на .NEt / c #