Правильное использование интерфейса IDisposable

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

public class LoggingContext : IDisposable {
    public Finicky(string name) {
        Log.Write("Entering Log Context {0}", name);
        Log.Indent();
    }
    public void Dispose() {
        Log.Outdent();
    }

    public static void Main() {
        Log.Write("Some initial stuff.");
        try {
            using(new LoggingContext()) {
                Log.Write("Some stuff inside the context.");
                throw new Exception();
            }
        } catch {
            Log.Write("Man, that was a heavy exception caught from inside a child logging context!");
        } finally {
            Log.Write("Some final stuff.");
        }
    }
}

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

Вы можете ознакомиться с этой статьей для более подробной информации о том, как реализовать шаблон Dispose, но в основном выглядит так:

public class SimpleCleanup : IDisposable
{
    // some fields that require cleanup
    private SafeHandle handle;
    private bool disposed = false; // to detect redundant calls

    public SimpleCleanup()
    {
        this.handle = /*...*/;
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Dispose managed resources.
                if (handle != null)
                {
                    handle.Dispose();
                }
            }

            // Dispose unmanaged managed resources.

            disposed = true;
        }
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
}

Наиболее важным здесь является Dispose (bool), который фактически работает в двух разных обстоятельствах:

• disposing == true: метод был вызван прямо или косвенно с помощью кода пользователя. Управляемые и неуправляемые ресурсы могут быть удалены.
• disposing == false: метод был вызван средой выполнения внутри финализатора, и вы не должны ссылаться на другие объекты. Могут быть удалены только неуправляемые ресурсы.

Проблема простое, чтобы GC заботиться о том, чтобы очистить, состоит в том, что у вас нет реального контроля, когда GC будет запускать цикл сбора (вы можете вызвать GC.Collect(), но вы действительно не должны этого делать) ресурсы могут оставаться дольше, чем необходимо. Помните, что вызов Dispose() фактически не вызывает цикл сбора или каким-либо образом заставляет GC собирать/освобождать объект; он просто предоставляет средства для более детерминированной очистки используемых ресурсов и сообщает GC, что эта очистка уже выполнена.

Весь смысл IDisposable и шаблона dispose заключается не в немедленном освобождении памяти. Единственный раз, когда вызов Dispose на самом деле даже имеет шанс немедленно освободить память, когда он обрабатывает сценарий dispose == false и манипулирует неуправляемыми ресурсами. Для управляемого кода память фактически не будет восстановлена ​​до тех пор, пока GC не проведет цикл сбора, который вы действительно не контролируете (кроме вызова GC.Collect(), о котором я уже говорил, это не очень хорошая идея).

Ваш сценарий действительно недействителен, поскольку строки в .NET не используют какие-либо неизведанные ресурсы и не реализуют IDisposable, нет способа заставить их "очищаться".

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

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

Что сводится к тому, что есть функция, которую вы можете вызвать, чтобы привести систему в состояние, и есть еще одна функция, которую вы можете вызвать, чтобы вывести ее из этого состояния. Теперь, в типичном примере, первая может быть функцией, которая возвращает дескриптор файла, а второй - вызовом CloseHandle.

Но - и это ключ - они могут быть любой подходящей парой функций. Один строит состояние, другой срывает его. Если государство было построено, но не снесено, то существует экземпляр ресурса. Вам необходимо организовать разрывы в нужное время - ресурс не управляется CLR. Единственным автоматически управляемым типом ресурса является память. Существует два вида: GC и стек. Типы значений управляются стеком (или путем приведения в движение внутри ссылочных типов), а ссылочные типы управляются GC.

Эти функции могут приводить к изменениям состояния, которые могут свободно перемежаться или, возможно, должны быть полностью вложенными. Изменения состояния могут быть потокобезопасными, или они могут не быть.

Посмотрите на пример в вопросе "Правосудие". Изменения в отладке файла журнала должны быть полностью вложенными, или все идет не так. Также они вряд ли будут потокобезопасными.

