IDisposable, делает это, действительно имеют значение

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

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

Короткий ответ заключается в том, что если объект прилагает усилия для реализации IDisposable, он существует по какой-то причине, поэтому ВСЕГДА удаляйте его, когда закончите, в идеале с помощью оператора using . Не умничайте и не хитрости с утилизацией иногда, но не в других случаях, когда вы не думаете, что вам нужно бла-бла-бла. Просто делайте то, что работает каждый раз.

Короче и удовлетворительнее ответ: вы правы, а ваши коллеги - идиоты, которые не знают, что делают.

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

Большинство по-прежнему будут очищать свои ресурсы после завершения объекта, но завершение не является детерминированным и на него нельзя полагаться для управления ресурсами.

Простое размещение объявлений переменных в блоке using (...) упрощает правильное удаление.

Некоторые из этих ресурсов как ручки являются ограниченным ресурсом для всей системы, поэтому, если ваше приложение не выпускает эти другие приложения или даже ОС, могут пострадать. Взгляните на последнюю статью Марка Руссиновича о расширении границ серии Windows для примеров.

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

Неутилизация объектов IDisposable, освобождающих базу данных, - надежный и эффективный способ генерировать OutOfMemoryExceptions в средах.

DataSet реализует IDisposable, и я читал, что нет необходимости вызывать Dispose, потому что объекты, которые должны быть утилизированы для набора данных, создаются только во время проектирования (дизайнером visual studio). Я никогда не видел OOM от неутилизированных наборов данных (только OOM от огромных DataSets)

Помимо очевидных случаев (уже упомянутых) нехватки ресурсов, еще одним преимуществом IDisposable является то, что, поскольку он гарантирует, что Dispose () вызывается при выходе из блока , использующего , вы можете использовать его для всех разные вещи, даже вещи, которые не просто «выполняют операции с ресурсом ОС».

В этом смысле это похоже на замену для бедняков блокам Ruby или один небольшой вариант использования макросов Lisp.

Не удаляя (или не закрывая) соединения с базой данных, вы в конечном итоге укуситесь, да. Я видел, как это происходит.

Да, Да, Да , Это важно.

Недавно я профилировал приложение, которое никогда не профилировалось. Это просто приложение Winforms, ничего страшного, не так ли?

Неправильно.

Не реализуя IDisposible и не отменяя ссылки на обработчики событий, приложение теряло память как решето.

.NET Framework не освобождает вас от необходимости убирать за собой, она просто снижает вероятность того, что вы что-то сломаете, если вы этого не сделаете.

Потратьте час, профилируйте свое приложение с помощью ANTS Profiler . Это бесплатная пробная версия. Если вы не видите утечек памяти, продолжайте свой путь. Если да, то это потому, что вы полагались на .NET Framework как на свой костыль.