Будет ли сборщик мусора вызывать IDisposable. Утилизировать для меня?

.NET IDisposable Pattern подразумевает, что если вы пишете финализатор и внедряете IDisposable, ваш финализатор должен явно вызывать Dispose. Это логично, и это то, что я всегда делал в тех редких ситуациях, когда требуется финализатор.

Однако, что произойдет, если я просто сделаю это:

class Foo : IDisposable
{
     public void Dispose(){ CloseSomeHandle(); }
}

и не реализовывать финализатор или что-то еще. Будет ли фреймворк вызывать метод Dispose для меня?

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

1. Кто-то несколько лет назад однажды сказал мне, что он на самом деле это сделает, и у этого человека был очень солидный послужной список "знания своих вещей".

2. Компилятор / фреймворк выполняет другие «волшебные» вещи в зависимости от того, какие интерфейсы вы реализуете (например, foreach, методы расширения, сериализация на основе атрибутов и т. Д.), Поэтому имеет смысл, что это тоже может быть «магическим».

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

Сборщик мусора .Net вызывает метод Object.Finalize объекта для сборки мусора. По умолчанию это ничего не делает и должно быть переопределено, если вы хотите освободить дополнительные ресурсы.

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

см. http://msdn.microsoft.com/en-us/library/system.object.finalize.aspx для получения дополнительной информации

Я хочу подчеркнуть точку зрения Брайана в его комментарии, потому что это важно.

Финализаторы не являются детерминированными деструкторами, как в C ++. Как уже отмечали другие, нет гарантии того, когда он будет вызван, и действительно, если у вас достаточно памяти, будет ли он когда-либо вызван.

Но плохая вещь в финализаторах заключается в том, что, как сказал Брайан, это заставляет ваш объект переживать сборку мусора. Это может быть плохо. Зачем?

Как вы можете знать, а может и не знать, GC разделен на поколения - Gen 0, 1 и 2 плюс куча больших объектов. Разделение - это бесполезный термин - вы получаете один блок памяти, но есть указатели того, где объекты Gen 0 начинаются и заканчиваются.

Мысленный процесс состоит в том, что вы, вероятно, будете использовать множество объектов, которые будут недолговечны. Так что GC должен легко и быстро добраться до объектов Gen 0. Поэтому, когда возникает нехватка памяти, первое, что он делает, это коллекция Gen 0.

Теперь, если это не устраняет достаточное давление, он возвращается и выполняет развертку 1-го поколения (переделывает Gen 0), а затем, если все еще недостаточно, он выполняет развертку 2-го поколения (повторяет Gen 1 и Gen 0). Таким образом, очистка долгоживущих объектов может занять некоторое время и быть довольно дорогой (поскольку ваши потоки могут быть приостановлены во время операции).

Это означает, что если вы делаете что-то вроде этого:

~MyClass() { }

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

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

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

• Сборщик мусора никогда не выполнит для вас метод Dispose.
• GC выполнит финализаторы, когда захочет .
• Один общий шаблон, который используется для объектов, имеющих финализатор, - это вызов его метода, который по соглашению определен как Dispose (удаление bool), передавая false, чтобы указать, что вызов был сделан из-за финализации, а не явного вызова Dispose.
• Это связано с тем, что при финализации объекта небезопасно делать какие-либо предположения о других управляемых объектах (возможно, они уже были завершены).

class SomeObject : IDisposable {
 IntPtr _SomeNativeHandle;
 FileStream _SomeFileStream;

 // Something useful here

 ~ SomeObject() {
  Dispose(false);
 }

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

 protected virtual void Dispose(bool disposing) {
  if(disposing) {
   GC.SuppressFinalize(this);
   //Because the object was explicitly disposed, there will be no need to 
   //run the finalizer.  Suppressing it reduces pressure on the GC

   //The managed reference to an IDisposable is disposed only if the 
   _SomeFileStream.Dispose();
  }

  //Regardless, clean up the native handle ourselves.  Because it is simple a member
  // of the current instance, the GC can't have done anything to it, 
  // and this is the onlyplace to safely clean up

  if(IntPtr.Zero != _SomeNativeHandle) {
   NativeMethods.CloseHandle(_SomeNativeHandle);
   _SomeNativeHandle = IntPtr.Zero;
  }
 }
}

