Використання методу Finalize / Dispose у C #

C # 2008

Я над цим працюю вже деякий час, і я все ще плутаюсь щодо використання методів доопрацювання та розпорядження кодом. Мої запитання нижче:

1. Я знаю, що нам потрібен лише фіналізатор під час розміщення некерованих ресурсів. Однак якщо є керовані ресурси, які здійснюють дзвінки на некеровані ресурси, чи все-таки потрібно буде застосувати фіналізатор?

2. Однак, якщо я розробляю клас, який не використовує жодних некерованих ресурсів - прямо чи опосередковано, чи слід реалізувати, IDisposableщоб дозволити клієнтам цього класу користуватися оператором "using"?

   Чи можливо реалізувати IDisposable просто для того, щоб клієнти вашого класу могли використовувати оператор, що використовує?

   using(myClass objClass = new myClass())
   {
       // Do stuff here
   }

3. Нижче я розробив цей простий код, щоб продемонструвати завершення використання:

   public class NoGateway : IDisposable
   {
       private WebClient wc = null;
   
       public NoGateway()
       {
           wc = new WebClient();
           wc.DownloadStringCompleted += wc_DownloadStringCompleted;
       }
   
   
       // Start the Async call to find if NoGateway is true or false
       public void NoGatewayStatus()
       {
           // Start the Async's download
               // Do other work here
           wc.DownloadStringAsync(new Uri(www.xxxx.xxx));
       }
   
       private void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
       {
           // Do work here
       }
   
       // Dispose of the NoGateway object
       public void Dispose()
       {
           wc.DownloadStringCompleted -= wc_DownloadStringCompleted;
           wc.Dispose();
           GC.SuppressFinalize(this);
       }
   }

Питання про вихідний код:

1. Тут я не додав фіналізатор, і зазвичай фіналізатор викличе GC, а фіналізатор викличе Dispose. Оскільки у мене немає фіналізатора, коли я зателефоную за методом Dispose? Чи повинен клієнт класу викликати його?

   Тож мій клас у прикладі називається NoGateway, і клієнт може використовувати та розпоряджатися таким класом:

   using(NoGateway objNoGateway = new NoGateway())
   {
       // Do stuff here   
   }

   Чи автоматично буде викликаний метод Dispose, коли виконання досягне кінця блоку, або клієнт повинен вручну викликати метод розпорядження? тобто

   NoGateway objNoGateway = new NoGateway();
   // Do stuff with object
   objNoGateway.Dispose(); // finished with it

2. Я використовую WebClientклас у своєму NoGatewayкласі. Оскільки WebClientреалізує IDisposableінтерфейс, чи означає це, що WebClientопосередковано використовуються некеровані ресурси? Чи існує чітке і швидке правило для цього? Як я можу знати, що клас використовує некеровані ресурси?

Рекомендована IDisposable картина тут . При програмуванні класу, який використовує IDisposable, як правило, слід використовувати два шаблони:

Реалізуючи герметичний клас, який не використовує керовані ресурси, ви просто реалізуєте метод Dispose, як і у звичайних реалізаціях інтерфейсу:

public sealed class A : IDisposable
{
    public void Dispose()
    {
        // get rid of managed resources, call Dispose on member variables...
    }
}

Реалізуючи незапечатаний клас, зробіть це так:

public class B : IDisposable
{    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }   
        // get rid of unmanaged resources
    }

    // only if you use unmanaged resources directly in B
    //~B()
    //{
    //    Dispose(false);
    //}
}

Зауважте, що я не оголосив фіналізатор у B; Вам слід застосувати фіналізатор лише у тому випадку, якщо у вас є фактичні некеровані ресурси для розпорядження. CLR має відношення до об'єктів, що можна доопрацювати, по-різному до об'єктів, що не завершуються, навіть якщо SuppressFinalizeвони викликаються.