Можно собрать поездку с сборщиком мусора, чтобы очистить неуправляемые ресурсы. Но только если функции изменения состояния являются потокобезопасными, а два состояния могут иметь периоды жизни, которые перекрываются каким-либо образом. Итак, пример юстиции ресурса НЕ должен иметь финализатор! Это никому не помогло.

Для этих ресурсов вы можете просто реализовать IDisposable без финализатора. Финализатор абсолютно необязателен - это должно быть. Это замалчивается или даже не упоминается во многих книгах.

Затем вам нужно использовать оператор using, чтобы иметь возможность гарантировать, что вызывается Dispose. Это по существу похоже на то, что вы едете со стеком (так как финализатор относится к GC, using относится к стеку).

Недопустимая часть состоит в том, что вам нужно вручную записать Dispose и заставить ее вызывать свои поля и ваш базовый класс. Программистам С++/CLI этого не нужно. В большинстве случаев компилятор записывает их для них.

Есть альтернатива, которую я предпочитаю для состояний, которые идеально встраиваются и не являются потокобезопасными (кроме всего прочего, избегая IDisposable spares, вы имеете проблему с аргументом с кем-то, кто не может удержаться от добавления финализатора для каждого класса, который реализует IDisposable).

Вместо написания класса вы пишете функцию. Функция принимает делегата для обратного вызова:

public static void Indented(this Log log, Action action)
{
    log.Indent();
    try
    {
        action();
    }
    finally
    {
        log.Outdent();
    }
}

И тогда простой пример:

Log.Write("Message at the top");
Log.Indented(() =>
{
    Log.Write("And this is indented");

    Log.Indented(() =>
    {
        Log.Write("This is even more indented");
    });
});
Log.Write("Back at the outermost level again");

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

Этот метод менее полезен, если ресурс является видом, который может иметь перекрывающиеся сроки жизни, потому что тогда вы хотите иметь возможность создавать ресурс A, затем ресурс B, а затем убивать ресурс A, а затем убивать ресурс B. Вы можете ' t сделать это, если вы заставили пользователя идеально вложить такие гнезда. Но тогда вам нужно использовать IDisposable (но все же без финализатора, если только вы не реализовали потоки, которые не являются бесплатными).

Сценарии Я использую IDisposable: очистка неуправляемых ресурсов, отмена подписки на события, закрытые соединения

Идиома, которую я использую для реализации IDisposable (not threadsafe):

class MyClass : IDisposable {
    // ...

    #region IDisposable Members and Helpers
    private bool disposed = false;

    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing) {
        if (!this.disposed) {
            if (disposing) {
                // cleanup code goes here
            }
            disposed = true;
        }
    }

    ~MyClass() {
        Dispose(false);
    }
    #endregion
}

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

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

EDIT В ответ на комментарий Скотта:

Единственный момент, когда влияют показатели производительности GC, - это когда вызывается [sic] GC.Collect() "

Концептуально, GC поддерживает представление о графе ссылок на объекты и все ссылки на него из фреймов стека потоков. Эта куча может быть довольно большой и охватывать многие страницы памяти. В качестве оптимизации GC анализирует страницы, которые вряд ли будут меняться очень часто, чтобы избежать повторного сканирования страницы без необходимости. GC получает уведомление от ядра, когда данные на странице меняются, поэтому он знает, что страница загрязнена и требует повторного сканирования. Если коллекция находится в Gen0, то вероятно, что другие вещи на странице тоже меняются, но это менее вероятно в Gen1 и Gen2. Анекдотически эти крючки не были доступны в Mac OS X для команды, которая портировала GC на Mac, чтобы получить подключаемый модуль Silverlight, работающий на этой платформе.