Это простая версия, но есть много нюансов, которые могут запутать вас в этом паттерне.

• Контракт для IDisposable.Dispose указывает, что вызов должен быть безопасным несколько раз (вызов Dispose для объекта, который уже был удален, ничего не должен делать)
• Правильно управлять иерархией наследования одноразовых объектов может быть очень сложно, особенно если разные уровни представляют новые одноразовые и неуправляемые ресурсы. В приведенном выше шаблоне Dispose (bool) является виртуальным, что позволяет переопределять его, чтобы им можно было управлять, но я считаю его подверженным ошибкам.

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

Простое определение SafeHandle делает это тривиальным:

private class SomeSafeHandle
 : SafeHandleZeroOrMinusOneIsInvalid {
 public SomeSafeHandle()
  : base(true)
  { }

 protected override bool ReleaseHandle()
 { return NativeMethods.CloseHandle(handle); }
}

Позволяет упростить содержащий тип:

class SomeObject : IDisposable {
 SomeSafeHandle _SomeSafeHandle;
 FileStream _SomeFileStream;
 // Something useful here
 public virtual void Dispose() {
  _SomeSafeHandle.Dispose();
  _SomeFileStream.Dispose();
 }
}

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

РЕДАКТИРОВАТЬ: Я ушел и проверил, просто чтобы убедиться:

class Program
{
    static void Main(string[] args)
    {
        Fred f = new Fred();
        f = null;
        GC.Collect();
        GC.WaitForPendingFinalizers();
        Console.WriteLine("Fred's gone, and he's not coming back...");
        Console.ReadLine();
    }
}

class Fred : IDisposable
{
    ~Fred()
    {
        Console.WriteLine("Being finalized");
    }

    void IDisposable.Dispose()
    {
        Console.WriteLine("Being Disposed");
    }
}

Не в том случае, который вы описываете, но GC позвонит вам в финализатор , если он у вас есть.

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

В зависимости от нагрузки на память вашего приложения, у вас может не быть gc для генерации этого объекта некоторое время. Таким образом, в случае, скажем, файлового потока или соединения БД, вам, возможно, придется подождать некоторое время, пока неуправляемый ресурс на некоторое время будет освобожден в вызове финализатора, что вызовет некоторые проблемы.

Нет, это не называется.

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

Я сделал следующий тест для этого:

class Program
{
    static void Main(string[] args)
    {
        Foo foo = new Foo();
        foo = null;
        Console.WriteLine("foo is null");
        GC.Collect();
        Console.WriteLine("GC Called");
        Console.ReadLine();
    }
}

class Foo : IDisposable
{
    public void Dispose()
    {

        Console.WriteLine("Disposed!");
    }

GC не будет звонить утилизировать. Он может вызвать ваш финализатор, но даже это не гарантируется при любых обстоятельствах.

Смотрите эту статью для обсуждения лучшего способа справиться с этим.

Документация по IDisposable дает довольно четкое и подробное объяснение поведения, а также пример кода. GC НЕ вызовет Dispose()метод интерфейса, но вызовет финализатор для вашего объекта.

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

Отказоустойчивым для шаблона является реализация финализатора, вызывающего метод Dispose (). Если вы этого не сделаете, вы можете создать некоторые утечки памяти, например: Если вы создаете какую-либо оболочку COM и никогда не вызываете System.Runtime.Interop.Marshall.ReleaseComObject (comObject) (который будет помещен в метод Dispose).

В clr нет магии для автоматического вызова методов Dispose, кроме отслеживания объектов, содержащих финализаторы, и их сохранения в таблице финализаторов GC и вызова их, когда GC запускает некоторую очистку эвристики.