Таким чином, ви не повинні оголошувати фіналізатор, якщо вам не доведеться, але ви даєте спадкоємцям свого класу гачок, щоб викликати ваш Disposeі реалізувати фіналізатор самостійно, якщо вони безпосередньо використовують некеровані ресурси:

public class C : B
{
    private IntPtr m_Handle;

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }
        ReleaseHandle(m_Handle);

        base.Dispose(disposing);
    }

    ~C() {
        Dispose(false);
    }
}

Якщо ви не використовуєте керовані ресурси безпосередньо ( SafeHandleа друзі не враховуються, оскільки вони декларують власні фіналізатори), тоді не застосовуйте фіналізатор, оскільки GC по-різному поводиться з класами для завершення, навіть якщо згодом ви придушите фіналізатор. Також зауважте, що, хоча Bвін не має фіналізатора, він все ще закликає SuppressFinalizeправильно мати справу з будь-якими підкласами, які реалізують фіналізатор.

Коли клас реалізує інтерфейс IDisposable, це означає, що десь є деякі некеровані ресурси, яких слід позбутися, коли ви закінчили використовувати клас. Фактичні ресурси вкладені в класи; видаляти їх не потрібно. Просто зателефонувавши Dispose()або загорнувши клас у засвідчення, ви using(...) {}зможете позбутися будь-яких некерованих ресурсів у міру необхідності.

Офіційну схему для реалізації IDisposableважко зрозуміти. Я вважаю, що це краще :

public class BetterDisposableClass : IDisposable {

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

  protected virtual void CleanUpManagedResources() { 
    // ...
  }
  protected virtual void CleanUpNativeResources() {
    // ...
  }

  ~BetterDisposableClass() {
    CleanUpNativeResources();
  }

}

Ще кращим рішенням є правило, згідно з яким завжди потрібно створити клас обгортки для будь-якого некерованого ресурсу, з яким потрібно обробляти:

public class NativeDisposable : IDisposable {

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

  protected virtual void CleanUpNativeResource() {
    // ...
  }

  ~NativeDisposable() {
    CleanUpNativeResource();
  }

}

З SafeHandleта його похідними ці класи мають бути дуже рідкісними .

Результат для одноразових класів, які не займаються безпосередньо некерованими ресурсами, навіть за наявності спадщини, є потужним: їм більше не потрібно займатися некерованими ресурсами . Їх буде просто реалізувати та зрозуміти:

public class ManagedDisposable : IDisposable {

  public virtual void Dispose() {
    // dispose of managed resources
  }

}