Еще один момент против ненужной утилизации ресурсов: представьте ситуацию, когда процесс выгружается. Представьте также, что этот процесс работает некоторое время. Скорее всего, многие из этих страниц памяти процесса были заменены на диск. По крайней мере, они больше не находятся в кешках L1 или L2. В такой ситуации нет смысла использовать приложение для разгрузки для замены всех этих данных и кодовых страниц в память для "освобождения" ресурсов, которые в любом случае будут освобождены операционной системой, когда процесс завершится. Это относится к управляемым и даже к неуправляемым ресурсам. Только ресурсы, которые поддерживают не-фоновые потоки, должны быть удалены, иначе процесс останется в живых.

Теперь во время обычного выполнения есть эфемерные ресурсы, которые необходимо очистить правильно (поскольку @fezmonkey указывает соединения с базой данных, сокеты, дескрипторы окон), чтобы избежать неуправляемых утечек памяти. Это те вещи, которые нужно уничтожить. Если вы создаете какой-то класс, которому принадлежит поток (и по собственному я имею в виду, что он его создал, и поэтому он отвечает за то, чтобы он остановился, по крайней мере, по моему стилю кодирования), тогда этот класс, скорее всего, должен реализовать IDisposable и снести нить во время Dispose.

.NET framework использует интерфейс IDisposable как сигнал, даже предупреждающий разработчиков, что этот класс должен быть удален. Я не могу думать о каких-либо типах в рамках, реализующих IDisposable (исключая явные реализации интерфейса), где удаление необязательно.

Да, этот код является полностью избыточным и ненужным, и он не делает сборщик мусора делать что-либо, что он не сделал бы иначе (если экземпляр MyCollection выходит за пределы области видимости.) Особенно вызовы .Clear().

Отвечайте на свое редактирование: Сортировка. Если я это сделаю:

public void WasteMemory()
{
    var instance = new MyCollection(); // this one has no Dispose() method
    instance.FillItWithAMillionStrings();
}

// 1 million strings are in memory, but marked for reclamation by the GC

Он функционально идентичен этому для управления памятью:

public void WasteMemory()
{
    var instance = new MyCollection(); // this one has your Dispose()
    instance.FillItWithAMillionStrings();
    instance.Dispose();
}

// 1 million strings are in memory, but marked for reclamation by the GC

Если вам действительно действительно нужно освободить память в этот самый момент, вызовите GC.Collect(). Однако здесь нет оснований делать это. При необходимости память будет освобождена.

Если вы хотите удалить прямо сейчас, используйте неуправляемую память.

См:

• Marshal.AllocHGlobal
• Marshal.FreeHGlobal
• Marshal.DestroyStructure

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

Public Class LargeStuff
  Implements IDisposable
  Private _Large as string()

  'Some strange code that means _Large now contains several million long strings.

  Public Sub Dispose() Implements IDisposable.Dispose
    _Large=Nothing
  End Sub

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

Ответ: Нет.
Вызов Dispose может освобождать неуправляемые ресурсы, он НЕ МОЖЕТ восстановить управляемую память, только GC может это сделать. Это не означает, что вышеизложенное не является хорошей идеей, следуя приведенной выше схеме, по-прежнему остается хорошей идеей. После того, как Dispose был запущен, ничего не мешает GC повторно запрашивать память, которая используется _Large, хотя экземпляр LargeStuff все еще может быть в области видимости. Строки в _Large также могут быть в гене 0, но экземпляр LargeStuff может быть gen 2, поэтому снова память будет повторно заявлена ​​раньше.
Нет смысла добавлять финализатора для вызова метода Dispose, показанного выше. Это будет просто ЗАДЕРЖАТЬ повторное требование к памяти, чтобы позволить финализатору работать.

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

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

Помимо первичного использования в качестве способа управления ресурсом системных ресурсов (полностью охваченных удивительным ответом Ian, kudos!), IDisposable/using может также использоваться для области изменения состояния (критических) глобальных ресурсов: консоли, потоков, процесса, любого глобального объекта, такого как экземпляр приложения. p >

Я написал статью об этом шаблоне: http://pragmateek.com/c-scope-your-global-state-changes-with-idisposable-and-the-using-statement/

