Когда операторы using в C # наиболее полезны?

Оператор using наиболее полезен при работе с неуправляемыми объектами, такими как соединения с базой данных.

Таким образом, соединение закрывается и удаляется независимо от того, что происходит в блоке кода.

Для получения дополнительной информации см. Эту статью о CodeProject: http://www.codeproject.com/KB/cs/tinguusingstatement.aspx

Без using (или ручного вызова Dispose()) объект в конечном итоге будет удален, но не в детерминированное время. То есть это может произойти сразу, через два дня или (в некоторых случаях) никогда.

Для таких вещей, как, скажем, сетевые соединения, вы хотите, чтобы соединение закрывалось, когда вы закончите с ним, а не «когда-либо», иначе оно будет бездействовать, загружая сокет.

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

Этот:

public void DoSomething()
{
    using (Font font1 = new Font("Arial", 10.0f))
    {
        // Draw some text here
    }
}

сопоставляется непосредственно с этим:

public void DoSomething()
{
    {
        Font font1;
        try
        {
            font1 = new Font("Arial", 10.0f);
            // Draw some text here
        }
        finally
        {
            IDisposable disp = font1 as IDisposable;
            if (disp != null) disp.Dispose();
        }
    }
}

Обратите внимание на блок finally: объект удаляется, даже если возникает исключение. Также обратите внимание на дополнительный блок анонимной области видимости: это означает, что объект не только удаляется, но и выходит за пределы области видимости.

Другая важная вещь здесь - это то, что утилизация гарантированно произойдет сразу же. Это детерминированный. Без оператора using или аналогичной конструкции объект все равно выйдет из области видимости в конце метода и в конечном итоге может быть собран. В идеале ресурс должен быть уничтожен, чтобы система могла его восстановить. Но «в конце концов» может не произойти какое-то время, а «в идеале» и «будет» - очень разные вещи.

Следовательно, «в конечном итоге» не всегда достаточно. Ресурсы, такие как соединения с базой данных, сокеты, семафоры / мьютексы и (в данном случае) ресурсы GDI, часто сильно ограничены и требуют немедленной очистки . Оператор using гарантирует, что это произойдет.

Конструкция using обеспечивает детерминированное удаление, т. Е. Высвобождение ресурсов. В приведенном выше примере да, если вы не используете оператор using, объект будет удален, но только если рекомендованный шаблон одноразового использования (то есть удаление ресурсов из финализатора класса , если применимо) был реализован для рассматриваемого класса (в вашем примере - класс Font). Следует отметить, что конструкция using может использоваться только с объектами, реализующими интерфейс IDisposable. Именно наличие этого интерфейса на объекте позволяет использовать для "вызова" метода Dispose.

Кроме того, базовые ресурсы будут освобождены только тогда, когда сборщик мусора решит собрать ваш объект Font вне области видимости. Ключевой концепцией программирования .Net (и большинства языков со сборщиком мусора) является то, что тот факт, что объект выходит за пределы области видимости, не означает, что он завершен / выпущен / уничтожен и т. Д. Скорее, сборщик мусора выполнит очистку. он определяет, а не сразу, когда объект выходит за пределы области видимости.

Наконец, оператор using «запекает» конструкцию try / finally, чтобы гарантировать, что Dispose вызывается независимо от содержащегося в нем кода, генерирующего исключение.

«Использование» вступает в игру, когда ресурс необходимо удалить, и он реализует интерфейс IDisposable.

Когда метод завершается, не удаляется ли объект Font в любом случае?

Нет, на него больше не будут ссылаться и, следовательно, на него можно будет выполнять сборку мусора. Если что-то еще (например, ссылка, содержащаяся в другой структуре данных) не удерживает ссылку.

Или метод Dispose запускается в другое время после выхода из метода?

Да, в процессе, не выделяющем много памяти, это может занять значительное время после выхода из метода.

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

Мне это кажется очень простым.

Если класс реализует IDisposable, то он почти просит вызвать Dispose для любого созданного вами экземпляра, как только вы закончите с ним. Я предлагаю использовать этот шаблон всякий раз, когда создается такой экземпляр:

