Гарантируется ли GC.SuppressFinalize?

Ответ 1

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

Если вы вставляете вызов в GC.KeepAlive(this) в конце метода Dispose, проблема может исчезнуть.

У Chris Brumme есть сообщение в блоге об этом, и я думаю, что там где-то где-то...

Ответ 2

Я всегда использую этот шаблон проектирования для реализации интерфейса IDisposable. (что предлагает Microsoft), и для меня GC.SuppressFinalize всегда имеет природу гарантии!

using System;
using System.ComponentModel;

//The following example demonstrates how to use the GC.SuppressFinalize method in a resource class to prevent the clean-up code for the object from being called twice.

public class DisposeExample
{
    // A 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 readonly Component component = new Component();
        // Track whether Dispose has been called.
        private bool disposed;

        // 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.
        private void Dispose(bool disposing)
        {
            // Check to see if Dispose has already been called.
            if (!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;
            }
            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 a MyResource object.
    }
}

Источник: MSDN: GC.SuppressFinalize Method

Ответ 3

Я делаю исключение InvalidOperationException в финализаторе, что позволяет легко находить типы, которые не были правильно расположены. Когда Dispose() вызывается там, где вызывается GC.SuppressFinalize, я никогда не получаю исключение.

Ответ 4

Я использовал ту же схему много раз, и GC.SupressFinalize всегда работал.

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

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

Eg. в конструкторе используйте

StackFrame frame = new StackFrame(1);

и сообщите об этом в своем отладочном сообщении во время финализатора.

Кроме того, я замечаю, что ваш GC.SupressFinalize не находится в предложении finally, если во время удаления выбрано исключение, финализатор объектов не будет подавлен.

Ответ 5

Когда объект с определяемым пользователем финализатором сконструирован, среда выполнения должна содержать внутреннюю ссылку на нее, поэтому, когда она становится недоступной в пользовательском коде, она может по-прежнему иметь финализатор, вызываемый в потоке завершения выполнения. Учитывая, что время имеет решающее значение при вызове финализаторов, нет смысла хранить объекты в очереди, если пользователь запросил их подавить. В моей тестовой реализации CLI я сохраняю флаг SuppressFinalizer в заголовке объектов с определенными пользователем финализаторами. Если флаг верен, когда поток финализатора достигает этого объекта в очереди, вызов финализатора пропускается. Я не удаляю объект из очереди, поэтому я могу сохранить вызов GC.SuppressFinalize() O (1) вместо O (N), где N - количество выделенных финализируемых объектов (я мог бы изменить эту политику на отложенное удаление политика позже).