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

Question

Поскольку процесс будет уничтожен ОС, и вся выделенная память будет переработана в любом случае, нормально ли не освобождать объекты/ресурсы в разделе окончательной настройки устройства?

Например,

unit Threading; 

interface 

implementation 

    var threadpool: ThreadPool; 

initialization 

    threadpool := ThreadPool.Create; 

finalization 

    threadpool.Free; // is it OK to remove this? 

end. 

Answer 1

Поскольку процесс будет уничтожен ОС, и вся выделенная память будет переработана в любом случае, правильно ли не освобождать объекты/ресурсы в разделе окончательной настройки устройства?

Да, это возможно. После завершения процесса система очистит ресурсы.

Однако есть несколько оговорок:

1. Большинство инструментов для обнаружения утечек убедитесь, что все динамически распределяемая память уничтожаются вашим процесс, прежде чем он возвращает управление системой. То, что вы предлагаете сделать, делает такие инструменты бессильными.
2. Если ваш код когда-либо встроен в динамическую библиотеку, такую ​​как DLL или пакет, тогда библиотека может быть выгружена, в то время как хост-процесс переносится. Это утечка и может повлиять на жизнеспособность хост-процесса.
3. Некоторые объекты требуют завершения финализации, иногда с ограничениями порядка. Не зная больше о вашем классе, мы не можем это судить.

Answer 2

Если удалить Free вызов из финализации секции затем threadpool и все его подпункты объекты будут всегда присутствовать в отчете утечки памяти вашего приложения. Тогда было бы трудно найти утечку памяти real.

Некоторые объекты могут выполнять действия по протоколированию или удалять файлы блокировки при уничтожении. Поэтому может потребоваться выполнение всех деструкторов.

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

Answer 3

Да, это нормально, но:

1) Вы можете использовать то следующие конструкции:

ThreadPool := ThreadPool.Create; 
RegisterExpectedMemoryLeak(ThreadPool); 

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

2) В противном случае вы можете ноль переменной (или использовать FreeAndNil, если вы хотите System.SysUtils зависимость):

finalization 
    ThreadPool.Free; 
    ThreadPool := nil; 

Таким образом, вы легко найти, кто получает доступ к ThreadPool, когда она выйдет.

3) Вы можете использовать TInterfacedObject для реализации или оболочки исходного класса.