Яка різниця між використанням IDisposable проти деструктора в C #?

Коли я можу реалізувати IDispose на класі на відміну від деструктора? Я читав цю статтю , але все одно пропускаю суть.

Моє припущення полягає в тому, що якщо я реалізую IDispose на об'єкті, я можу явно його знищити на відміну від того, щоб чекати, коли сміттєзбірник це зробить. Це правильно?

Чи означає це, що я завжди повинен явно закликати розпоряджатися об'єктом? Назвіть кілька поширених прикладів цього?

Фіналізатор (він же деструктор) є частиною збору сміття (GC) - він невизначений, коли (або навіть якщо) це відбувається, оскільки GC відбувається в основному внаслідок тиску пам'яті (тобто потрібно більше місця). Фіналізатори зазвичай використовуються лише для очищення некерованих ресурсів, оскільки керовані ресурси матимуть власний збір / утилізацію.

Тому IDisposableвикористовується для детермінованого очищення об'єктів, тобто зараз. Він не збирає пам'ять об'єкта (яка все ще належить до GC), але використовується, наприклад, для закриття файлів, підключень до бази даних тощо.

Про це є багато попередніх тем:

• детермінована доопрацювання
• розміщення предметів
• за допомогою блоку
• ресурси

Нарешті, зауважте, що не рідкість IDisposableоб’єкт також має фіналізатор; в цьому випадку Dispose()зазвичай дзвонять GC.SuppressFinalize(this), тобто GC не запускає фіналізатор - він просто викидає пам'ять (набагато дешевше). Фіналізатор все ще працює, якщо ви забудете Dispose()об'єкт.

Роль Finalize()методу полягає в тому, щоб об’єкт .NET міг очищати некеровані ресурси під час збирання сміття . Однак такі об’єкти, як підключення до бази даних або обробники файлів, повинні бути звільнені якнайшвидше, замість того, щоб покладатися на збирання сміття. Для цього вам слід реалізувати IDisposableінтерфейс та звільнити свої ресурси в Dispose()методі.

На MSDN є дуже хороший опис :

Основне використання цього інтерфейсу - це звільнення некерованих ресурсів . Збірник сміття автоматично звільняє пам'ять, виділену керованому об'єкту, коли цей об'єкт більше не використовується. Однак передбачити, коли відбуватиметься вивезення сміття, неможливо . Крім того, сміттєзбірник не має знань про некеровані ресурси, такі як ручки вікон або відкриті файли та потоки.

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

Єдине, що має бути в деструкторі C #, це такий рядок:

Dispose(False);

Це воно. Нічого іншого ніколи не повинно бути в цьому методі.

Ваше запитання щодо того, чи варто завжди телефонувати, Disposeчи ні, зазвичай - гаряча дискусія. Дивіться це блозі про цікаву перспективу від шанованих людей у ​​.NET-спільноті.

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

У першому прикладі він каже, що Disposeзапуск елементів керування Windows Forms є стомлюючим та непотрібним у основних сценаріях. Однак він не зазначає, що Disposeнасправді викликається автоматично контейнерами управління в цих основних сценаріях.

У другому прикладі він зазначає, що розробник може помилково припустити, що екземпляр з нього IAsyncResult.WaitHandleслід агресивно розпоряджатися, не розуміючи, що властивість ліниво ініціалізує ручку очікування, що призводить до непотрібного покарання за виконання. Але проблема цього прикладу полягає в тому, що IAsyncResultсам по собі не дотримується власних опублікованих інструкцій Microsoft щодо поводження з IDisposableоб'єктами. Тобто, якщо клас містить посилання на IDisposableтип, то сам клас повинен реалізувати IDisposable. Якщо IAsyncResultдотримуватися цього правила, то його власнеDispose метод може прийняти рішення щодо того, хто з його складових потребує розпорядження.

Тож якщо у когось немає більш переконливого аргументу, я збираюся залишитися в таборі "завжди дзвонити", з розумінням того, що трапляються деякі випадкові випадки, які виникають з-за поганого дизайнерського вибору.

Насправді це дуже просто. Я знаю, що на нього відповіли, але я спробую ще раз, але спробую зробити це максимально просто.

Зазвичай деструктор ніколи не повинен використовуватися. Це лише run .net хоче, щоб він запускався. Він працюватиме лише після циклу збирання сміття. Він фактично ніколи не може бути запущений протягом життєвого циклу вашої програми. З цієї причини ви ніколи не повинні ставити жодний код у деструктор, який слід «запустити». Ви також не можете покластися на будь-які існуючі об'єкти в класі, які існуватимуть під час його запуску (вони, можливо, вже були очищені, оскільки не гарантується порядок введення деструкторів).

IDisposible слід використовувати щоразу, коли у вас є об'єкт, який створює ресурси, які потребують очищення (тобто файли та графічні ручки). Насправді, багато хто стверджує, що все, що ви поклали в деструктор, повинно бути поставлено в ідентифікаційному порядку через причини, перелічені вище.

Більшість класів зателефонують у розпорядження, коли виконується фіналізатор, але це просто як безпечна охорона і на нього ніколи не слід покладатися. Вам слід явно розпоряджатися будь-чим, що реалізує IDisposable, коли ви закінчите з цим. Якщо ви реалізуєте IDisposable, вам слід зателефонувати утилізувати у фіналізаторі. Для прикладу див. Http://msdn.microsoft.com/en-us/library/system.idisposable.aspx .

Ось ще одна чудова стаття, яка очищає частину туману, що оточує IDisposable, GC та розпоряджається.

Chris Lyons WebLog Демістифікуючи розпорядження