Зауважте, що будь-яка реалізація, яка використовується для ідентифікації, повинна відповідати наведеній нижче схемі (IMHO). Я розробив цю модель на основі інформації від кількох чудових .NET "богів" .NET Framework Design Guidelines (зауважте, що MSDN чомусь не дотримується цього!). Настанови .NET Framework Design були написані Кшиштофом Кваліною (архітектор CLR в той час), Бредом Абрамсом (я вважаю, менеджером програми CLR в той час) і Біллом Вагнером ([Ефективний C #] та [Більш ефективний C #] (просто візьміть a шукайте їх на Amazon.com:

Зауважте, що НІКОЛИ не слід застосовувати Finalizer, якщо ваш клас безпосередньо не містить (не успадковує) ресурси без управління. Після того, як ви реалізуєте Finalizer у класі, навіть якщо його ніколи не називають, гарантовано будете користуватися додатковою колекцією. Він автоматично розміщується у черзі на завершення (яка працює на одному потоці). Крім того, одна дуже важлива примітка ... весь код, виконаний у Finalizer (якщо вам потрібно реалізувати його), ОБОВ'ЯЗКОВО має бути безпечним для потоків І виключенням! BAD речі відбуватимуться інакше ... (тобто невизначена поведінка, а у випадку винятку - фатальна непоправна аварія програми).

Шаблон, який я склав (і написав фрагмент коду), наступний:

#region IDisposable implementation

//TODO remember to make this class inherit from IDisposable -> $className$ : IDisposable

// Default initialization for a bool is 'false'
private bool IsDisposed { get; set; }

/// <summary>
/// Implementation of Dispose according to .NET Framework Design Guidelines.
/// </summary>
/// <remarks>Do not make this method virtual.
/// A derived class should not be able to override this method.
/// </remarks>
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.

    // Always use SuppressFinalize() in case a subclass
    // of this type implements a finalizer.
    GC.SuppressFinalize( this );
}

/// <summary>
/// Overloaded Implementation of Dispose.
/// </summary>
/// <param name="isDisposing"></param>
/// <remarks>
/// <para><list type="bulleted">Dispose(bool isDisposing) executes in two distinct scenarios.
/// <item>If <paramref name="isDisposing"/> equals true, the method has been called directly
/// or indirectly by a user's code. Managed and unmanaged resources
/// can be disposed.</item>
/// <item>If <paramref name="isDisposing"/> 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.</item></list></para>
/// </remarks>
protected virtual void Dispose( bool isDisposing )
{
    // TODO If you need thread safety, use a lock around these 
    // operations, as well as in your methods that use the resource.
    try
    {
        if( !this.IsDisposed )
        {
            if( isDisposing )
            {
                // TODO Release all managed resources here

                $end$
            }

            // TODO Release all unmanaged resources here



            // TODO explicitly set root references to null to expressly tell the GarbageCollector
            // that the resources have been disposed of and its ok to release the memory allocated for them.


        }
    }
    finally
    {
        // explicitly call the base class Dispose implementation
        base.Dispose( isDisposing );

        this.IsDisposed = true;
    }
}

//TODO Uncomment this code if this class will contain members which are UNmanaged
// 
///// <summary>Finalizer for $className$</summary>
///// <remarks>This finalizer will run only if the Dispose method does not get called.
///// It gives your base class the opportunity to finalize.
///// DO NOT provide finalizers in types derived from this class.
///// All code executed within a Finalizer MUST be thread-safe!</remarks>
//  ~$className$()
//  {
//     Dispose( false );
//  }
#endregion IDisposable implementation

Ось код для реалізації IDisposable у похідному класі. Зауважте, що вам не потрібно чітко перераховувати спадкування з IDisposable у визначенні похідного класу.

public DerivedClass : BaseClass, IDisposable (remove the IDisposable because it is inherited from BaseClass)


protected override void Dispose( bool isDisposing )
{
    try
    {
        if ( !this.IsDisposed )
        {
            if ( isDisposing )
            {
                // Release all managed resources here

            }
        }
    }
    finally
    {
        // explicitly call the base class Dispose implementation
        base.Dispose( isDisposing );
    }
}

Я опублікував цю реалізацію у своєму блозі за адресою: Як правильно схему розпорядження

Я погоджуюся з pm100 (і я повинен був прямо сказати про це в своєму попередньому пості).

Ніколи не слід реалізовувати IDisposable у класі, якщо він вам не потрібен. Щоб бути дуже конкретним, існує приблизно 5 разів, коли вам коли-небудь знадобиться / слід реалізувати IDisposable:

1. Ваш клас явно містить (тобто не через спадщину) будь-які керовані ресурси, які реалізують IDisposable і повинні бути очищені, як тільки ваш клас більше не використовується. Наприклад, якщо ваш клас містить екземпляр Stream, DbCommand, DataTable тощо.

2. Ваш клас явно містить будь-які керовані ресурси, які реалізують метод Close () - наприклад, IDataReader, IDbConnection тощо. Зверніть увагу, що деякі з цих класів реалізують IDisposable, використовуючи метод Dispose (), а також метод Close ().

3. Ваш клас явно містить некерований ресурс - наприклад, об’єкт COM, покажчики (так, ви можете використовувати вказівники в керованому C #, але вони повинні бути оголошені в блоках "небезпечних" і т.д. У випадку некерованих ресурсів, ви також повинні переконатися, що зателефонуйте System.Runtime.InteropServices.Marshal.ReleaseComObject () на RCW. Навіть незважаючи на те, що RCW теоретично є керованою обгорткою, під кришками все ще відбувається підрахунок посилань.

4. Якщо ваш клас підписався на події, використовуючи чіткі посилання. Вам потрібно скасувати реєстрацію / відсторонитися від подій. Завжди переконайтеся, що вони спочатку не є нульовими, перш ніж спробувати скасувати реєстрацію / відключити їх.

5. Ваш клас містить будь-яку комбінацію перерахованих вище ...

Рекомендованою альтернативою для роботи з об’єктами COM та використання Marshal.ReleaseComObject () є використання класу System.Runtime.InteropServices.SafeHandle.

Команда BCL (колектив бібліотек базового класу) має тут хороший пост у блозі http://blogs.msdn.com/bclteam/archive/2005/03/16/396900.aspx

Одним з дуже важливих зауважень є те, що якщо ви працюєте з WCF та прибираєте ресурси, вам варто ВЖЕ ЗАВЖДИ уникати блоку "використання". Існує безліч публікацій в блогах, а деякі на MSDN про те, чому це погана ідея. Я також розмістив про це тут - не використовуйте "using ()" з проксі-сервером WCF

Використання лямбдів замість IDisposable.

Я ніколи не був в захваті від усієї ідеї, що використовує / IDisposable. Проблема полягає в тому, що він вимагає від абонента:

• знайте, що вони повинні використовувати IDisposable
• не забудьте використати "користуватися".

Мій новий кращий метод - замість цього використовувати фабричний метод та лямбда

Уявіть, що я хочу зробити щось із SqlConnection (щось, що повинно бути загорнене у користування). Класично ви б це зробили

using (Var conn = Factory.MakeConnection())
{
     conn.Query(....);
}

Новий шлях

Factory.DoWithConnection((conn)=>
{
    conn.Query(...);
}

У першому випадку абонент може просто не використовувати синтаксис, що використовує. У другому випадку у користувача немає вибору. Не існує методу, який створює об'єкт SqlConnection, абонент повинен викликати DoWithConnection.

DoWithConnection виглядає приблизно так

void DoWithConnection(Action<SqlConnection> action)
{
   using (var conn = MakeConnection())
   {
       action(conn);
   }
}

MakeConnection зараз приватний

ніхто не відповів на запитання про те, чи слід реалізовувати IDisposable, хоча і цього не потрібно.

Коротка відповідь: Ні

Довга відповідь:

Це дозволить споживачеві вашого класу використовувати "використання". Питання, яке я б задав, - чому вони це роблять? Більшість розробників не використовуватимуть "використання", якщо не знають, що вони повинні - і як вони знають. Або

• його переглядає досвід (наприклад, клас сокета)
• її документально підтверджено
• вони обережні і бачать, що клас реалізує IDisposable

Отже, реалізуючи IDisposable, ви говорите розробникам (принаймні деяких), що цей клас завершує щось, що повинно бути випущено. Вони використовуватимуть "використання" - але є й інші випадки, коли використання неможливо (сфера дії об'єкта не локальна); і їм доведеться потурбуватися про термін експлуатації предметів у інших випадках - я б точно переживав. Але це не обов’язково

Ви реалізуєте Idisposable, щоб дозволити їм користуватися, але вони не будуть використовувати, якщо ви не скажете їм.

Тому не робіть цього

1. Якщо ви використовуєте інші керовані об'єкти, які використовують некеровані ресурси, за їх остаточну відповідальність не входить відповідальність. Ваша відповідальність полягає в тому, щоб зателефонувати розпоряджатися цими об'єктами, коли виклик Dispose на ваш об'єкт, і він зупиняється на цьому.

2. Якщо ваш клас не використовує ніяких обмежених ресурсів, я не розумію, чому ви зробили б ваш клас реалізувати IDisposable. Ви повинні робити це, лише якщо:

   • Знайте, що у вас скоро будуть обмежені ресурси у ваших об'єктах, тільки не зараз (і я маю на увазі, що як і в "ми все ще розвиваємося, це буде тут, перш ніж ми закінчимо", а не як "Я думаю, нам це буде потрібно ")
   • Використання обмежених ресурсів

3. Так, код, який використовує ваш код, повинен викликати метод розпорядження вашого об'єкта. І так, код, який використовує ваш об’єкт, може використовуватись так, usingяк ви показали.

4. (2 рази?) Цілком ймовірно, що WebClient використовує або некеровані ресурси, або інші керовані ресурси, що реалізують IDisposable. Точна причина, однак, не важлива. Що важливо, це те, що він реалізує IDisposable, і тому вам належить діяти на цих знаннях, видаляючи об'єкт, коли ви закінчите з ним, навіть якщо виявляється, що WebClient взагалі не використовує інших ресурсів.

Утилізація:

public abstract class DisposableObject : IDisposable
{
    public bool Disposed { get; private set;}      

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

    ~DisposableObject()
    {
        Dispose(false);
    }

    private void Dispose(bool disposing)
    {
        if (!Disposed)
        {
            if (disposing)
            {
                DisposeManagedResources();
            }

            DisposeUnmanagedResources();
            Disposed = true;
        }
    }

    protected virtual void DisposeManagedResources() { }
    protected virtual void DisposeUnmanagedResources() { }
}

Приклад успадкування:

public class A : DisposableObject
{
    public Component components_a { get; set; }
    private IntPtr handle_a;

    protected override void DisposeManagedResources()
    {
        try
        {
          Console.WriteLine("A_DisposeManagedResources");
          components_a.Dispose();
          components_a = null;
        }
        finally
        { 
          base.DisposeManagedResources();
        }
    }

    protected override void DisposeUnmanagedResources()
    {
        try
        {
          Console.WriteLine("A_DisposeUnmanagedResources");
          CloseHandle(handle_a);
          handle_a = IntPtr.Zero;
        }
        finally
        { 
          base.DisposeUnmanagedResources();
        }
    }
}

public class B : A
{
    public Component components_b { get; set; }
    private IntPtr handle_b;

    protected override void DisposeManagedResources()
    {
        try
        {
          Console.WriteLine("B_DisposeManagedResources");
          components_b.Dispose();
          components_b = null;
        }
        finally
        { 
          base.DisposeManagedResources();
        }
    }

    protected override void DisposeUnmanagedResources()
    {
        try
        {
          Console.WriteLine("B_DisposeUnmanagedResources");
          CloseHandle(handle_b);
          handle_b = IntPtr.Zero;
        }
        finally
        { 
          base.DisposeUnmanagedResources();
        }
    }
}

Деякі аспекти іншої відповіді дещо неправильні з 2 причин:

Спочатку,

using(NoGateway objNoGateway = new NoGateway())

насправді еквівалентно:

try
{
    NoGateway = new NoGateway();
}
finally
{
    if(NoGateway != null)
    {
        NoGateway.Dispose();
    }
}

Це може здатися смішним, оскільки "новий" оператор ніколи не повинен повертати "null", якщо у вас немає виключення OutOfMemory. Але врахуйте наступні випадки: 1. Ви викликаєте FactoryClass, який повертає ресурс, який не використовується, або 2. Якщо у вас є тип, який може або не може успадковувати з IDisposable, залежно від його реалізації - пам’ятайте, що я бачив, що шаблон, який використовується на відстані, реалізований неправильно багато Час у багатьох клієнтів, коли розробники просто додають метод Dispose (), не успадковуючи від IDisposable (поганий, поганий, поганий). У вас також може бути випадок повернення ідентифікаційного ресурсу з властивості чи методу (знову ж таки погано, погано, погано - не «видавати свої ідентифікаційні ресурси»)

using(IDisposable objNoGateway = new NoGateway() as IDisposable)
{
    if (NoGateway != null)
    {
        ...

Якщо оператор "as" повертає null (або властивість чи метод, що повертає ресурс), а ваш код у блоці "using" захищає від "null", ваш код не підірветься при спробі виклику Dispose на null об'єкт через нульова перевірка 'вбудований'.

Друга причина, що ваша відповідь не точна, полягає в наступному stmt:

Викликається фіналізатор, що GC знищує ваш об'єкт

По-перше, фіналізація (як і сама GC) не детермінована. CLR визначає, коли він викличе фіналізатор. тобто розробник / код поняття не має. Якщо шаблон IDisposable реалізований правильно (як я вже розміщував вище) і GC.SuppressFinalize () був викликаний, фіналізатор НЕ буде викликаний. Це одна з головних причин правильно реалізувати шаблон. Оскільки існує лише 1 потік фіналізатора на керований процес, незалежно від кількості логічних процесорів, ви можете легко погіршити продуктивність, створивши резервну копію або навіть повісивши нитку Finalizer, забувши викликати GC.SuppressFinalize ().

На своєму блозі я опублікував правильну реалізацію Шаблону розпорядження: Як правильно реалізувати шаблон розпорядження

1) WebClient - керований тип, тому вам не потрібен фіналізатор. Фіналізатор потрібен у тому випадку, якщо ваші користувачі не розпоряджаються () класом NoGateway, а рідний тип (який GC не збирає) потребує очищення після. У цьому випадку, якщо користувач не зателефонує Dispose (), вміщений WebClient буде видалений GC відразу після того, як це зробить NoGateway.

2) Опосередковано так, але вам не доведеться турбуватися про це. Ваш код правильний у вигляді підставки, і ви не можете перешкодити вашим користувачам забути розпоряджатися () дуже легко.

Візерунок від msdn

public class BaseResource: IDisposable
{
   private IntPtr handle;
   private Component Components;
   private bool disposed = false;
   public BaseResource()
   {
   }
   public void Dispose()
   {
      Dispose(true);      
      GC.SuppressFinalize(this);
   }
   protected virtual void Dispose(bool disposing)
   {
      if(!this.disposed)
      {        
         if(disposing)
         {
            Components.Dispose();
         }         
         CloseHandle(handle);
         handle = IntPtr.Zero;
       }
      disposed = true;         
   }
   ~BaseResource()      
   {      Dispose(false);
   }
   public void DoSomething()
   {
      if(this.disposed)
      {
         throw new ObjectDisposedException();
      }
   }
}
public class MyResourceWrapper: BaseResource
{
   private ManagedResource addedManaged;
   private NativeResource addedNative;
   private bool disposed = false;
   public MyResourceWrapper()
   {
   }
   protected override void Dispose(bool disposing)
   {
      if(!this.disposed)
      {
         try
         {
            if(disposing)
            {             
               addedManaged.Dispose();         
            }
            CloseHandle(addedNative);
            this.disposed = true;
         }
         finally
         {
            base.Dispose(disposing);
         }
      }
   }
}

using(NoGateway objNoGateway = new NoGateway())

еквівалентно

try
{
    NoGateway = new NoGateway();
}

finally
{
    NoGateway.Dispose();
}

Викликається фіналізатор, що GC знищує ваш об'єкт. Це може бути зовсім іншим часом, ніж тоді, коли ви покинете свій метод. Утилізація IDisposable викликається відразу після виходу із блоку використання. Отже, шаблон зазвичай використовується для використання для безкоштовного використання ресурсів відразу після того, як вони вам більше не потрібні.

З того, що я знаю, настійно не рекомендується використовувати Finalizer / Destructor:

public ~MyClass() {
  //dont use this
}

Переважно, це пов’язано з невідомим, коли або ЯКЩО це буде викликано. Спосіб утилізації набагато кращий, особливо якщо ви використовуєте або розпоряджаєтесь безпосередньо.

використання - це добре. використай це :)