using (var instanceName = new DisposableClass())
{
    // Your code here
}

Это просто, чисто и работает для всего, кроме классов прокси WCF, которые не работают. Для тех, см. http://www.iserviceoriated.com/blog/post/Indisposable+-+WCF+Gotcha+1.aspx.

Вот что действительно делает использование (на основе вашего примера)

Font font1 = new Font(...);
try
{
    // code that uses font...
}
finally
{
    if (font1 != null)
        font1.Dispose();
}

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

Они полезны в любой ситуации, когда вы хотите, чтобы код очистки вызывал для объекта детерминированно и независимо от исключений (поскольку оператор using на самом деле является просто try/finally).

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

Это чисто синтаксический сахар поверх блока try-catch-finally и вызова метода Dispose. Он даже не обязательно определяет лексическую область видимости, поскольку вы можете передать ему переменную экземпляра. По сути, это делает ваш код чище и проще в обслуживании.

Dispose вызывается при выходе из оператора using, поскольку он явно вызывается этой конструкцией. Метод dispose не вызывается явно, когда переменная выходит за пределы области видимости (метод выхода).

Поведение, которое вы МОЖЕТЕ наблюдать, выглядит так: обычно вещи, реализующие IDisposable, также вызывают метод Dispose в деструкторе классов, и деструктор МОЖЕТ быть вызван вскоре после того, как переменная выходит за пределы области видимости, но это не гарантируется. Деструктор вызывается сборщиком мусора.

Мне нравится использовать их вот так:

    static public void AddSampleData(String name)
    {
        String CreateScript = GetScript(String.Format("SampleData_{0}", name));
        using (IDbConnection MyConnection = GetConnection())
        {
            MyConnection.Open();
            IDbCommand MyCommand = MyConnection.CreateCommand();
            foreach (String SqlScriptLine in CreateScript.Split(';'))
            {
                String CleanedString = SqlScriptLine.Replace(";", "").Trim();
                if (CleanedString.Length == 0)
                    continue;

                MyCommand.CommandText = CleanedString;
                int Result = MyCommand.ExecuteNonQuery();
            }
        }
    }

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

    static public void AddSampleData(String name)
    {
        String CreateScript = GetScript(String.Format("SampleData_{0}", name));

        IDbConnection MyConnection = null;
        try
        {
            IDbConnection MyConnection = GetConnection();
            MyConnection.Open();
            IDbCommand MyCommand = MyConnection.CreateCommand();
            foreach (String SqlScriptLine in CreateScript.Split(';'))
            {
                String CleanedString = SqlScriptLine.Replace(";", "").Trim();
                if (CleanedString.Length == 0)
                    continue;

                MyCommand.CommandText = CleanedString;
                int Result = MyCommand.ExecuteNonQuery();
            }
        }
        finally
        {
            if (MyConnection != null
                && MyConnection.State == ConnectionState.Open)
                MyConnection.Close();
        }
    }

И честно говоря, какой метод легче читать? То же самое и с формами:

    public void ChangeConfig()
    {
        using (ConfigForm MyForm = new ConfigForm())
        {
            DialogResult ConfigResult = MyForm.ShowDialog();
            if (ConfigResult == DialogResult.OK)
                SaveConfig();
        }

        ConfigForm MyForm = new ConfigForm();
        DialogResult ConfigResult = MyForm.ShowDialog();
        MyForm.Dispose();
        if (ConfigResult == DialogResult.OK)
            SaveConfig();
    }

Все ответы о детерминированности и недетерминированности и о том, как using работает под капотом, верны.

Но чтобы выбрать конкретный образец, не забывайте, что почти все объекты System.Drawing (GDI + wrapper) также содержат ссылки на неуправляемую память, так что вы можете столкнуться с проблемами при их широком использовании, не избавляясь от них. правильно (где using - самый простой способ).

Я задал здесь очень похожий вопрос:

Ресурсы, которые необходимо вручную очистить в C #? < / а>