Есть ли Время, в которое можно проигнорировать IDisposable. Расположить?

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

Вот почему нам нужна функция Dispose . Освобождение памяти не происходит автоматически, как вы сказали в случае с неуправляемым кодом.

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

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

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

Во время совместного завершения работы домен приложения выгружается, что вызывает выполнение всех финализаторов:

Из документации Object.Finalize :

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

Таким образом, вы в безопасности при завершении работы, пока выполняются два критерия:

• Каждый IDisposable объект, который все еще жив, имеет правильно реализованный финализатор (верно для классов Framework, может не соответствовать менее надежные библиотеки); и

• На самом деле это совместное завершение работы, а не аварийное завершение, такое как жесткое завершение процесса, Ctrl-C в консольном приложении или Environment.FailFast .

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

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

Небольшой пример, чтобы дать вам представление:

    sealed class Logger : IDisposable
    {
        private bool _disposed = false;

        public Logger()
        {
            System.IO.File.AppendAllText( @"C:\mylog.txt", "LOG STARTED" );
        }

        ~Logger()
        {
            Dispose();
        }

        public void Dispose()
        {
            if ( !_disposed )
            {
                System.IO.File.AppendAllText( @"C:\mylog.txt", "LOG STOPPED" );
                _disposed = true;
            }
        }

        public void WriteMessage( string msg )
        {
            System.IO.File.AppendAllText( @"C:\mylog.txt", "MESSAGE: " + msg );
        }
    }

Обратите внимание, что этот класс Logger не «удерживает» какие-либо ресурсы в стиле объекта ядра. Он открывает файл и сразу закрывает его. Однако есть такая логика, что он должен писать «LOG STOPPED», когда объект уничтожается.Эта логика - то, что GC не может понять - и здесь можно использовать IDisposable .

Следовательно, вы не можете рассчитывать на то, что Windows очистит объекты ядра после вас. Может быть, есть что-то, чего не знает даже Windows.

При этом, однако, при условии, что ваши одноразовые объекты правильно написаны (т.е. вызывают Dispose в финализаторе), они все равно будут удалены CLR после выхода из процесса.

Итак, ответ: да, нет необходимости вызывать Dispose непосредственно перед выходом из проекта. Но НЕ потому, что одноразовые ресурсы являются объектами ядра (потому что они не обязательно таковыми).

Править

Как правильно заметил Джош Эйнштейн, на самом деле не гарантируется запуск финализаторов при выходе из процесса. Итак, ответ будет следующим: всегда вызывайте Dispose, просто для того, чтобы засудить