Деструктор против IDisposable?

Я написал довольно подробный пост, который должен помочь объяснить о финализаторах, IDisposable и о том, когда следует использовать тот или иной: http://gregbee.ch/blog/implementing-and-using-the-idisposable-interface

Вероятно, самая важная часть цитируется ниже:

When you are using unmanaged resources such as handles and database connections, you should ensure that they are held for the minimum amount of time, using the principle of acquire late and release early. In C++ releasing the resources is typically done in the destructor, which is deterministically run at the point where the object is deleted. The .NET runtime, however, uses a garbage collector (GC) to clean up and reclaim the memory used by objects that are no longer reachable; as this runs on a periodic basis it means that the point at which your object is cleaned up is nondeterministic. The consequence of this is that destructors do not exist for managed objects as there is no deterministic place to run them.

Instead of destructors, C# has finalizers which are implemented by overriding the Finalize method defined on the base Object class (though C# somewhat confusingly uses the C++ destructor syntax ~Object for this). If an object overrides the Finalize method then rather than being collected by the GC when it is out of scope, the GC places it on a finalizer queue. In the next GC cycle all finalizers on the queue are run (on a single thread in the current implementation) and the memory from the finalized objects reclaimed. It's fairly obvious from this why you don't want to do clean up in a finalizer: it takes two GC cycles to collect the object instead of one and there is a single thread where all finalizers are run while every other thread is suspended, so it's going to hurt performance.

So if you don't have destructors, and you don't want to leave the cleanup to the finalizer, then the only option is to manually, deterministically, clean up the object. Enter the IDisposable interface which provides a standard for supporting this functionality and defines a single method, Dispose, where you put in the cleanup logic for the object. When used within a finally block, this interface provides equivalent functionality to destructors. The reason for finally blocks in code is primarily to support the IDisposable interface; this is why C++ uses simply try/except as there is no need for a finally block with destructors.

Укороченная версия

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

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

Мой самый популярный ответ на Stackoverflow с самого начала объясняет вам, почему у вас есть IDisposable, что он должен делать, что может делать ваш финализатор, чего он не должен делать.

This answer melts faces

был использован для его описания: P

Наличие деструктора (~ Object ()) в управляемом языке программирования - самая глупая идея. Для неуправляемых языков, таких как C, C++, вполне имеет смысл иметь деструкторы, поскольку они используют идиому RAII, но для управляемых, таких как Java, C#, это просто абсурд.

Джошуа Блох, бывший руководитель проекта Java Collection Framework, отмечал, что идея метода finalize () (который эквивалентен деструктору, подобному C++ в C#) в Java была самой большой ошибкой из когда-либо сделанных. Как и в C#, функция finallize () в Java дает накладные расходы на «новый», поскольку он должен быть добавлен в очередь финализатора во время выделения. Более того, сборщик мусора должен выскакивать и запускать finallize () в очереди, поэтому в два раза больше накладных расходов во время gc.

В C# было много расширенных функций, таких как using (IDisposable) {}, которые не только позволяют ограничить переменную IDisposable областью блока using, но также гарантируют ее очистку. У меня вопрос, почему C# пошел по тому же пути, что и Java, что привело к большой ошибке. Возможно, если бы разработка dotnet началась примерно после 2003–2005 гг., Когда многие архитекторы Java обнаружили ошибку finallize (), то ошибку можно было бы предотвратить.

Многие хорошие идеи одного языка часто переносятся на другой язык, например, «IDisposable / using combo» в C#, который был перенесен в Java 1.7 в его операторе «try (object-to-dispose) {}». Но очень плохо, что архитекторы языка не могут обнаружить плохую идею, замаскированную под хорошую, во время ее передачи от одного к другому.

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