Он иллюстрирует, как вы можете защитить некоторое часто используемое глобальное состояние в многоразовом и читаемом способе: цвета консоли, текущая культура потоков, свойства объекта приложения Excel...

Во всяком случае, я ожидаю, что код будет менее эффективным, чем при его отсутствии.

Вызов методов Clear() не нужен, и GC, вероятно, не сделал бы этого, если Dispose не сделал этого...

Есть вещи, которые операция Dispose() делает в примере кода, который может иметь эффект, который не будет происходить из-за обычного GC объекта MyCollection.

Если объекты, на которые ссылаются _theList или _theDict, ссылаются на другие объекты, тогда объект List<> или Dictionary<> не будет подлежать сбору, но не будет иметь никакого содержимого. Если бы не было операции Dispose(), как в примере, эти коллекции все равно будут содержать их содержимое.

Конечно, если бы это была ситуация, я бы назвал ее сломанным дизайном - я просто указываю (по-видимому, педантично), что операция Dispose() может быть не полностью избыточной, в зависимости от того, существуют ли другие виды использования из List<> или Dictionary<>, которые не показаны в фрагменте.

Наиболее оправданным вариантом использования для распоряжения управляемыми ресурсами является подготовка к тому, чтобы GC восстановил ресурсы, которые в противном случае никогда не были бы собраны.

Первым примером является круговая ссылка.

В то время как лучше всего использовать шаблоны, которые избегают циклических ссылок, если вы в конечном итоге получаете (например) "дочерний" объект, у которого есть ссылка на его "родительский", это может остановить сбор GC GC родителя, если вы просто отказываетесь от ссылки и полагаетесь на GC-plus, если вы внедрили финализатор, он никогда не будет вызван.

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

Реализация IDisposable для родителей и детей - лучший способ сделать это. Когда Dispose вызывается в Parent, вызовите Dispose для всех дочерних элементов и в методе Dispose для детей установите для родительских ссылок значение null.

Первое из определения. Для меня неуправляемый ресурс означает некоторый класс, который реализует интерфейс IDisposable или что-то созданное с использованием вызовов в dll. GC не знает, как бороться с такими объектами. Если класс имеет, например, только типы значений, то я не рассматриваю этот класс как класс с неуправляемыми ресурсами. Для моего кода я следую следующим практикам:

• Если созданный мной класс использует некоторые неуправляемые ресурсы, значит, я также должен реализовать интерфейс IDisposable для очистки памяти.
  
• Очистите объекты, как только я их закончу.
  
• В моем методе dispose я перебираю все IDisposable членов класса и вызываю Dispose.
  
• В моем методе метода Dispose GC.SuppressFinalize(this), чтобы уведомить сборщика мусора о том, что мой объект уже очищен. Я делаю это, потому что вызов GC - дорогостоящая операция.
  
• В качестве дополнительной меры предосторожности я пытаюсь сделать возможным вызов Dispose() несколько раз.
  
• Когда-то я добавляю закрытый член _disposed и проверяет вызовы методов, если объект был очищен. И если он был очищен, сгенерируйте ObjectDisposedException
  Следующий шаблон демонстрирует то, что я описал в словах как образец кода:
  

public class SomeClass : IDisposable
    {
        /// <summary>
        /// As usually I don't care was object disposed or not
        /// </summary>
        public void SomeMethod()
        {
            if (_disposed)
                throw new ObjectDisposedException("SomeClass instance been disposed");
        }

        public void Dispose()
        {
            Dispose(true);
        }

        private bool _disposed;

        protected virtual void Dispose(bool disposing)
        {
            if (_disposed)
                return;
            if (disposing)//we are in the first call
            {
            }
            _disposed = true;
        }
    }

Одна из проблем большинства обсуждений "неуправляемых ресурсов" заключается в том, что они действительно не определяют этот термин, но, похоже, подразумевают, что он имеет какое-то отношение к неуправляемому коду. Хотя верно, что многие типы неуправляемых ресурсов взаимодействуют с неуправляемым кодом, мышление о неуправляемых ресурсах в таких терминах не помогает.

