Работа с .NET IDisposable объектами

FxCop мощь help (хотя он не обнаружил тест, который я только что запустил); но да: вы должны проверить. IDisposable - это просто такая важная часть системы, что вам нужно выработать эту привычку. Использование intellisense для поиска .D - хорошее начало (хотя и не идеальное).

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

ReSharper тоже выполняет эту работу, предлагая опцию «вставить в использование конструкции». Однако это не означает, что это ошибка ...

Конечно, если вы не уверены - пытатьсяusing it: компилятор насмехается над вами, если вы параноик:

using (int i = 5) {}

Error   1   'int': type used in a using statement must be implicitly convertible to 'System.IDisposable'    

Как и Fxcop (с которым они связаны), инструменты анализа кода в VS (если у вас одна из вышестоящих версий) также найдут эти случаи.

Всегда старайтесь использовать блоки "использования". Для большинства объектов это не имеет большого значения, однако я столкнулся с недавней проблемой, когда я реализовал элемент управления ActiveX в классе и не выполнял очистку изящно, если Dispose не был вызван правильно. Суть в том, что даже если кажется, что это не имеет большого значения, постарайтесь сделать это правильно, потому что через некоторое время это будет иметь значение.

Если объект реализует интерфейс IDisposable, то для этого есть причина, и вы должны вызывать его, и его не следует рассматривать как необязательный. Самый простой способ сделать это - использовать блок using.

Dispose() не предназначен для вызова только финализатором объекта, и, фактически, многие объекты будут реализовывать Dispose(), но не финализатор (что совершенно верно).

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

Метод Dispose() никак не связан с деструктором. Наиболее близким к деструктору в .NET является финализатор. Оператор using не выполняет никакого освобождения ... фактически, вызов Dispose() не освобождает управляемую кучу; он освобождает только неуправляемые ресурсы, которые были выделены. Управляемые ресурсы не освобождаются по-настоящему до тех пор, пока сборщик мусора не запустится и не соберет пространство памяти, выделенное для этого графа объектов.

Лучшие способы определить, реализует ли класс IDisposable:

• IntelliSense (если в нем есть метод Dispose() или Close())
• MSDN
• Отражатель
• Компилятор (если он не реализует IDisposable, вы получите ошибку компилятора)
• Здравый смысл (если это чувствует, как будто вы должны закрыть / освободить объект после того, как закончите, тогда вы, вероятно, должен)
• Семантика (если есть Open(), вероятно, должен быть вызван соответствующий Close())
• Компилятор. Попробуйте поместить его в оператор using. Если он не реализует IDisposable, компилятор выдаст ошибку.

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

@Atario, неверен не только принятый ответ, но и ваше собственное редактирование. Представьте себе следующую ситуацию (что на самом деле произошло в одной CTP из Visual Studio 2005):

Для рисования графики вы создаете перья, не выбрасывая их. Перьям не требуется много памяти, но они используют дескриптор GDI + внутри. Если вы не выбросите перо, ручка GDI + не будет выпущена. Если ваше приложение не требует интенсивного использования памяти, некоторое время может пройти без вызова GC. Однако количество доступных дескрипторов GDI + ограничено, и достаточно скоро, когда вы попытаетесь создать новое перо, операция завершится ошибкой.

Фактически, в Visual Studio 2005 CTP, если вы использовали приложение достаточно долго, все шрифты внезапно переключались на «Системные».

Именно поэтому недостаточно полагается на сборщик мусора при утилизации. Использование памяти не обязательно соответствует количеству неуправляемых ресурсов, которые вы приобретаете (и не выпускаете). Следовательно, эти ресурсы могут быть исчерпаны задолго до вызова GC.

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

Вот почему (IMHO) RAII C++ превосходит оператор using .NET.

Многие люди сказали, что IDisposable предназначен только для неуправляемых ресурсов, это верно только в зависимости от того, как вы определяете «ресурс». У вас может быть блокировка чтения / записи, реализующая IDisposable, и тогда «ресурс» - это концептуальный доступ к блоку кода. У вас может быть объект, который изменяет курсор на песочные часы в конструкторе и обратно к ранее сохраненному значению в IDispose, а затем «ресурс» - это измененный курсор. Я бы сказал, что вы используете IDisposable, когда хотите, чтобы детерминированное действие выполнялось при выходе из области видимости независимо от того, как она оставлена, но я должен признать, что это гораздо менее привлекательно, чем фраза «это для управления неуправляемым управлением ресурсами».

См. Также вопрос о почему в .NET нет RAII.

К сожалению, ни FxCop, ни StyleCop, похоже, не предупреждают об этом. Как отмечали другие комментаторы, обычно очень важно обязательно вызвать dispose. Если я не уверен, я всегда проверяю обозреватель объектов (Ctrl + Alt + J), чтобы посмотреть на дерево наследования.

Я использую блоки using в основном для этого сценария:

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

В качестве аргумента допустим, что у меня есть 11 точек выхода для моего метода, 10 из которых находятся внутри этого блока using и 1 после него (что может быть типичным для некоторого написанного мной библиотечного кода).

Поскольку объект автоматически удаляется при выходе из блока using, мне не нужно иметь 10 разных вызовов .Dispose () - это просто происходит. Это приводит к более чистому коду, поскольку теперь он менее загроможден вызовами dispose (в данном случае на 10 строк кода меньше).

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

Мне действительно нечего добавить к общему использованию блоков Using, но я просто хотел добавить исключение к правилу:

Любой объект, реализующий IDisposable, по-видимому, не должен вызывать исключение во время его метода Dispose (). Это отлично работало до WCF (могут быть и другие), и теперь возможно, что канал WCF выбрасывает исключение во время Dispose (). Если это происходит, когда он используется в блоке Using, это вызывает проблемы и требует реализации обработки исключений. Это, очевидно, требует большего знания внутренней работы, поэтому Microsoft теперь рекомендует не использовать каналы WCF в блоках Using (извините, не удалось найти ссылку, но много других результатов в Google), даже если он реализует IDisposable .. Просто чтобы сделать вещи более сложный!

In short, it's not the end of the world if I miss a using. I just wish something would generate at least a warning for it.

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

Хорошим примером этого является класс использует частный EventWaitHandle (или AutoResetEvent) для связи между двумя потоками, и вы хотите удалить WaitHandle после завершения потока.

Так что это не так просто, как какой-нибудь инструмент, просто проверить, что вы создаете только объекты IDisposable в блоке using.

Согласно эта ссылка, Надстройка CodeRush будет обнаруживать и отмечать, когда локальные переменные IDisposable не очищаются, в режиме реального времени по мере ввода.

Могу встретить вас на полпути квесту.

Я не понимаю сути вашего вопроса. Благодаря сборщику мусора утечки памяти практически невозможны. Однако вам нужна надежная логика.

Я использую для создания классов IDisposable вот такие:

public MyClass: IDisposable
{

    private bool _disposed = false;

    //Destructor
    ~MyClass()
    { Dispose(false); }

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

    private void Dispose(bool disposing)
    {
        if (_disposed) return;
        GC.SuppressFinalize(this);

        /* actions to always perform */

        if (disposing) { /* actions to be performed when Dispose() is called */ }

        _disposed=true;
}

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

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