Когда C# “используют” самые полезные операторы?

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

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

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

Я большой поклонник управления заданиями Bash , главным образом использования Control-Z и fg , особенно если я занимаюсь разработкой в ​​терминале. Если у меня открыт emacs и мне нужно скомпилировать, развернуть и т. Д. Я просто Control-Z приостановил emacs, сделал то, что мне нужно, и fg , чтобы вернуть его. Это сохраняет все буферы Emacs в целости и делает их намного проще, чем перезапускает все, что я делаю.

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

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

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

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

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

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

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

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

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

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

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

Да, в процессе, который не выделяет много памяти, что может занять значительное время после завершения метода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И я получил хороший совет в виде:

В общем, если у чего-то есть метод 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();
    }

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

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