Вместо этого следует понимать, что общего у всех управляемых ресурсов: все они влекут за собой объект, запрашивающий у кого-то вне "вещи" что-то делать от его имени, в ущерб каким-то другим "вещам", а другое лицо соглашается сделайте это до дальнейшего уведомления. Если объект должен был быть оставлен и исчезнут без следа, ничто не могло бы сказать, что вне "вещи" ему больше не нужно было изменять свое поведение от имени объекта, который больше не существовал; следовательно, "полезность вещей будет постоянно уменьшаться".

Таким образом, неуправляемый ресурс представляет собой соглашение какой-либо внешней "вещи", чтобы изменить свое поведение от имени объекта, что бесполезно ухудшало бы полезность этой внешней "вещи", если бы объект был оставлен и прекратил свое существование. Управляемый ресурс - это объект, который является бенефициаром такого соглашения, но который подписал для получения уведомления, если он оставлен, и который будет использовать такое уведомление, чтобы привести свои дела в порядок до его уничтожения.

IDisposable подходит для отмены подписки на события.

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

В следующем примере показан хороший пример для шаблона IDisposable с некоторым кодом и комментариями.

public class DisposeExample
{
    // A base class that implements IDisposable. 
    // By implementing IDisposable, you are announcing that 
    // instances of this type allocate scarce resources. 
    public class MyResource: IDisposable
    {
        // Pointer to an external unmanaged resource. 
        private IntPtr handle;
        // Other managed resource this class uses. 
        private Component component = new Component();
        // Track whether Dispose has been called. 
        private bool disposed = false;

        // The class constructor. 
        public MyResource(IntPtr handle)
        {
            this.handle = handle;
        }

        // Implement IDisposable. 
        // Do not make this method virtual. 
        // A derived class should not be able to override this method. 
        public void Dispose()
        {
            Dispose(true);
            // This object will be cleaned up by the Dispose method. 
            // Therefore, you should call GC.SupressFinalize to 
            // take this object off the finalization queue 
            // and prevent finalization code for this object 
            // from executing a second time.
            GC.SuppressFinalize(this);
        }

        // Dispose(bool disposing) executes in two distinct scenarios. 
        // If disposing equals true, the method has been called directly 
        // or indirectly by a user code. Managed and unmanaged resources 
        // can be disposed. 
        // If disposing equals false, the method has been called by the 
        // runtime from inside the finalizer and you should not reference 
        // other objects. Only unmanaged resources can be disposed. 
        protected virtual void Dispose(bool disposing)
        {
            // Check to see if Dispose has already been called. 
            if(!this.disposed)
            {
                // If disposing equals true, dispose all managed 
                // and unmanaged resources. 
                if(disposing)
                {
                    // Dispose managed resources.
                    component.Dispose();
                }

                // Call the appropriate methods to clean up 
                // unmanaged resources here. 
                // If disposing is false, 
                // only the following code is executed.
                CloseHandle(handle);
                handle = IntPtr.Zero;

                // Note disposing has been done.
                disposed = true;

            }
        }

        // Use interop to call the method necessary 
        // to clean up the unmanaged resource.
        [System.Runtime.InteropServices.DllImport("Kernel32")]
        private extern static Boolean CloseHandle(IntPtr handle);

        // Use C# destructor syntax for finalization code. 
        // This destructor will run only if the Dispose method 
        // does not get called. 
        // It gives your base class the opportunity to finalize. 
        // Do not provide destructors in types derived from this class.
        ~MyResource()
        {
            // Do not re-create Dispose clean-up code here. 
            // Calling Dispose(false) is optimal in terms of 
            // readability and maintainability.
            Dispose(false);
        }
    }
    public static void Main()
    {
        // Insert code here to create 
        // and use the MyResource object.
    }
}